Claude Fable 5 on Bedrock Requires Sharing Inference Data with Anthropic

Using Anthropic's Claude Fable 5 or Mythos 5 on Amazon Bedrock requires opting into provider_data_share, a data retention mode that sends prompts and outputs to Anthropic for 30-day retention with human review. There is no alternative mode. The allowed_modes field for these models contains exactly one value.

For every previous model on Bedrock, including Opus 4.8, Sonnet, and Haiku, inference data stayed inside the AWS boundary, and model providers never saw it. That guarantee is what got Bedrock through procurement, legal review, and the security questionnaires that sit between a proof of concept and production. Fable 5 changes the deal.

The AWS blog post states it plainly at the bottom:

Once you opt into data retention, your data will leave AWS's data and security boundary.

Anthropic frames the 30-day retention as a safety requirement for Mythos-class models, needed to catch novel attacks and jailbreaks through their blocking classifiers. The company has indicated that future models at this capability tier will carry the same requirement. This is not an AWS decision. It is Anthropic's policy applied consistently across all platforms where Fable 5 and Mythos 5 are offered.

On Reddit, one commenter pushed back on conflating safety review with training data collection:

The key distinction worth parsing: this is for safety evaluation, not training the next model's weights. Anthropic retains inference data temporarily to detect misuse and research model behavior, not to fold it back into pretraining. Still a legitimate compliance concern for healthcare/finance, but it's a different threat model than "our prompts become part of future Claude."

Chris Farris, a cloud security researcher at Securosis, published a detailed critique arguing that AWS broke the core value proposition of Bedrock:

The entire value of AWS Bedrock was that it sat as the neutral place between companies and model providers. It guaranteed data and inference residency, and there was no possibility of your organization's data used by the model providers for their own purposes. Strip that away and AWS Bedrock is first-party Anthropic, with fewer features.

The governance implications are immediate. Anthropic becomes a sub-processor with access to inputs and outputs, including human review of flagged content. For regulated organizations, that means DPA amendments, an updated sub-processor list, a revisit of records of processing, and a fresh look at the legal basis for every workload pointed at these models. For European organizations specifically, Farris raised a concern about the CLOUD Act: Anthropic is a US company now deploying its most capable model in collaboration with the US government, putting retained data within reach of US legal requests.

One German practitioner on Reddit confirmed the impact:

This will be a deal breaker for us. And I would guess for a lot of German/European-based companies.

Healthcare organizations face an additional compliance gap. One Reddit commenter raised the question directly:

Will Anthropic provide a way to acquire a BAA with them via Bedrock then? We have health data and we can't legally share PII/PHI without a BAA. We have one with AWS which is why we use Bedrock.

Teams with an existing AWS BAA covering Bedrock inference now need to determine whether Anthropic's sub-processor status requires a separate agreement, one that may not yet exist for this data path.

The way it shipped drew the sharpest criticism. The data retention API call went live the same minute the models launched. There was no advance notice to security teams. The SCP pattern to block data sharing org-wide exists, using the bedrock-mantle:DataRetentionMode condition key, but it was buried in a docs subsection that got no announcement. Farris noted:

The capability got a megaphone. The guardrail didn't even get a footnote.

A separate monitoring gap compounds the problem. Here's the monitoring gap that makes this worse: bedrock-mantle logs to a completely different CloudTrail event source (bedrock-mantle.amazonaws.com) than regular Bedrock (bedrock.amazonaws.com). If your CSPM rules and security detectors are watching for Bedrock activity, they won't catch the data retention change. You have to add the Mantle event source explicitly.

AWS has since published isolation guidance through the Builder Center, recommending dedicated Bedrock projects for Fable 5 with provider_data_share while keeping production workloads under zero-retention. Farris documented an SCP pattern using the bedrock-mantle:DataRetentionMode condition key to deny any retention mode other than none org-wide, with exceptions scoped to specific accounts where an approved use case and signed-off DPA exist.

In a further development, on June 12, AWS updated the blog post to note that Anthropic has asked AWS to revoke access to Claude Fable 5 and Claude Mythos 5 for all users, citing compliance with a US Government export control directive. All other models, including Opus 4.8, remain unaffected. Teams that had already enabled provider_data_share at the account level during the three days the models were available should deploy Farris's SCP pattern to restore the default zero-retention posture.

The broader question for enterprises is whether this is a one-time exception for frontier safety models or a new normal. Anthropic has signaled it is the latter. Teams that chose Bedrock specifically because data never left the AWS boundary now face a choice: stay on Opus 4.8 and accept the capability gap, or move to frontier models and accept a fundamentally different data governance posture. That is a conversation for architects, legal, and compliance together, and it should have started before launch day, not after.