A managed identity is an identity in Microsoft Entra ID that Azure creates and maintains for a compute resource — an App Service site, an AKS workload, a Function app. The platform handles the credentials internally; your code just asks for a token at runtime. Since Claude on Microsoft Foundry supports Entra ID authentication (a bearer token in the Authorization header) alongside API keys, a managed identity can call your Claude deployment with zero secrets in code, config, or environment files.
System-assigned or user-assigned?
Azure offers two flavors. A system-assigned identity is created with, and bound to, a single resource: enable it on one Function app and it lives and dies with that app. A user-assigned identity is a standalone resource you create once and attach to many compute resources. For a single service calling Claude, system-assigned is the low-ceremony default. When a fleet of services should share one identity — one role assignment on the Foundry resource instead of a dozen — user-assigned earns its keep. Either way, the identity is what receives the RBAC role.
The three-step setup
Step 1 — enable the identity on your compute. App Service and Azure Functions expose an Identity setting where you switch on system-assigned or attach a user-assigned identity. On AKS, the equivalent pattern is workload identity, which maps a Kubernetes service account to an Entra identity — covered in depth in AKS workload identity for Foundry.
Step 2 — grant the inference role. On the Foundry resource's Access control (IAM) page, assign the data-plane role to the identity. Microsoft's documentation names Cognitive Services User; Anthropic's page says Foundry User or Cognitive Services User. The documented failure signature is precise: a 403 from the endpoint usually means this role assignment is missing.
Step 3 — use the token provider in code. Microsoft's samples use DefaultAzureCredential, which automatically picks up the managed identity when running on Azure (and falls back to your developer login locally), wrapped in get_bearer_token_provider and passed to the AnthropicFoundry client:
from azure.identity import DefaultAzureCredential, get_bearer_token_provider
from anthropic import AnthropicFoundry
token_provider = get_bearer_token_provider(
DefaultAzureCredential(),
"https://ai.cognitiveservices.com/.default",
)
client = AnthropicFoundry(
azure_ad_token_provider=token_provider,
base_url="https://example-resource.services.ai.azure.com/anthropic",
)
message = client.messages.create(
model="claude-sonnet-5",
max_tokens=1024,
messages=[{"role": "user", "content": "Hello from a managed identity"}],
)One documentation wrinkle to know: Microsoft's guide uses the token scope https://ai.cognitiveservices.com/.default, while Anthropic's uses https://ai.azure.com/.default. Both appear in official docs; if tokens are rejected with one scope in your environment, try the other and standardize on what works for your resource.
Why this beats keys — and one case where you can't choose
The wins compound. No plaintext key exists, so nothing can leak through source control or logs; access is revoked by removing a role assignment rather than rotating a shared string; every call is attributable to a specific identity, which makes RBAC and Conditional Access meaningful; and each service can carry exactly the access it needs. There is also a hard requirement lurking: Claude Mythos 5 and Mythos Preview on Foundry support Entra ID authentication only — no API keys — so identity-based auth is the only door for those gated models.
Troubleshooting the first call
Three failures cover most first attempts. A 403 means the token worked but the role is missing (step 2). A credential error from DefaultAzureCredential means the identity is not enabled or not attached where the code actually runs (step 1). A 401 with a valid identity suggests scope trouble — revisit the two documented scope strings above. For everything else, capture the request-id and apim-request-id headers that Foundry returns; support uses both to trace a request across Anthropic and Azure systems.
Where to go next
Pair this with RBAC roles for Foundry, see the Azure Functions integration, or keep keys safe where they must exist with Key Vault.