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.

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.

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.