AWS Bedrock's zero data retention has two exceptions

Amazon Bedrock does not store your prompts. That is the default, it is written down, and it is unusual enough to be worth quoting in full.

From the abuse detection page: "Amazon Bedrock uses a zero operator access (ZOA) data security model. This means no operators of the service can access model input or output. Also, Amazon Bedrock uses a zero data retention (ZDR) data security model. This means that by default, Amazon Bedrock does not store model inputs or outputs."

Two models on the platform will not run under that default. Both are Anthropic's: Claude Fable 5 and Claude Fable 5.1. To use either one, you have to instruct AWS in writing to start keeping your traffic.

Everything below is read off two pages of the Amazon Bedrock User Guide, the data retention page and the abuse detection page, as they stood on 8 September 2026. Retention policy is exactly the sort of thing that moves without an announcement, so treat the dates and the model lists here as a snapshot and check the pages themselves before you act on any of it.

What the retention page says#

Bedrock's retention setting is not a switch. It is a mode, and the modes form an ordered scale from least to most permissive:

none  <  default  <  aws_review  <  provider_data_share

A model is available when your effective mode is at or above the mode it requires. For these two, AWS states the requirement and the consequence together: "You must explicitly set your data retention mode to aws_review, or to the legacy provider_data_share, before you can invoke these models. If your effective mode is none or default, these models will be unavailable."

Unavailable is literal. The model returns status: "unavailable" in the models list with the reason attached, and requests to it are blocked.

The part that is on the other page#

The mode is called aws_review, and the retention page describes it as one that "allows your inputs and outputs to be retained for human review by AWS". AWS adds that the review happens inside the AWS boundary, that the model provider does not review your content, and that your content is not shared with the provider.

Read only that page and you would reasonably conclude that human review is the whole of what you are agreeing to. It is not. The abuse detection page carries the other half:

"For Anthropic Claude Fable 5 and Claude Fable 5.1, all traffic will be retained for up to 30 days for automated offline abuse detection. Classifier-flagged traffic will be subject to potential human review performed by AWS."

So the two halves are different sizes. Everything you send is kept for 30 days and scanned by machine. A subset that a classifier flags may then be read by a person at AWS. The mode is named after the smaller half.

Neither page is wrong. The retention page is describing the permission you grant; the abuse detection page is describing the practice that permission covers. But the decision you are actually making is the bigger one, and you only see it if you read both. This is the same reason the privacy audit on coding assistants had to go to settings pages rather than marketing pages: the exact claim is rarely in the place that announces it.

What is not affected#

The scope here is narrow, and AWS is explicit about that in three places.

Older Claude models are untouched: "There is no data retention change to Claude models released before Claude Fable 5."

A permissive account setting does not spread. Each model declares which modes it accepts, and AWS works the example through with Claude Opus 4.8, whose accepted list includes none: because the model permits none, its data is not retained whatever you set at the account level. Setting aws_review for the account you need it in does not quietly opt your other traffic in.

And the retention is not provider sharing. provider_data_share is marked legacy, with AWS stating plainly that Bedrock does not share your content with model providers today, and that setting the mode does not cause it to happen. If you are already on it, you are covered for the new models and need do nothing.

OpenAI's models on Bedrock sit at a different level again. For the GPT-5.4, GPT-5.5 and GPT-5.6 families, AWS retains "classifier-flagged traffic" for up to 30 days, not all of it. That is a materially smaller retention footprint than the Anthropic pair, on the same platform, on the same page.

How to check what yours is set to#

There is no interface for this yet. AWS says so: "At launch, there is no console UI for configuring data retention. Customers must use the API."

Your effective mode is resolved from the first scope that has an opinion, in the order project, then account, then the model's own default. Since inherit is the factory setting for new accounts and projects, a fresh account inherits all the way down to the model default, which for most models means nothing is kept.

Reading your current setting is a GET on /v1/data_retention; a project's is a GET on its project route. Both are documented with worked curl examples on the retention page, and a per-model GET returns that model's effective mode alongside the modes it accepts, which is the fastest way to answer "will this model work for us" without discovering it in production.

If you cannot accept 30 days#

Three routes exist, and they are not equivalent.

You can be granted an exemption. AWS evaluates zero data retention "on a per-account, per-model basis in coordination with the model provider", and for Claude specifically routes eligibility to Anthropic rather than handling it itself. An approved account sees none appear in that model's accepted modes.

You can qualify for the Enterprise Frontier Safeguards program, which AWS says receives zero data retention through December 31, 2026. Note the date: after it, "all traffic will be retained for up to 30 days for automated offline abuse detection" like everyone else. It is a deferral, not a carve out.

Or you can enforce a ceiling. The write actions publish a condition key, and AWS documents a service control policy that denies any attempt to set aws_review or provider_data_share organisation wide. The stated effect is that models requiring human review appear as unavailable to every account under the policy. That is a real answer for a regulated environment: you lose the two models and you gain a guarantee nobody can turn them on.

One thing to check before choosing: if you use cross-region inference, retained inputs and outputs are stored in the destination region, meaning the region your request was processed in rather than the one you called. For anyone with data residency obligations that is the detail that decides it, and it is one line on each page.

The honest summary#

Bedrock's default posture is better than most of the industry's, and the two exceptions are disclosed rather than buried. What is worth knowing is the shape of the trade: not "AWS might read some of your prompts", but "everything you send these two models is kept for a month, machine-scanned, and a flagged subset may be read by a person, and you cannot use them otherwise".

Whether that is acceptable is a question about your data, not about AWS. If it is not, the local and cloud trade-off is the next thing to work through, with the security cost of running a model yourself priced in honestly, because self-hosting moves the risk rather than removing it. If it is acceptable, the thing to do today is read your account's current mode before you need it, and check it against what the workload actually costs to run.

The pattern here is not new. It is the same one Mistral set when it trained on user chats by default: the setting exists, it is documented, it is reachable, and almost nobody looks until something makes them.