Claude in Microsoft Foundry accepts two credentials against the same endpoint: an Azure-issued API key (sent in the api-key or x-api-key header) and a Microsoft Entra ID bearer token. The security difference between them is stark. Azure role-based access control (RBAC) applies only when callers authenticate with Entra ID; a key grants full access to the resource with no role restrictions at all. That is why Microsoft recommends Entra ID for granular control — and why mature deployments eventually disable key-based authentication outright, using the resource property disableLocalAuth. ("Local auth" is Azure's term for credentials local to the resource, i.e. its keys, as opposed to directory-issued identities.)
The switch itself
Setting disableLocalAuth: true makes the resource reject key-authenticated requests entirely, leaving Entra ID as the only door. Microsoft documents three ways to set it. The quickest is PowerShell:
Set-AzCognitiveServicesAccount `
-ResourceGroupName "my-rg" `
-Name "my-foundry-resource" `
-DisableLocalAuth $trueFor infrastructure-as-code shops, the same property is settable in a Bicep file or an ARM template on the account resource — which is the better long-term home for it, since it makes keyless-only a declared, reviewable property of the environment rather than a one-off command someone ran. If your team manages Foundry through templates already, see our ARM template guide and Terraform setup for where resource properties like this live.
Before you flip it: verify nothing still uses keys
Disabling local auth is instant and unforgiving: every caller still presenting a key starts failing authentication the moment it takes effect. The migration order that avoids a production incident:
1. Move every consumer to Entra ID first. The Anthropic SDK supports this natively — pass an azure_ad_token_provider (built from DefaultAzureCredential and get_bearer_token_provider) to AnthropicFoundry, with tokens acquired for the https://ai.azure.com/.default scope. Each caller also needs an RBAC role such as Foundry User or Cognitive Services User on the resource; a 403 after switching usually means the role assignment is missing. Role assignments can take up to 5 minutes to propagate. Details in the Entra ID auth guide.
2. Hunt for stragglers. Check anywhere a key could be hiding: the environment variables your deployments set (ANTHROPIC_FOUNDRY_API_KEY is auto-read by the SDKs, so a leftover value keeps key auth alive silently), secrets in Key Vault or CI/CD pipelines, and scripts that pass api_key= explicitly. If you have diagnostic logging enabled on the resource, review recent traffic for key-authenticated calls before proceeding — and if you cannot confirm from logs, check the official documentation for the auditing options available on your resource tier rather than guessing.
3. Rotate keys as a dry run. Regenerating Key1 and Key2 under Resource Management → Keys and Endpoints in the Azure portal invalidates all existing keys without disabling key auth. Anything that breaks after rotation is a caller you missed — far better to discover it in a controlled window than after the permanent switch. Note the flip side: until you regenerate, holders of existing keys retain access, which is itself an argument for finishing the job with disableLocalAuth.
4. Flip the switch, monitor for auth failures, and treat any that appear as the final stragglers.
disableLocalAuth is a setting, not a one-way door — you can set it back to false if something critical breaks. But treat re-enabling as an incident response, not a routine option, or the migration never actually finishes.Why bother, in one paragraph
Keys are bearer secrets: whoever has one is the resource, with full access and no identity attached. Entra ID tokens expire (typically after one hour), are issued to a specific user or managed identity, respect RBAC role scoping, and show up in your directory's sign-in machinery. Disabling local auth converts "we prefer Entra ID" from a convention into a guarantee — and it is the only way to make RBAC assignments like those in our Foundry role guide actually binding on every caller.