AWS Builder Center

Builder Center

Isolate Claude Fable 5 Data Retention with Mantle Projects

Create a dedicated Bedrock project for Fable 5 with provider_data_share, keeping production workloads under zero-retention. Includes IAM lockdown.

Andrea Gallo

AWS Solutions Architect

Introduction

Claude Fable 5 is Anthropic's latest Mythos-class model, purpose-built for multi-day autonomous coding, advanced vision, and long-horizon agentic workflows. To access Fable 5 on Amazon Bedrock, you must opt into  provider_data_share  mode, which allows inference data to be retained and shared with Anthropic per their model requirements.
Important: There is no data retention change to models released before Claude Fable 5. Your existing Bedrock workloads (Opus, Sonnet, Haiku) remain unaffected.
While enabling  provider_data_share  at the account level is technically safe for most models (each model's  allowed_modes  determines whether data is actually shared, see  Data Retention ), it may create unnecessary questions during compliance reviews. For organizations subject to regulatory oversight, isolating data retention at the project level provides auditable clarity: your compliance team can point to a single, dedicated project where data sharing is explicitly enabled, separate from your production workloads which continue to operate under zero-retention.
Mantle Projects provide that boundary. In this guide, we'll walk through:
  1. Creating a dedicated project for Fable 5 with  provider_data_share  enabled
  1. Keeping your account default at  default  so other models remain at their standard retention policy
  1. Using IAM policies to restrict the project to Fable-only invocations
By the end, you'll have a clean separation: Fable 5 accessible in a dedicated project with explicit data sharing, all other workloads operating under their standard policies, and IAM enforcement ensuring the boundaries stay in place.

Prerequisites

  • An AWS account with Amazon Bedrock access
  • A Bedrock API key (generated from the Bedrock console)
  • IAM permissions including  bedrock-mantle:*  actions on the API key's backing IAM user
  •  curl  installed (all steps use curl commands)
Note: This guide uses a Bedrock API key for simplicity. The same operations can be performed using AWS SigV4 authentication (IAM credentials via the AWS CLI or SDK). If your organization prefers IAM-based access over static keys, substitute  x-api-key  headers with SigV4-signed requests using  awscurl  or  boto3 .
Important: Long-term Bedrock API keys are created with a restricted default policy that only permits get and list operations. To complete the steps in this guide, you must attach an additional inline policy to the backing IAM user granting at minimum:  bedrock-mantle:CreateProject ,  bedrock-mantle:UpdateProject ,  bedrock-mantle:CreateInference , and  bedrock-mantle:GetAccountDataRetention . For simplicity, you can grant  bedrock-mantle:*  on  Resource: "*" 

Understanding Data Retention Modes

Amazon Bedrock provides three data retention modes:
Mode
Behavior
default
The model's own retention policy applies. For most models, this means zero data retention. AWS may retain data for safety/abuse prevention only. Model providers do NOT receive it.
none
Zero data retention. Nothing is written to durable storage or shared with model providers.
provider_data_share
AWS retains and shares inference data with the model provider per their requirements. Required for Fable 5 and Mythos 5.
Setting  provider_data_share  at the project level does NOT mean all model traffic in that project is shared with providers. Each model's  allowed_modes  determines what actually happens:
  • A model whose  allowed_modes  is  ["provider_data_share"]  (e.g., Claude Fable 5) - data is retained and shared with the provider.
  • A model whose  allowed_modes  is  ["default", "provider_data_share"]  (e.g., Claude Opus 4.8) - data is retained by AWS only. The model accepts  provider_data_share  as a valid mode but does not require data to leave AWS's boundary. ( source )
This distinction is critical: even if your project is set to  provider_data_share , only models that exclusively require it (Fable 5, Mythos 5) will actually share data. All other models continue to operate under their standard data handling.

Setting up Project Isolation

Now that you understand how modes work, here's how we'll configure your account to isolate Fable 5 into its own project

Step 1: Verify Your Account is at Default

First, confirm your account-level data retention is set to  default :
Bash
curl -s "https://bedrock-mantle.us-east-1.api.aws/v1/data_retention" \
  -H "x-api-key: $BEDROCK_API_KEY"

Expected response:
JSON
{"mode": "default", "updated_at": 1781213635}


Step 2: Confirm Fable 5 is Unavailable at Account Level

With the account at  default , calling Fable 5 should be blocked:
Bash
curl -s "https://bedrock-mantle.us-east-1.api.aws/anthropic/v1/messages" \
  -H "x-api-key: $BEDROCK_API_KEY" \
  -H "Content-Type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -d '{"model":"anthropic.claude-fable-5","max_tokens":50,"messages":[{"role":"user","content":"Hello"}]}'

Expected response:
JSON
{
  "type": "error",
  "error": {
    "type": "invalid_request_error",
    "message": "data retention mode 'default' is not available for this model"
  }
}

This confirms: Fable 5 requires an explicit opt-in to  provider_data_share .

Step 3: Create a Dedicated Project for Fable 5

Create a new Mantle project specifically for Fable workloads:
Bash
curl -s -X POST "https://bedrock-mantle.us-east-1.api.aws/v1/organization/projects" \
  -H "x-api-key: $BEDROCK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "fable-workspace",
    "tags": {
      "Purpose": "Fable5-isolated",
      "DataRetention": "provider_data_share"
    }
  }'

Expected response:
JSON
{
  "arn": "arn:aws:bedrock-mantle:us-east-1:123456789012:project/proj_xxxxxxxxxxxxxx",
  "id": "proj_xxxxxxxxxxxxxx",
  "name": "fable-workspace",
  "data_retention": {"mode": "inherit"},
  "status": "active",
  "tags": {"Purpose": "Fable5-isolated", "DataRetention": "provider_data_share"}
}

Note the project ID ( proj_xxxxxxxxxxxxxx ), you'll need it for the following steps.
Note: The project is created with  data_retention: inherit  by default. We'll set it explicitly in the next step.

Step 4: Enable Data Sharing on the Project

Set the project's data retention mode to  provider_data_share :
Bash
curl -s -X POST "https://bedrock-mantle.us-east-1.api.aws/v1/organization/projects/proj_xxxxxxxxxxxxxx" \
  -H "x-api-key: $BEDROCK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"data_retention": {"mode": "provider_data_share"}}'

Expected response confirms the update:
JSON
{
  "id": "proj_xxxxxxxxxxxxxx",
  "data_retention": {"mode": "provider_data_share"},
  "status": "active"
}


Step 5: Invoke Fable 5 from the Project

Now call Fable 5 using the  anthropic-workspace-id  header to target the project:
Bash
curl -s "https://bedrock-mantle.us-east-1.api.aws/anthropic/v1/messages" \
  -H "x-api-key: $BEDROCK_API_KEY" \
  -H "Content-Type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-workspace-id: proj_xxxxxxxxxxxxxx" \
  -d '{"model":"anthropic.claude-fable-5","max_tokens":100,"messages":[{"role":"user","content":"Hello from the Fable workspace!"}]}'

✅ Success, Fable 5 responds.

Step 6: Verify Isolation, Fable Remains Blocked at Account Level

Without the  anthropic-workspace-id  header (targeting the default project), Fable should still be blocked:
Bash
curl -s "https://bedrock-mantle.us-east-1.api.aws/anthropic/v1/messages" \
  -H "x-api-key: $BEDROCK_API_KEY" \
  -H "Content-Type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -d '{"model":"anthropic.claude-fable-5","max_tokens":50,"messages":[{"role":"user","content":"Hello"}]}'

Expected:  "data retention mode 'default' is not available for this model" 
✅ Confirmed, Fable 5 is only accessible through the dedicated project.

Step 7: Restrict the Project to Fable-Only (IAM Policy)

At this point, any model can be called from the fable-workspace project. To ensure only Fable 5 is used there (preventing accidental access from other workloads), attach an IAM Deny policy to the API key's backing IAM user:
IAM Console → Users → [your Bedrock API key user] → Permissions → Add inline policy → JSON:
JSON
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNonFableInFableProject",
      "Effect": "Deny",
      "Action": "bedrock-mantle:CreateInference",
      "Resource": "arn:aws:bedrock-mantle:us-east-1:123456789012:project/proj_xxxxxxxxxxxxxx",
      "Condition": {
        "StringNotEquals": {
          "bedrock-mantle:Model": "anthropic.claude-fable-5"
        }
      }
    }
  ]
}

This policy uses the  bedrock-mantle:Model  condition key to deny any inference request that isn't Fable 5, but ONLY for the fable-workspace project. All other projects remain unrestricted.

Verify the restriction:

Call Haiku from fable-workspace (should be BLOCKED):
Bash
curl -s "https://bedrock-mantle.us-east-1.api.aws/anthropic/v1/messages" \
  -H "x-api-key: $BEDROCK_API_KEY" \
  -H "Content-Type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-workspace-id: proj_xxxxxxxxxxxxxx" \
  -d '{"model":"anthropic.claude-haiku-4-5","max_tokens":50,"messages":[{"role":"user","content":"Hello"}]}'

Expected:
JSON
{
  "type": "error",
  "error": {
    "type": "permission_error",
    "message": "User is not authorized to perform: bedrock-mantle:CreateInference ... with an explicit deny in an identity-based policy"
  }
}

Call Fable from fable-workspace (should still WORK):
Bash
curl -s "https://bedrock-mantle.us-east-1.api.aws/anthropic/v1/messages" \
  -H "x-api-key: $BEDROCK_API_KEY" \
  -H "Content-Type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-workspace-id: proj_xxxxxxxxxxxxxx" \
  -d '{"model":"anthropic.claude-fable-5","max_tokens":50,"messages":[{"role":"user","content":"Hello from Fable!"}]}'

✅ Success, the project is now locked to Fable-only.

Things to Know

Organization-wide governance with SCPs

If your organization requires zero data retention across all accounts, you can enforce this with a Service Control Policy:
JSON
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnforceZDR",
      "Effect": "Deny",
      "Action": [
        "bedrock-mantle:PutAccountDataRetention",
        "bedrock-mantle:UpdateProject"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "bedrock-mantle:DataRetentionMode": "none"
        }
      }
    }
  ]
}

This prevents anyone in the organization from enabling  provider_data_share , except through a specific exception process for approved accounts.

Compliance considerations

If your organization requires zero data retention for compliance reasons (e.g., HIPAA, BAA) and also needs access to Fable 5, work with your AWS Account Team to evaluate options.

References

# amazon-bedrock# anthropic-claude# iam
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article