Amazon Bedrock Zero Data Retention: Enforce It with Projects, IAM, and SCPs

“Amazon Bedrock does not use your prompts to train base models” is not a complete data-retention policy. An application can use an API that stores state, select a model that requires safety retention, opt into provider data sharing, route inference through another Region, or log the same prompt in five systems you control. Compliance needs an enforced configuration and an evidence trail, not a sentence copied from a service FAQ.

AWS added explicit Bedrock retention modes, project-level controls on the Mantle endpoint, and IAM condition keys that can be enforced with service control policies. On July 7, 2026, AWS published an organization-wide pattern for keeping production at none while letting carefully separated research accounts use models with different requirements.

This guide implements that pattern. It covers mode resolution, the difference between bedrock-runtime and bedrock-mantle, OU design, a preventive SCP, the Organizations management-account gap, verification, cross-Region inference, and the logs that can quietly defeat a zero-retention claim.

Start by defining what “zero” covers

Bedrock’s none mode controls service and model-provider retention after inference processing. It does not delete application copies. API Gateway access logs, Lambda logs, X-Ray traces, exception trackers, evaluation datasets, chat history tables, support bundles, and browser telemetry may still store the request or response.

A useful data map separates four planes:

Do not call the whole architecture zero-retention because the first row is none. State the boundary precisely: “Bedrock inference runs in none; the application retains redacted conversation metadata for 30 days,” for example.

The Bedrock trust and safety production checklist covers prompt logging, abuse controls, and incident evidence. Retention configuration belongs beside those controls, not in a separate compliance document nobody reads during deployment.

Understand the four modes

Bedrock resolves an effective retention setting from the most specific configured scope: project, then account, then the model default. The first value that is not inherit wins.

effective mode = first non-inherit value(project → account → model default)

provider_data_share is not silently inherited from a model. It is an explicit opt-in at the account or project level. If the effective ceiling is none and a model requires sharing or unsupported retention, the call is denied rather than quietly weakening the policy.

Some accounts may receive model-specific zero-data-retention approval after working with AWS and the provider. Do not assume that availability in one account applies to another. Query the model’s allowed_modes as part of admission.

AWS also documents an exception for automated detection of child sexual abuse material: flagged content may be stored and reviewed for required reporting even under none. Legal and security teams should understand that exception before writing absolute contractual language. The current details belong in the Bedrock data-retention documentation, not in a static internal wiki.

Two endpoint families require two designs

Bedrock Projects apply to the OpenAI-compatible and Anthropic-compatible APIs on bedrock-mantle. A project can set its own mode, allowing a production project to use none while a research project in the same account accepts a different ceiling.

The traditional bedrock-runtime endpoint, including InvokeModel and Converse, does not use project-level retention. The account setting applies to all calls in that account. If two runtime workloads need different ceilings, separate them into different AWS accounts or OUs.

This endpoint distinction is easy to miss because both products appear under Amazon Bedrock. Architecture review should record the hostname and API family, not just the service name.

The existing Claude Opus 5 production guide discusses that model’s data-handling posture. This article addresses the organization control that must remain correct as models and terms change.

Build OUs around data policy

Use accounts as the hard boundary for bedrock-runtime and as defense in depth for Mantle:

AWS Organization
├── OU: AI-Zero-Retention
│   ├── Account: customer-support-prod
│   ├── Account: document-processing-prod
│   └── Account: regulated-evaluation
└── OU: AI-Research
    ├── Account: model-experiments
    └── Account: red-team-sandbox

The zero-retention OU receives the SCP. Research does not, but it still needs data classification, approved datasets, explicit opt-in, and budget controls. “Research” is not permission to upload customer records.

Do not mix an unrestricted sandbox account into the production OU and create SCP exceptions for individual administrators. Exceptions accumulate and make the policy impossible to explain. Move the account to the correct OU after review.

The AWS Organizations and Control Tower guide covers OU and guardrail design. Retention is an excellent example of why accounts should express security boundaries instead of mirroring a company org chart.

Initialize every account before attaching the deny

New accounts can inherit rather than hold an explicit none. A deny policy that blocks changes away from none does not automatically write the desired value. Set the account mode first in every relevant Region and account:

aws bedrock put-account-data-retention \
  --region us-east-1 \
  --mode none

aws bedrock get-account-data-retention \
  --region us-east-1

Inventory Regions in which Bedrock workloads or inference profiles operate. The retention controls and endpoint availability evolve, so automate the query rather than maintaining a spreadsheet.

For hundreds of accounts, run the initialization through an approved StackSets, account-vending, or automation role. Record account, Region, observed mode, desired mode, timestamp, and API response. Retry throttled calls and fail closed when a Region cannot be verified.

Deny weaker settings with an SCP

The SCP must cover the Bedrock control plane and Mantle. The following structure denies any requested mode other than none:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RequireBedrockControlPlaneZeroRetention",
      "Effect": "Deny",
      "Action": "bedrock:PutAccountDataRetention",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "bedrock:DataRetentionMode": "none"
        }
      }
    },
    {
      "Sid": "RequireMantleZeroRetention",
      "Effect": "Deny",
      "Action": [
        "bedrock-mantle:PutAccountDataRetention",
        "bedrock-mantle:CreateProject",
        "bedrock-mantle:UpdateProject"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "bedrock-mantle:DataRetentionMode": "none"
        }
      }
    }
  ]
}

Test the exact policy in a sandbox OU before attaching it broadly. Condition-key behavior on omitted parameters matters. Confirm that required account and project operations still work when they specify none, and that default, inherit, and provider_data_share fail.

SCPs limit permissions; they do not grant them. Principals still need IAM permission for approved operations. The IAM permission-boundaries guide explains another policy layer, but boundaries cannot substitute for an organization-wide SCP when account administrators can change identity policies.

Close the management-account gap

AWS Organizations SCPs do not restrict the management account. If Bedrock is enabled there, an administrator can change retention even when every member account is protected.

The cleanest choice is not to run application inference in the management account. Keep it for organization administration, restrict access, and use dedicated workload accounts. If Bedrock must be present, attach an IAM policy with the same explicit deny to every relevant principal, including roles used by automation.

An IAM deny is less structurally strong than an SCP because management-account administrators can change IAM. Compensate with tightly controlled break-glass access, CloudTrail alerts for policy and retention changes, and a continuous configuration check.

The AWS Security Blog calls out this management-account exemption in its zero-retention enforcement walkthrough. Include it in the audit narrative instead of claiming root-level coverage that does not exist.

Configure and verify Mantle projects

Set the account ceiling, then make the project explicit. An inherited production project can become weaker if someone later changes the account:

export BEDROCK_API_KEY='set-this-through-your-secret-manager'
export PROJECT_ID='proj_customer_support_prod'

curl --fail-with-body \
  -X POST \
  "https://bedrock-mantle.us-east-1.api.aws/v1/organization/projects/${PROJECT_ID}" \
  -H "x-api-key: ${BEDROCK_API_KEY}" \
  -H 'Content-Type: application/json' \
  -d '{"data_retention":{"mode":"none"}}'

Do not place API keys in shell history, CI variables visible to forks, or article examples used verbatim. Retrieve the key at runtime from your approved secret store and mask it in logs.

Verify account, project, and model:

curl --fail-with-body \
  "https://bedrock-mantle.us-east-1.api.aws/v1/data_retention" \
  -H "x-api-key: ${BEDROCK_API_KEY}"

curl --fail-with-body \
  "https://bedrock-mantle.us-east-1.api.aws/v1/organization/projects/${PROJECT_ID}" \
  -H "x-api-key: ${BEDROCK_API_KEY}"

curl --fail-with-body \
  "https://bedrock-mantle.us-east-1.api.aws/v1/models/anthropic.claude-sonnet" \
  -H "x-api-key: ${BEDROCK_API_KEY}"

Model identifiers change. Discover the approved identifier from ListModels and assert that the effective mode is none before admitting it to production. The Bedrock model lifecycle guide explains why model replacement and retirement need automation rather than manual review once a year.

Test the preventive control

A security control is not complete until a negative test fails for the right reason. From a sandbox member account under the SCP, attempt a prohibited change:

aws bedrock put-account-data-retention \
  --region us-east-1 \
  --mode provider_data_share

Expect AccessDenied with an explicit deny from the service control policy. Then verify that setting none is permitted for an authorized principal. Repeat against Mantle project creation or update.

Automate these tests after policy changes. A JSON policy that passed syntax validation can still use the wrong action prefix or condition key.

Cross-Region inference changes the data map

With cross-Region inference, Bedrock may process a request in a destination Region. If a selected model retains data under the effective mode, the retained input and output can reside in that destination Region. Data residency review must include the inference profile’s possible Regions, not merely the client endpoint.

For strict workloads, combine retention policy with Region restrictions and approved inference profiles. Test what happens when an allowed model is unavailable in the preferred Region. A fallback that violates residency is not a reliability improvement.

The cross-account Bedrock Guardrails pattern is complementary: guardrails inspect content, while retention controls what may persist. Neither replaces the other.

Stop your own telemetry from retaining prompts

Search the codebase and observability configuration for raw request bodies. Common leaks include:

• API Gateway execution or access logs containing body fields
• Lambda logger.info(event) statements
• OpenTelemetry span attributes containing prompts
• Exception objects that serialize request payloads
• Agent traces and tool-call transcripts
• Evaluation systems that copy “interesting failures” indefinitely

Redact before the model call and log structured metadata: request ID, project ID, model ID, token counts, latency, policy decision, guardrail outcome, and a non-reversible content fingerprint when needed for correlation. Never hash a low-entropy secret and assume it cannot be recovered.

The responsible AI GRC implementation guide provides a broader control framework. Zero retention is one control objective, not a full responsible-AI program.

Choose the policy by workload, not by model hype

The most conservative policy is not always “deny Bedrock.” It is to make the retention ceiling machine-enforced, separate incompatible workloads, and reject models that cannot meet the declared boundary. That lets teams adopt compatible models quickly without reopening the entire data-governance decision for every launch.

Run the control as code. Initialize every account. Protect both action families. Keep application workloads out of the Organizations management account. Verify the effective project, account, and model mode before traffic. Then audit the copies you create yourself. Only after all five are true does none become a defensible production claim rather than a console screenshot.

Automate the new-account bootstrap safely

The most dangerous time is between account creation and policy enforcement. A new account starts with inherited retention behavior, so attaching a deny policy before initializing the account can block the very API call required to move it to none.

Build the account-vending sequence as an explicit state machine:

1. Create or enroll the workload account in a quarantine organizational unit with no production traffic.
2. Deploy the automation role, logging, and required Bedrock control-plane permissions.
3. Query the current account and project retention configuration.
4. Set the account-level mode to none through the supported management API.
5. Read the configuration back and assert the effective result.
6. Query each approved model for supported retention modes and fail enrollment when none is unavailable.
7. Attach the SCP that denies weaker settings and ungoverned paths.
8. Move the account into the production organizational unit only after conformance tests pass.

The management account is not restricted by SCPs. Do not run Bedrock workloads there. Protect its identities with tightly reviewed IAM policies, strong federation, and minimal standing access.

Keep separate controls for the bedrock-mantle project APIs and account-level bedrock-runtime calls. A project set to zero retention does not automatically govern a caller that bypasses the project and invokes the account-level runtime. If teams need different retention guarantees, use separate workload accounts because the account-level runtime has one effective account boundary.

Add a continuous conformance job that assumes a read-only audit role in every enrolled account and checks:

Alert on drift rather than silently rewriting it. Automatic repair can destroy evidence of who changed a security control and why. Capture the event, quarantine new traffic if necessary, then restore the expected configuration through the normal change path.

Verify the claim from the application path

A console screenshot is weak evidence. Test the exact application identity, endpoint, project, model, Region, and SDK path used in production.

Create positive and negative tests. The positive test invokes an approved model through the governed project and receives a response. Negative tests attempt to set a disallowed retention mode, use an unapproved model, call the account-level runtime when policy requires a project, and select an unapproved cross-Region destination. Each must fail for the expected authorization reason.

Store the effective configuration, SCP version, model capability response, CloudTrail request ID, application deployment version, and test result in the release evidence. Re-run the suite after a model upgrade, new Region, organization move, or policy change.

Zero data retention is one privacy property, not a complete data-protection program. The application can still log prompts, traces, tool arguments, responses, embeddings, or exception payloads. Inspect API Gateway, Lambda, agent frameworks, observability exporters, and support tooling. Redact or avoid sensitive content at each layer and set retention on the logs you intentionally keep.

The Bedrock documentation also identifies a narrow safety exception for content flagged as potential child sexual abuse material. Describe the control accurately in compliance material instead of presenting “zero” as an unconditional physical impossibility across every safety process.

Sources

• AWS Security Blog: Enforce zero data retention on Amazon Bedrock
• Amazon Bedrock: Data retention
• AWS Service Authorization: Bedrock Powered by AWS Mantle
• AWS Organizations: Service control policies
• AWS Organizations: SCP effects on permissions
• Amazon Bedrock: Cross-Region inference
• Amazon Bedrock: Security and privacy