# Official sources

Use this reference only when you need source grounding for AWS service behavior or the detailed source list.

## AWS documentation

Use these as starting points, not as proof of the user's live AWS state:
- https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub-v2.html
- https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html
- https://docs.aws.amazon.com/inspector/latest/user/what-is-inspector.html
- https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html

## Grounding rule

Official documentation explains AWS service behavior. It does not prove the user's current account, Region, quota, resource configuration, IAM boundary, pricing, entitlement, or operational state. Prefer read-only AWS MCP or CLI evidence, repository evidence, or sanitized user-provided evidence for current-state claims.

## Current MCP/documentation refresh (2026-06-02)

Service facts from official docs:
- Security Hub unifies cloud security signals, exposure detection, automated response paths, and third-party integrations.
- IAM Access Analyzer can identify external/internal access, unused IAM access, validate policies, and generate policies from CloudTrail activity.

Sampled live evidence:
- Read-only regional availability sampling reported Security Hub and GuardDuty as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
- Sampled APIs `SecurityHub+GetFindings`, `GuardDuty+ListDetectors`, and `AccessAnalyzer+ListFindings` were reported `isAvailableIn` in those regions.

Review implications:
- Hardening requires enabled-service coverage, org aggregation, finding severity/age, exceptions, IAM exposure, public access, encryption/logging gaps, and remediation ownership.
- Security tool availability does not prove detectors are enabled, findings are triaged, or controls are enforced.

# Safety checklist

Use this reference before privileged, destructive, traffic-changing, cost-changing, compliance-impacting, or production-impacting recommendations.

## Non-negotiables

- Never ask users to paste secrets, access keys, session tokens, private keys, customer identifiers, or sensitive account data into chat.
- Use read-only AWS MCP or read-only AWS CLI evidence for live state when available; otherwise use repository evidence, sanitized user evidence, or official documentation and label the evidence level.
- Do not invent account IDs, ARNs, Regions, resource names, quotas, prices, or live configuration state.
- Require explicit user approval before privileged, destructive, traffic-changing, cost-changing, or production-impacting actions.
- Use current official AWS documentation for service behavior when the answer depends on AWS service details.
- Keep remediation least-privilege, reversible, and scoped to the requested workload or account boundary.

## Stress checks

- What can expose data?
- What can escalate privilege?
- What can break production or block rollback?
- What can create unbounded cost?
- What compliance or audit evidence is missing?
- What rollback or validation path is unproven?

## Evidence labels

Use `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's live AWS state.

# Security Posture Prioritization Guide

Use this reference when prioritizing AWS Security Hub CSPM, GuardDuty, Inspector, Macie, Config, CloudTrail, IAM, public exposure, vulnerability, and compliance posture findings.

## What people get wrong

The lazy story is:

> Sort Security Hub findings by severity and fix the highs first.

Wrong. Finding severity is an input, not a priority model. Real risk depends on exploitability, exposure, asset criticality, compensating controls, account scope, and remediation blast radius.

Common bad assumptions:

- Security Hub enabled means all relevant controls are covered.
- GuardDuty finding absence means no threat activity.
- Inspector vulnerability severity equals business priority.
- Public exposure findings are all equally urgent.
- CloudTrail configured in one account/Region proves audit coverage.
- Auto-remediation is safe for posture hardening.

## Security-posture failure modes

- Delegated administrator and organization coverage miss member accounts or Regions.
- Security Hub standards are enabled but findings are suppressed, stale, or unowned.
- GuardDuty, Inspector, Macie, Config, or CloudTrail are partially deployed or not routed to responders.
- IAM findings are remediated with broad deny/allow changes that break workloads.
- Public S3, security group, ALB, API Gateway, or CloudFront exposure lacks data classification context.
- Remediation deletes evidence, disables logging, rotates secrets without consumers, or changes KMS policies unsafely.

## Minimum safe workflow

1. Confirm organization/account/Region scope and which services are actually enabled.
2. Normalize findings by resource, owner, business criticality, exposure path, data sensitivity, and active threat evidence.
3. Separate detection gaps from resource misconfigurations and vulnerability remediation.
4. Prioritize by risk: internet exposure plus sensitive data, identity escalation, logging gaps, exploitable vulnerabilities, and active GuardDuty signals.
5. Recommend least-privilege, reversible remediation with validation and rollback notes.
6. Track exceptions, suppressions, compensating controls, and due dates explicitly.
7. Do not execute auto-remediation from this review skill.

## Verification targets

- Security Hub/CSPM standards, finding workflow status, suppression rules, and delegated admin/account coverage
- GuardDuty detectors, findings, malware protection, trusted/threat lists, and alert routing
- Inspector coverage for EC2/ECR/Lambda and vulnerable package/resource context
- Macie jobs/classification findings for sensitive data exposure
- Config recorders, conformance packs, aggregators, and CloudTrail organization trails/log integrity
- IAM Access Analyzer, public access findings, security group exposure, S3 Block Public Access, KMS key policy, and secret rotation evidence

## When to push back

Push back if the user asks to:

- treat compliance score as actual security risk
- suppress findings without owner, reason, expiry, and compensating control
- run broad auto-remediation on production resources
- widen IAM/network access to clear a finding
- claim organization coverage from a single account sample
- remove logs/evidence while remediating

# Workflow and output contract

Use this reference only when performing the full review, implementation guidance, incident triage, or production-readiness pass.

## Review domains

Check these areas before giving a verdict:
- Security Hub standards, AWS Config recording, finding coverage, suppressions, and delegated admin
- GuardDuty, Inspector, Macie, CloudTrail, KMS, IAM Access Analyzer, and public-access controls
- Prioritization by exploitability, blast radius, data sensitivity, exposure, and business owner
- Remediation plan with rollback, exception handling, and validation commands

## Safe workflow

1. **Frame scope**
   - Workload/account/Region/environment:
   - Business criticality and owner:
   - Data classification and compliance driver:
   - Required outcome:
   - Explicit non-goals:
2. **Collect evidence**
   - Prefer read-only AWS MCP or read-only AWS CLI evidence for current-state claims when available.
   - Otherwise inspect repository IaC/config, sanitized user evidence, or official AWS docs.
   - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
3. **Stress-test risk**
   - What can expose data?
   - What can escalate privilege?
   - What can break production or block rollback?
   - What can create unbounded cost?
   - What evidence is missing?
4. **Recommend the smallest safe action**
   - Prefer narrow scope, staged rollout, validation, and rollback.
   - If the safest action is to stop and gather evidence, say that plainly.

## Output contract

Return this structure:
```markdown
# AWS Security Posture Hardening: <scope>
## Executive verdict
- Status: READY / READY WITH RISKS / NOT READY / NEEDS EVIDENCE
- Biggest risk:
- Evidence level:
## Scope and assumptions
- Confirmed:
- Unknown:
- Out of scope:
## Findings
| Severity | Finding | Evidence | Why it matters | Minimum safe action |
|---|---|---|---|---|
## Recommended actions
1. <action> — owner: <owner>, validation: <check>, rollback: <rollback>
## Validation
- Commands or checks:
- Expected result:
## Residual risk
- <risk or explicit none>
```