AWS Bedrock Mythos 30-Day Retention: The IT Playbook

A long row of dark server racks lit by blue indicator lights in a hyperscale data center — Photo via Unsplash

TL;DR: On June 9, 2026, AWS made Claude Fable 5 available on Amazon Bedrock. To use it, you must opt into a new data retention mode called provider_data_share, which retains your prompts and completions for up to 30 days and shares them with Anthropic. There is no console UI for the setting. The new behavior is documented in three places that have to be read together to make sense: the AWS blog post by Channy Yun, the AWS Service Terms section 50.12.2 (Abuse Detection) and 50.12.2.2 (Anthropic transfer consent), and the AWS Bedrock data retention documentation. The new AWS Bedrock abuse detection page makes the 30-day window explicit: "For Anthropic Claude Fable 5, inputs and outputs will be retained for up to 30 days. In order to use Claude Fable 5, as required by Anthropic, you must opt in to sharing retained traffic with Anthropic for abuse detection and potential human review." If you are an enterprise IT decision-maker, this article is the technical and contractual deep-dive. The WIRED and Verge apology story we covered separately is the consumer-facing one. This one is the line-developer-to-CISO version: actual API calls, the four retention modes, the IAM condition key, the cross-region inference rule, the fallback rule for safety-classifier redirects to Opus 4.8, and the path to request ZDR (zero data retention) access if your compliance team cannot accept the 30-day window.

What the AWS Service Terms Actually Say

The 30-day retention rule is in AWS Service Terms section 50.12, the Bedrock-specific addendum. The relevant subsections, in plain text:

50.12.2 (Abuse Detection): "For certain models identified on the Bedrock abuse detection page, as part of providing the Service, Amazon Bedrock stores Service inputs and outputs for up to 30 days (unless otherwise required by law) solely to detect activity that violates our, or third-party model providers', terms of service or use policies. If we detect a potential violation, you agree and instruct that we may review the Service inputs and outputs to determine if a violation has occurred."^[1]

50.12.2.2 (Anthropic transfer consent): "Certain Anthropic models identified on the Bedrock abuse detection page require you to consent to the transfer of Your Content and associated metadata to Anthropic for abuse detection, via the opt-in mechanism described in the applicable service documentation. By providing such consent, you instruct AWS to transfer Your Content and associated metadata to Anthropic for processing in accordance with Anthropic's Data Processing Addendum."^[1]

Read the two together. The 30-day window is the default for "certain models identified on the Bedrock abuse detection page." The Anthropic transfer is a separate consent. Fable 5 and Mythos 5 are the first two models that require both. The Anthropic support documentation, updated June 11, 2026, calls out the same dual structure: "This change only applies to organizations that have set up workspaces with zero data retention (ZDR) in Claude Console, use Claude Code with ZDR in Claude Enterprise, or access Claude through AWS Bedrock, Google Cloud Agent Platform, or Microsoft Foundry with ZDR. For all other organizations, there is no change and there's nothing to configure."^[2] Translated: if you were already on a default AWS account that retains data, the new policy is invisible to you. If you went out of your way to set up ZDR, you are the customer the new rule actually affects.

Two other contract terms matter for the enterprise IT review. 50.12.4 (Customized models): "Third-party model providers cannot access your customized model. We will not access or use your customized model except as necessary to maintain or provide the Amazon Bedrock Service, or as necessary to comply with the law or a binding order of a governmental body."^[1] This is the existing protection for fine-tuned models, and it is unchanged. 50.12.5 (Usage telemetry): "We may share information, that does not include Your Content, about your use of a third-party model with the provider of that third-party model."^[1] Usage metadata, not content, can flow back to Anthropic regardless of retention mode. That is a separate conversation your privacy team should be aware of, but it is not new in the Fable 5 launch.

The Data Flow: From Prompt to Anthropic Reviewer

Here is the end-to-end flow for an inference call to Fable 5 on Amazon Bedrock, in five steps. The flow is documented across the AWS blog, the AWS data retention documentation, and the Anthropic support article. None of the five steps is speculative.

Customer request. Your application calls the Bedrock API. The endpoint is either bedrock-mantle.us-east-1.api.aws (the new data plane, bearer-token or API-key auth) or bedrock.us-east-1.amazonaws.com (the control plane, SigV4 auth). The model ID is anthropic.claude-fable-5 or global.anthropic.claude-fable-5 for cross-region inference.^[3][4]
Retention check. AWS checks the effective data retention mode for the request. If your effective mode is none or default, the Fable 5 model will appear as "status": "unavailable" in the models list. To invoke Fable 5 or Mythos 5, your effective mode must be provider_data_share.^[3]
Inference and retention. The model processes the request. The full prompt and the full completion are written to durable storage inside the AWS account, retained for up to 30 days. The storage lives in the inference destination region (the region where the model actually ran), not the source region. If you enabled cross-region inference, the destination region is wherever AWS routed your request.^[3][5]
Transfer to Anthropic. Because your effective mode is provider_data_share, AWS transfers the retained prompt and completion to Anthropic. The transfer is governed by Anthropic's Data Processing Addendum (DPA), not just the AWS DPA. Anthropic's documentation describes the DPA-bound processing: "Data submitted through the Services will be processed in accordance with the Anthropic Data Processing Addendum (DPA), which is incorporated into these Terms by reference."^[6]
Classifier and human review. Anthropic runs automated classifiers over the retained traffic. The classifiers look for "patterns of misuse that are not visible from a single exchange." Specific examples Anthropic names: best-of-N jailbreaking, state-sponsored espionage, data extortion campaigns. Flagged conversations can be reviewed by a small set of approved reviewers through tooling that prevents export, copying, or downloading. Every access is recorded in a tamper-proof log. After 30 days the data is auto-deleted, except in rare cases where it is part of an active safety investigation or a legal hold.^[2]

Two footnotes change the flow in practice. First, the Anthropic support article says the retained data for Bedrock customers "stays in AWS": "Through Amazon Bedrock: Retention will need to be enabled to access your new covered model, and retained data stays in AWS."^[2] That language is the one Anthropic added on June 11 in response to the June 9 announcement. The June 9 AWS blog post said the data "leaves AWS's data and security boundary" and that the data goes to Anthropic for human review. The two statements describe the same architecture with different emphasis. The data is stored in your AWS account. Anthropic reviewers can read the data. For most enterprise compliance teams, the second fact is the one that matters.^[2][3] Second, the safety-classifier fallback path does not share with Anthropic. If a Fable 5 request is declined by a safety classifier and the fallback credit is redeemed on Claude Opus 4.8, the fallback invocation follows Opus 4.8's data-handling rules, not Fable 5's. The Opus 4.8 response is not retained or shared with Anthropic.^[3] This is the only path through Fable 5 that does not trigger the 30-day retention with provider sharing.

The Four Data Retention Modes

The AWS Bedrock Data Retention API exposes four modes, documented in the Bedrock user guide and the abuse detection page.^[3][5] The mode is set at one of two scopes (project or account), and the effective mode for any request is the first non-inherit value in the chain: project, then account, then model default.

inherit (default for new accounts and projects). No opinion at this scope. The system defers to a broader scope. If everything is inherit, the model default applies.^[3]

default. The data retention policy of the model applies. If ZDR applied previously, ZDR still applies. Actual retention depends on the model; consult the model's terms. AWS may retain the data for safety and abuse-prevention purposes. The model provider does not receive it.^[3] Important nuance from the docs: "Setting store=false does not guarantee zero data retention. Some models may still retain data for safety review even when store=false. If you require guaranteed zero retention, set data_retention_mode to none."^[3] The Responses API's store=false parameter does not do what it sounds like for every model.

provider_data_share. This mode allows Amazon Bedrock to retain and share your inference data with model providers per their requirements. It is required for access to certain models. The current list of models that require it is Claude Fable 5 and Claude Mythos 5. For these models, the data is retained for up to 30 days for trust and safety purposes and is shared with Anthropic.^[3][5]

none. Zero data retention. No request or response data is written to durable storage by AWS or shared with the model provider. On the Responses API, store defaults to false and store=true is rejected. Background mode is not available. Chat Completions and Messages requests are never retained.^[3] The model documentation page says: "If a model's allowed_modes includes none, we won't persist anything."^[3] For most models, including Claude Opus 4.8, none is one of the available modes. For Fable 5 and Mythos 5, it is not. You have to request ZDR access to get it added to allowed_modes for those specific models.^[3]

To check what a specific model supports, call the model metadata endpoint. The response will list allowed_modes and the current effective mode. Example response for Fable 5 with the account mode set to default:^[3]

{
  "id": "anthropic.claude-fable-5",
  "created": 1733443200,
  "owned_by": "system",
  "status": "unavailable",
  "status_reason": "This model is not available under data retention mode 'default'.",
  "data_retention": {
    "mode": "default",
    "source": "account",
    "allowed_modes": ["provider_data_share"]
  }
}

Three things to read out of that response. First, the status field is "unavailable". You cannot invoke the model. Second, the status_reason is human-readable and tells you exactly why. Third, allowed_modes is a list of one entry. For Fable 5, the only mode that satisfies the requirement is provider_data_share. If your effective mode does not match, the model is unavailable, and the API tells you so in plain English.

The API Calls You Need to Know

The Data Retention API lives on two different control planes, with different authentication, depending on whether you are calling the data plane or the AWS control plane. Both do the same thing. AWS added the SigV4 / AWS CLI path on June 10, 2026, in response to enterprise customer requests; the bearer-token path was the only option on June 9.^[3][4]

Set account-wide mode (data plane, bearer or API key):^[3]

curl -X PUT https://bedrock-mantle.us-east-1.api.aws/v1/data_retention \
  -H "x-api-key: $BEDROCK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "mode": "provider_data_share" }'

Response:

{
  "mode": "provider_data_share",
  "updated_at": 1733529600
}

Set account-wide mode (control plane, bearer token):^[4]

curl -X PUT https://bedrock.us-east-1.amazonaws.com/data-retention \
  -H "Authorization: Bearer $AWS_B...OCK" \
  -H "Content-Type: application/json" \
  -d '{ "mode": "provider_data_share" }'

Set account-wide mode (control plane, AWS SigV4):^[4]

curl -s -X PUT https://bedrock.us-east-1.amazonaws.com/data-retention \
  --aws-sigv4 "aws:amz:us-east-1:bedrock" \
  --user "$AWS_ACCESS_KEY_ID:$AWS_SECRET_ACCESS_KEY" \
  -H "x-amz-security-token: $AWS_SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"mode":"provider_data_share"}'

AWS CLI equivalent:^[4]

aws bedrock put-account-data-retention \
  --mode provider_data_share

Check current setting (data plane):^[3]

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

A new account returns {"mode":"inherit","updatedAt":null}.^[4] That is the default. inherit means the system defers to the broader scope. If everything is inherit, the model default applies. For Fable 5, the model default is provider_data_share, so a new account can invoke Fable 5 without changing anything. The catch: inherit as a default is convenient for the customer who does not read the docs. The customer who reads the docs has to deliberately set the account or project to none or default if they want to opt out of provider sharing at the model level.^[3]

Set project-level mode:^[3]

curl https://bedrock-mantle.us-east-1.api.aws/v1/organization/projects/proj_abc123 \
  -H "x-api-key: $BEDROCK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "data_retention": { "mode": "provider_data_share" } }'

The project-level setting is the right tool for a mixed-model environment. If you have one AWS account with ten projects, and only one project needs Fable 5, set the project to provider_data_share and leave the account at default or none. The other nine projects keep their existing data handling. The project scope is also the right tool for an enterprise with a regulated workload and a non-regulated workload in the same account.^[3]

Locking It Down with IAM and Service Control Policies

If you do not want individual developers in your AWS organization to flip their account to provider_data_share on their own, you can deny the action with an IAM policy or an AWS Organizations Service Control Policy (SCP). The condition key for the data plane is bedrock-mantle:DataRetentionMode. The condition key for the control plane is bedrock:DataRetentionMode.^[3]

Example SCP that requires zero data retention across the entire organization (data plane):^[3]

{
    "Effect": "Deny",
    "Action": [
        "bedrock-mantle:PutAccountDataRetention",
        "bedrock-mantle:CreateProject",
        "bedrock-mantle:UpdateProject"
    ],
    "Condition": {
        "StringNotEquals": {
            "bedrock-mantle:DataRetentionMode": "none"
        }
    }
}

Same idea, control plane version:^[3]

{
    "Effect": "Deny",
    "Action": [
        "bedrock:PutAccountDataRetention"
    ],
    "Condition": {
        "StringNotEquals": {
            "bedrock:DataRetentionMode": "none"
        }
    }
}

The Bedrock IAM action reference, in full, is:^[3]

bedrock-mantle:ListModels (GET /v1/models)
bedrock-mantle:GetModel (GET /v1/models/{model})
bedrock-mantle:GetAccountDataRetention (GET /v1/data_retention)
bedrock-mantle:PutAccountDataRetention (PUT /v1/data_retention)
bedrock-mantle:GetProject (GET /v1/organization/projects/{project_id})
bedrock-mantle:UpdateProject (POST /v1/organization/projects/{project_id})
bedrock:GetAccountDataRetention (GET /data-retention, control plane)
bedrock:PutAccountDataRetention (PUT /data-retention, control plane)

The IAM actions enforce the policy decision; the condition key is what makes it actually do something. The example SCP says: any principal trying to set the account or project retention mode to anything other than none is denied. Combined with the none mode being a valid choice for most models, that SCP means no developer in the organization can opt into provider_data_share on their own. To get Fable 5 access, the developer needs a project that the SCP excludes, or the SCP needs an exception for a specific role or OU. This is the right architecture for a regulated industry that needs an exception process for Fable 5 use, rather than an allow-by-default posture.^[3]

The ZDR Negotiation Playbook

The most important sentence in the AWS documentation for a regulated-industry CISO is in the data retention user guide, not the API reference. It is the only path to Fable 5 access without 30-day provider sharing:^[3]

"If your organization requires zero data retention for compliance reasons and you need access to these models, contact your AWS account manager to discuss eligibility. ZDR access is evaluated on a per-account, per-model basis in coordination with the model provider."^[3]

Three things to read out of that. First, ZDR for Fable 5 is a per-account, per-model exception. It is not a self-serve toggle. You cannot write a script that flips it. You contact your AWS account manager. Second, the eligibility evaluation is "in coordination with the model provider." That means Anthropic is in the loop. Anthropic's own support article lists the same ZDR pathway and adds one concrete option: "Eligible organizations also have the option to add customer-managed encryption keys and access transparency audit logs."^[2] Customer-managed keys (CMK) and access transparency are the two AWS mechanisms that give the customer a way to verify that AWS (and by extension Anthropic's reviewers on AWS) is not reading data they should not be reading. The access transparency log gives you a record of every time an AWS operator or Anthropic reviewer accesses the data. The CMK gives you the option to revoke the key, which makes the data unreadable in practice. Third, the cross-region inference rule still applies: "If cross-region inference is enabled for these models, retained inputs and outputs are stored in destination regions."^[3] If you care about data residency, you need to check whether cross-region inference is enabled for your account, and what destination regions your requests are routed to. The data flows to the destination region, not the region you think you are calling from.

The actual negotiation playbook, in the order a real CISO should run it:

Map the workload. Inventory which internal applications, agents, and developer sandboxes would actually need Fable 5 or Mythos 5. Most enterprise workloads are fine on Claude Opus 4.8 (or earlier generations), which has full ZDR by default. The 30-day retention with provider sharing is only triggered for Fable 5 and Mythos 5 specifically.^[3][5]
Decide on the scope. If only one team or one project needs Fable 5, set the project scope to provider_data_share and leave the account at none or default. The other projects keep their existing data handling. This is the smallest-blast-radius approach.^[3]
Audit your cross-region inference settings. Cross-region inference is enabled by default for many AWS accounts. If you have it on, the retained data is stored in the destination region, not the source region. For EU customers who thought they were processing data inside Frankfurt or Stockholm, cross-region inference can route requests to US East (N. Virginia) and store the retained data there. The 30-day retention then lives in the US, not the EU. That is a GDPR-relevant data residency question your DPO should answer before you turn on Fable 5.^[3][5][7]
Lock down with SCPs. If your organization uses AWS Organizations, write an SCP that denies any non-none retention mode outside of an explicit exception list. The exception list is the projects that have been approved for Fable 5 use, the roles that can update those projects, and the regions the projects are allowed to use.^[3]
Open a ticket with your AWS account manager for ZDR eligibility. If your compliance team cannot accept 30-day retention with provider sharing, ask. The ZDR access path is per-account, per-model, and requires Anthropic coordination. Expect to provide a written justification, a list of the compliance frameworks that prohibit the default, and a list of the alternative safeguards you have already implemented (encryption, access controls, audit logging, data minimization). The Anthropic support article confirms that customer-managed encryption keys and access transparency audit logs are available options for eligible customers.^[2][3]
Update your DPA inventory. Anthropic's support article is explicit: the transfer is governed by Anthropic's DPA, not just the AWS DPA. If your data processing agreements register subprocessors, you need to confirm that the Anthropic transfer is captured in your Article 28 (GDPR) subprocessors list, your CCPA service provider list, and your state-level privacy law equivalents (Colorado, Connecticut, California, and the July 1 amendments to all three).^[2][6][8]
Read the safety-classifier fallback path. The fallback to Opus 4.8 on safety-classifier redirects does not share with Anthropic and does not trigger 30-day retention. If your application is sensitive to retention, consider routing the safety-sensitive portion of the workflow through Opus 4.8 and reserving Fable 5 for the tasks that actually need Mythos-class capability. The pricing is the same: you pay Fable rates for the initial tokens and Opus rates for the fallback tokens. The AWS blog spells this out.^[3][4]
Document the decision in your model card or AI system registry. If you are subject to the EU AI Act, Colorado AI Act (effective June 30, 2026), or any state-level transparency law, the choice to use Fable 5 with provider data sharing is a data-handling decision that has to be documented in the system record. The system card and the DPA addendum are the two artifacts a regulator will ask for.^[9][10]

How Bedrock Compares to the Other Anthropic Surfaces

The Anthropic support article is explicit that the 30-day retention with provider sharing applies across every Anthropic surface, with platform-specific differences:^[2]

Claude Console (direct API): Turn on retention for the workspaces where you want to use covered models in the developer console (Workspace > Manage > Privacy Controls). Your other ZDR-enabled workspaces keep ZDR.^[2]
Claude Platform on AWS (not Bedrock): Retention is configured at the workspace level, same as the direct Claude API. Retained data is handled by Anthropic under the same controls.^[2]
Amazon Bedrock: Retention enabled via the new Data Retention API. Retained data stays in AWS (per the June 11 Anthropic support language), but Anthropic reviewers can access flagged content.^[2]
Google Cloud Agent Platform: Retention enabled, retained data stays in the GCP environment. Same Bedrock-style data flow but on Google Cloud.^[2]
Microsoft Foundry (Azure): Retention is configured per Azure Subscription. If you have ZDR configured, you have to create and use a separate Azure Subscription to access covered models. This is the strictest of the three clouds.^[2]
Claude Code: Data handling follows the workspace it operates in. If the workspace has retention enabled, Claude Code can use covered models. Bedrock and Google Cloud Agent Platform versions of Claude Code follow the cloud environment's retention setting.^[2]
Claude Enterprise chat or Cowork: Already operates with standard retention, so covered models are accessible without a configuration change.^[2]

The Bedrock implementation is the most enterprise-friendly of the three clouds, because the retention is set at the account or project level, can be locked down with IAM, and gives you the option to use customer-managed keys and access transparency audit logs. The Azure implementation is the strictest, requiring a separate subscription. The Google Cloud implementation is the middle path, similar to Bedrock but with GCP's identity and access management primitives instead of IAM. If you are a multi-cloud shop, the cross-cloud consistency is helpful: the same Anthropic reviewer pool sees the same content regardless of which cloud the data lives in, because the data transfer is from the cloud to Anthropic, not from one cloud to another.^[2]

The Bigger Picture: Why the 30-Day Window Matters Beyond Fable 5

The Bedrock data retention documentation has one paragraph that every enterprise customer should read twice:^[3]

"There is no data retention change to models released before Claude Fable 5. AWS is committed to making sure that you are in full control over when and with whom your data is retained and shared."^[3]

That statement is doing a lot of work. It is a commitment that the Fable 5 launch is a one-time, well-defined event, not the start of a slow drift. It is also an implicit promise that the provider_data_share mode will not be quietly added to the allowed_modes list of older models. If AWS or Anthropic changed that, the contract would be the document to point at.

But the Fable 5 launch is also the first time a frontier-class model on Bedrock has required provider sharing. Every future model that joins the Mythos class will inherit the same architecture. The materials in this article are the template for what that future model will look like. If you build your ZDR negotiation playbook now, you will be ready when AWS adds Mythos 6, Fable 6, or the next OpenAI model that requires the same opt-in. The HN comment thread on the Fable 5 launch, which hit 418 points on the front page, included at least one commenter noting that the same 30-day window now applies to "OpenAI GPT-5.4 and GPT-5.5 models" on Bedrock.^[5][11] The Bedrock abuse detection page is structured to absorb new models over time. The 30-day window is the new normal for the highest-capability models on the platform.

The other thing to read into the architecture: the safety-classifier fallback path is the one place where the data does not leave AWS. The fallback to Opus 4.8 is documented in the data retention page:^[3] "When a Claude Fable 5 request is declined by a safety classifier and the fallback credit is redeemed on Claude Opus 4.8, the fallback invocation follows Opus 4.8's data-handling rules, not Fable 5's. The Opus 4.8 response is not retained or shared with Anthropic." If you are an enterprise architect designing a system that uses Fable 5, the design question is: which parts of the workflow need Mythos-class capability, and which parts can route through Opus 4.8 if a safety classifier fires? The answer changes the data flow. The answer changes the bill. The answer changes the audit trail. The answer is the kind of design decision that has to be documented in the system card, not made in a Slack thread.

What Else AWS Added on June 9

Two other facts from the AWS blog post are worth flagging for enterprise IT, even though they are not directly about retention.^[4]

Region availability at launch. Claude Fable 5 is available in US East (N. Virginia) and Europe (Stockholm) at launch. Claude Fable 5 on the Claude Platform on AWS is available in North America, South America, Europe, and Asia Pacific. The Bedrock regional gap is the same gap every other Anthropic model on Bedrock has had, but it is worth flagging for customers with EU-only data residency requirements: if you are using Bedrock from eu-central-1 or eu-west-1, your Fable 5 requests are routed to Stockholm (eu-north-1) or US East (us-east-1) under cross-region inference. The retained data is stored in the destination region. Confirm which destination your account is using before you turn Fable 5 on.^[3][4][5]

Model access is gradually expanding. The AWS blog notes that Fable 5 access is being rolled out gradually across AWS accounts. "If your account doesn't have access yet, it will be enabled soon depending on your Bedrock usage. If you want to get access to this model quickly, contact your usual AWS Support."^[4] If you are testing the API today and getting "status": "unavailable" for a reason other than the data retention mode, that is the reason. Contact AWS Support and ask for Fable 5 access on your account.

Pricing for the fallback path. The pricing documentation is specific about what happens when a safety classifier redirects to Opus 4.8: "When a harmful prompt is routed to Opus 4.8 instead of Fable 5, you pay only Opus prices. If a request is blocked mid-conversation, initial tokens are charged at Fable rates and subsequent tokens at Opus rates."^[4] For cost modeling, that means the safety-classifier fallback does not silently inflate your bill to Fable 5 rates. The mid-conversation block, where some tokens have already been processed by Fable 5 before the classifier fires, is the messy case: the initial tokens are Fable-priced, the rest are Opus-priced. Track this in your cost allocation.

What to Do Today

If you are an enterprise IT decision-maker reading this, the action list is short:

Audit your current Bedrock data retention posture. Run aws bedrock get-account-data-retention or call GET /v1/data_retention on the data plane. If you see {"mode":"inherit","updatedAt":null}, you are on the default, and Fable 5 is technically available to you because the model default is provider_data_share.^[3][4]
Map which workloads need Fable 5 vs Opus 4.8. Opus 4.8 is the previous flagship. It is still available, it is still capable, and it does not require provider data sharing. The Mythos-class jump is real for the workloads that need it, but the cost is the data layer.^[2][3]
Check your cross-region inference settings. Cross-region inference can route your Fable 5 requests to US East (N. Virginia) and store the retained data there, even if your account is based in Europe. That is a GDPR-relevant data residency question.^[3][5]
Lock down with SCPs. If you do not want individual developers opting the account into provider_data_share, write an SCP that denies anything other than none. Allow exceptions for specific projects that have been approved for Fable 5 use.^[3]
Open a ZDR eligibility ticket with your AWS account manager if your compliance team cannot accept 30-day provider sharing. ZDR access is per-account, per-model, requires Anthropic coordination, and can include customer-managed keys and access transparency audit logs. Expect a written justification.^[2][3]
Update your DPA inventory. The Anthropic transfer is governed by Anthropic's DPA, not just the AWS DPA. Add Anthropic to your subprocessors list if it is not there already.^[2][6]
Document the decision in your model card or AI system registry. If you are subject to the EU AI Act, the Colorado AI Act (effective June 30, 2026), or any state-level transparency law, the choice to use Fable 5 with provider data sharing is a data-handling decision that has to be on the record.^[9][10]

The Bottom Line

AWS Bedrock is the right place to run a frontier model if you are an enterprise that has already bet on AWS as your cloud. The data residency story is good for the models that do not require provider sharing, and it is reasonable for the models that do. The 30-day window with Anthropic sharing is the price of admission to the Mythos class. The price is documented. The price is configurable at the project level. The price can be negotiated down to ZDR for eligible customers. The price is not free, and it is not invisible.

The thing to take away from this article is not the API. The API is the easy part. The thing to take away is the structure of the negotiation. AWS gives you four retention modes, two scopes, an IAM condition key, a per-account ZDR exception process, customer-managed keys, access transparency logs, and a fallback path that does not share. Anthropic gives you a DPA, a tamper-proof reviewer log, automatic 30-day deletion, and an opt-in to eligible-organization encryption and audit. The structure is there. Use it.