Configure AWS KMS for CMEK

The key policy grants Anthropic's IAM role cross-account access. Three statements are required:

1. Account root admin: the standard KMS pattern. Your account retains full admin control.
2. Anthropic encrypt and decrypt: the kms:Encrypt and kms:Decrypt actions, which Anthropic uses to encrypt and decrypt the data keys that protect your workspace data (envelope encryption).
3. Anthropic describe: the metadata read Anthropic performs at startup. It is granted separately because DescribeKey has no EncryptionContext parameter, so an EncryptionContext condition on this action would always deny.

export YOUR_ACCOUNT=$(aws sts get-caller-identity --query Account --output text)

aws kms create-key \
  --region <region> \
  --description "Anthropic CMEK" \
  --key-usage ENCRYPT_DECRYPT \
  --policy "{
    \"Version\": \"2012-10-17\",
    \"Statement\": [
      {
        \"Sid\": \"AccountRootAdmin\",
        \"Effect\": \"Allow\",
        \"Principal\": {\"AWS\": \"arn:aws:iam::${YOUR_ACCOUNT}:root\"},
        \"Action\": \"kms:*\",
        \"Resource\": \"*\"
      },
      {
        \"Sid\": \"AllowAnthropicCMEKCrypto\",
        \"Effect\": \"Allow\",
        \"Principal\": {\"AWS\": \"arn:aws:iam::915198916910:role/anthropic-cmek-client-us\"},
        \"Action\": [\"kms:Encrypt\", \"kms:Decrypt\"],
        \"Resource\": \"*\",
        \"Condition\": {
          \"StringEquals\": {
            \"kms:EncryptionContext:anthropic:compartment_uuid\": \"<compartment-uuid>\"
          }
        }
      },
      {
        \"Sid\": \"AllowAnthropicCMEKDescribe\",
        \"Effect\": \"Allow\",
        \"Principal\": {\"AWS\": \"arn:aws:iam::915198916910:role/anthropic-cmek-client-us\"},
        \"Action\": \"kms:DescribeKey\",
        \"Resource\": \"*\"
      }
    ]
  }"

Capture KeyMetadata.Arn from the output. You need it when you register the key in the next step.

The EncryptionContext condition is recommended but optional. Anthropic always includes your workspace's compartment ID in the encryption context, so ciphertext is cryptographically bound to that compartment regardless. Adding the condition provides defense-in-depth at the IAM layer. To start without it, omit the Condition block from the AllowAnthropicCMEKCrypto statement and add it later with kms:PutKeyPolicy.

You can also create the key from the AWS Console. Choose a symmetric key with the encrypt and decrypt key usage, a single-region key, and KMS key material origin. The Create-key wizard commits a key policy at its Review step: if you add Anthropic's account ID 915198916910 under key usage permissions there, the generated policy grants the whole Anthropic account broader actions (such as kms:ReEncrypt* and kms:GenerateDataKey*) with no EncryptionContext condition, and validation would still succeed against it. To avoid leaving an over-permissive key, finish the wizard with administrative permissions only, then open the key's Key policy tab and replace the JSON with the role-scoped policy shown above (the three statements scoped to the anthropic-cmek-client-us role, with the EncryptionContext condition).

Create an external key configuration through the Admin API.

curl -sS https://api.anthropic.com/v1/organizations/external_keys \
  -H "x-api-key: <anthropic-admin-api-key>" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "display_name": "<friendly-name>",
    "geo": "us",
    "provider_config": {
      "type": "aws",
      "kms_arn": "<key-arn-from-step-1>",
      "role_arn": "arn:aws:iam::915198916910:role/anthropic-cmek-client-us"
    }
  }'

The response contains the external key ID:

{
  "type": "external_key",
  "id": "ekey_<id>",
  "display_name": "<friendly-name>"
}

Trigger an encrypt and decrypt round-trip against your key.

curl -sS -X POST https://api.anthropic.com/v1/organizations/external_keys/ekey_<id>/validate \
  -H "x-api-key: <anthropic-admin-api-key>" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" -d '{}'

A successful response looks like this:

{ "type": "external_key_validation", "status": "success", "error": null }

If validation fails, common causes are:

• Encryption context mismatch: if you kept the EncryptionContext condition in the key policy, confirm you replaced <compartment-uuid> with your workspace's actual compartment ID (see step 1). A wrong or unsubstituted value makes KMS return an opaque AccessDeniedException. To rule it out, temporarily remove the Condition block from the AllowAnthropicCMEKCrypto statement and re-validate.
• Resource control policies (RCPs): if your AWS organization has an RCP that denies KMS operations when aws:PrincipalOrgID does not match your org, it blocks Anthropic's cross-account role. The RCP needs a carve-out for this key or for Anthropic's role ARN. Service control policies do not apply here, because they do not evaluate for external principals calling through resource-based policies.
• Access granted via IAM instead of the key policy: cross-account KMS access must be granted in the key policy itself, not through an IAM policy in your account. Check with aws kms get-key-policy --key-id <id> --policy-name default.
• Region mismatch: confirm the key's region is one Anthropic operates in for the geo tier you configured.