Configure Azure Key Vault for CMEK

This creates a service principal in your Entra tenant for Anthropic's CMEK client application. The application requests no Microsoft Graph permissions; it exists solely as a federation target for Key Vault data-plane access.

az ad sp create --id 8635ae1a-3e5d-44e8-a4ed-e0f614466f87

From the output, capture the id field. This is the service principal's object ID in your tenant, which you use when you assign the RBAC role.

{
  "appId": "8635ae1a-3e5d-44e8-a4ed-e0f614466f87",
  "displayName": "anthropic-cmek-client-us",
  "id": "<sp-object-id>"
}

If the service principal already exists in your tenant (from a prior attempt or another integration), az ad sp create exits with an "already exists" error. Fetch its object ID instead:

az ad sp show --id 8635ae1a-3e5d-44e8-a4ed-e0f614466f87 --query id -o tsv

This step has no Portal equivalent. If you do not have the Azure CLI installed locally, open Cloud Shell from the Portal's top navigation bar. After the command succeeds, you can find the service principal's object ID in Microsoft Entra ID > Enterprise applications by clearing the default application-type filter and searching for anthropic-cmek-client-us.

Azure Key Vault does not support symmetric key wrapping, so the key must be RSA (3072-bit or larger) with wrapKey and unwrapKey in its allowed operations.

az keyvault key create \
  --vault-name <your-vault-name> \
  --name <your-key-name> \
  --kty RSA --size 3072 \
  --ops wrapKey unwrapKey

For HSM-backed keys, use --kty RSA-HSM (requires a Premium-SKU vault). Software-protected RSA keys are acceptable for this integration.

From the Portal, open your Key Vault, select Keys, then Generate/Import. Set the key type to RSA and the size to 3072 or larger. To restrict the key to wrap and unwrap only, open the key version, scroll to Permitted operations, and uncheck everything except Wrap Key and Unwrap Key.

Assign the Key Vault Crypto User role to the service principal from the first step, scoped to the individual key rather than the whole vault.

VAULT_ID=$(az keyvault show --name <your-vault-name> --query id -o tsv)

az role assignment create \
  --role "Key Vault Crypto User" \
  --assignee-object-id <sp-object-id> \
  --assignee-principal-type ServicePrincipal \
  --scope "${VAULT_ID}/keys/<your-key-name>"

The built-in Key Vault Crypto User role grants key cryptographic operations (encrypt, decrypt, wrap, unwrap, sign, verify) plus key read on its assigned scope. The --ops wrapKey unwrapKey restriction you set on the key in the previous step further narrows which of those operations can succeed against this key, so in practice Anthropic can only wrap and unwrap.

From the Portal, open the key (not the vault), select its Access control (IAM) tab, click Add > Add role assignment, select Key Vault Crypto User, and assign it to the anthropic-cmek-client-us service principal.

az keyvault show --name <your-vault-name> \
  --query "{rbac:properties.enableRbacAuthorization, purge:properties.enablePurgeProtection, pub:properties.publicNetworkAccess, net:properties.networkAcls.defaultAction, ipRules:properties.networkAcls.ipRules, uri:properties.vaultUri, tenantId:properties.tenantId}"

Confirm that:

• rbac is true.
• purge is true. If it is false or null, enable purge protection on the vault before proceeding — without it, a soft-deleted key can be permanently purged during the retention window, making your CMEK-protected data unrecoverable.
• pub is "Enabled". If it is "Disabled", Anthropic cannot reach the vault over its public data-plane endpoint and validation fails.
• net is "Allow", or, if it is "Deny", that ipRules include Anthropic's egress ranges (contact Anthropic for the current list).
• uri is the vault URI you use when you register the key.
• tenantId is the tenant that governs the vault. Use this value as tenant_id when you register the key, not the tenant of your currently-active subscription (the two can differ in cross-tenant setups).

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": "azure",
      "vault_uri": "https://<your-vault-name>.vault.azure.net/",
      "key_name": "<your-key-name>",
      "tenant_id": "<your-tenant-id>"
    }
  }'

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. This confirms that Anthropic can authenticate to your tenant and perform wrap and unwrap operations.

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, the error field describes the problem. Common causes are:

• RBAC propagation delay: role assignments can take a few minutes to take effect. Wait and retry.
• Network ACLs blocking Anthropic: confirm public network access and ipRules as described in the verification step.
• Conditional access policies on workload identities: if your tenant has conditional access policies that target service principals, exclude the Anthropic service principal or add Anthropic's egress ranges to the policy's named locations.

Once the key is validated, attach it to a workspace to enable CMEK for that workspace's data.

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