# 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/AmazonS3/latest/userguide/access-control-block-public-access.html
- https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-points.html
- https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies.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:
- S3 Block Public Access can be configured at account, bucket, access point, and organization levels; IAM Access Analyzer for S3 can review public buckets.
- S3 access points support shared dataset access patterns, VPC restrictions, IAM policies, and object-operation controls.

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

Review implications:
- Data perimeter review needs bucket/access point policies, BPA state, encryption, VPC endpoint policy, organization/SCP context, Access Analyzer findings, replication, logging, and exception approvals.
- Public-access absence alone does not prove tenant/data perimeter safety.

# S3 Data Perimeter Controls Guide

Use this reference for Amazon S3 data perimeter reviews covering Block Public Access, Object Ownership, ACL removal, bucket/access point policies, VPC endpoint conditions, TLS-only access, encryption, replication, logging, and cross-account access.

## What people get wrong

The lazy story is:

> Block Public Access is on, so the bucket is safe.

Wrong. S3 exposure is a policy system. Public blocking helps, but data can still leak through broad principals, cross-account trust, access points, replication, CloudFront origins, VPC endpoint policies, logging gaps, and weak object ownership assumptions.

Common bad assumptions:

- `Principal: *` is safe if conditions look specific.
- ACLs no longer matter everywhere because Object Ownership exists.
- VPC endpoint conditions prove private-only access.
- SSE-S3/SSE-KMS proves authorization and data minimization.
- Access points simplify policy without changing risk.
- Server access logging or CloudTrail data events are enabled unless proven.

## S3-specific failure modes

- Bucket policy allows public, cross-account, or organization-wide access without prefix/resource boundaries.
- Access point or Multi-Region Access Point policy bypasses intended bucket guardrails.
- Block Public Access differs at account, bucket, and access-point layers.
- Object Ownership/ACL state allows unexpected object-owner access or breaks writers.
- VPC endpoint policy, `aws:SourceVpce`, `aws:PrincipalOrgID`, and TLS conditions are missing or misapplied.
- Replication, lifecycle expiration, inventory, logging, or Macie coverage excludes sensitive prefixes.

## Minimum safe workflow

1. Identify bucket, account, Region, data classification, access patterns, writers/readers, and prefixes.
2. Review account-level and bucket-level Block Public Access plus Object Ownership and ACL posture.
3. Inspect bucket policy, access point policies, VPC endpoint policies, KMS key policy, and cross-account principals together.
4. Verify data perimeter conditions: organization, VPC endpoint, TLS, encryption, source account, source ARN, and prefix scope.
5. Check logging/detection: CloudTrail data events, S3 server access logs, Storage Lens, Macie, Access Analyzer, and Security Hub findings.
6. Recommend smallest reversible policy/control changes; destructive delete/lifecycle changes require separate approval.
7. State what live evidence was sampled and what remains unknown.

## Verification targets

- S3 Block Public Access at account, bucket, and access point level
- Object Ownership, ACL state, bucket policy, access point policy, and Multi-Region Access Point policy
- IAM/SCP/VPC endpoint/KMS policies affecting access
- policy conditions: `aws:PrincipalOrgID`, `aws:SourceVpce`, `aws:SecureTransport`, `s3:prefix`, `aws:SourceArn`, `aws:SourceAccount`
- CloudTrail data events, server access logs, S3 Inventory, Storage Lens, Macie classification, Access Analyzer, and Security Hub findings
- replication/lifecycle/object lock/retention settings for sensitive prefixes

## When to push back

Push back if the user asks to:

- allow broad cross-account or public access without data-owner approval
- disable Block Public Access to “fix” application access
- rely on encryption as a substitute for authorization
- remove logs, Object Lock, retention, or replication without compliance review
- trust a single bucket policy snippet without account/SCP/KMS/endpoint context
- patch production bucket policies without rollback and access test plan

# 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, compliance-impacting, 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.

# 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:
- Bucket/account/org-level public access settings, Object Ownership, ACL posture, access points, and resource policies
- Principal/resource/action/condition scoping, prefix boundaries, TLS-only, VPC endpoint, organization, and data perimeter conditions
- Encryption, KMS key access, replication, logging, lifecycle, retention, Macie, Storage Lens, and backup/recovery interactions
- Validation via IAM Access Analyzer, Security Hub, S3 policy checks, sanitized evidence, and rollback

## 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 S3 Data Perimeter Governor: <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>
```