Microsoft Foundry in Practice

Authenticating with Microsoft Entra ID Instead of API Keys

If your workload already has an Azure identity, it doesn't need a static API key to call Claude on Foundry. Entra ID tokens give you RBAC, central identity management, and one less secret to rotate.

Claude 3P 101 · Updated July 2026 · Unofficial guide

Microsoft Foundry documents two authentication methods for Claude deployments: Azure-issued API keys and Microsoft Entra ID tokens. Both target the same Azure-hosted endpoint. Entra ID (Microsoft's cloud identity service, formerly Azure Active Directory) replaces the static key with a short-lived bearer token issued to an identity — a user, a service principal, or a managed identity attached to your compute. For workloads already running inside Azure, this is usually the right production choice: access is governed by Azure role-based access control (RBAC), granted and revoked centrally, and there is no long-lived secret to leak or rotate.

How it works on the wire

Instead of an api-key header, requests carry a standard OAuth-style bearer token: Authorization: Bearer <token>. Your code doesn't mint tokens by hand — the Azure Identity library does it. Microsoft's samples use DefaultAzureCredential, which tries a chain of identity sources (environment credentials, managed identity, developer sign-in) so the same code works on a laptop and in production, plus get_bearer_token_provider to keep tokens refreshed.

One detail to watch: the token scope. Microsoft's documentation uses https://ai.cognitiveservices.com/.default, while Anthropic's Foundry page uses https://ai.azure.com/.default. Both are documented; if one scope gives you authorization errors in your environment, try the other and check the current docs for your setup.

Wiring it into the SDK

The Anthropic Python SDK's Foundry client accepts a token provider directly, per Microsoft's sample pattern:

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=512,
    messages=[{"role": "user", "content": "Hello via Entra ID"}],
)

Note there is no API key anywhere. On an Azure VM, App Service, or AKS pod with a managed identity, DefaultAzureCredential picks that identity up automatically — see the managed identity article for the compute-side setup.

Granting access: roles, not keys

With Entra ID, "who can call Claude" becomes an RBAC question. The identity calling the deployment needs an appropriate role on the Foundry resource. If you get a 403, the usual cause is a missing role assignment — Microsoft's documentation points to Cognitive Services User, and Anthropic's mentions Foundry User or Cognitive Services User. Assign the role at the resource (or resource group) level to the calling identity and retry. For the broader permission model, see Foundry RBAC.

Rule of thumb: if the request fails with 401, the token is missing or malformed (wrong scope, expired credential chain). If it fails with 403, the token is fine but the identity lacks a role on the resource. Debug them differently.

Why bother, when a key already works?

Three reasons enterprises make the switch. Revocation is instant and targeted: removing one identity's role assignment cuts off one workload, whereas regenerating a shared API key breaks every client holding it at once. Auditability improves: calls are attributable to a named identity rather than to "whoever had the key." Nothing to leak: tokens are short-lived and minted on demand, so there is no long-lived secret sitting in configuration to end up in a repository or a log. The trade-off is a small amount of setup — role assignments and, outside Azure, a credential source for DefaultAzureCredential to find.

When Entra ID is mandatory, and a shortcut

For most Claude models on Foundry, Entra ID is a choice. For two it isn't: claude-mythos-5 and claude-mythos-preview — gated research previews granted at Anthropic's discretion — support Microsoft Entra ID authentication only, with no API keys.

If you're starting fresh, Microsoft's "Claude on Foundry starter kit" (github.com/Azure-Samples/claude) provisions a Foundry account, project, and Claude deployments with a single azd up (Bicep or Terraform) and wires both the Anthropic SDK and the Claude Code CLI to use Entra ID with no API keys — a working reference for exactly the pattern in this article.

Where to go next

Compare with the key-based path in managing API keys, then follow the SDK setup guides for Python or TypeScript. The production checklist covers what else to lock down before launch.

Sources