Microsoft Entra ID Conditional Access is the policy layer that sits in front of token issuance: when an identity signs in to get a token, Conditional Access evaluates signals — who the user is, what device they are on, where they are connecting from, how risky the sign-in looks — and decides whether to issue the token, demand more proof (like multifactor authentication), or refuse. Because Claude on Microsoft Foundry accepts Entra ID bearer tokens as one of its two documented authentication methods, Conditional Access can govern access to your Claude deployments the same way it governs access to the rest of your Microsoft estate.
The prerequisite: token-based auth, not keys
This entire control only bites when callers authenticate with Entra ID. Foundry's other method — the API key from the deployment's Details tab — never touches Entra: no sign-in occurs, so no Conditional Access policy is evaluated, and the key works from any device, anywhere, for anyone holding it. If Conditional Access is part of your security design for Claude, the operational conclusion is immediate: standardize on Entra authentication (bearer tokens obtained via DefaultAzureCredential or your identity platform, with the Cognitive Services User / Foundry User role assigned) and treat any remaining API keys as a bypass to be inventoried and retired. Whether key-based access can be disabled on your resource is a platform setting to confirm in current Azure documentation — at minimum, keep keys in Key Vault and audit their reads. Notably, the gated Claude Mythos 5 and Mythos Preview models already force the good pattern: they support Entra ID authentication only, with no API keys at all.
Policies that make sense for a model endpoint
A Conditional Access policy has three parts: assignments (which users or workload identities, targeting which application or resource), conditions (device state, location, sign-in risk), and access controls (block, or grant with requirements). For Claude access, the patterns enterprises reach for first:
| Goal | Policy shape |
|---|---|
| Developers only from managed laptops | Target the developer group; require a compliant or hybrid-joined device for token issuance |
| No access from unexpected geographies | Condition on named locations; block sign-ins from outside your operating regions |
| Stronger proof for sensitive access | Grant only with multifactor authentication for users in scope of the Claude-calling role |
| Constrain service principals | Use Conditional Access for workload identities to restrict app-based access, e.g. by location |
Two design notes. First, target policies at the group that holds the Claude inference role in RBAC — keeping the RBAC group and the Conditional Access scope aligned means one membership list drives both. Second, production workloads on Azure compute should use managed identities, which authenticate from inside the platform; your device- and location-based policies are mostly about humans — developers, analysts, and admins — and about credentials that could wander. Coverage details for workload identities are licensing- and feature-dependent, so verify in current Entra documentation.
Rolling out without breaking production
Conditional Access mistakes are loud: a mis-scoped block policy can cut off a production service or lock administrators out. Use the staged path. Start in report-only mode, where the policy evaluates and logs what it would have done without enforcing; review the sign-in logs for a week or two; then enforce for a pilot group before the full population. Always exclude a break-glass account, and test the failure mode deliberately: a developer denied by policy should see a failed token acquisition in their tooling — distinct from the 403 that signals a missing RBAC role on a successfully issued token. Knowing which failure is which saves hours of misdirected debugging.
Honest scope
Neither Microsoft's nor Anthropic's Claude-on-Foundry documentation prescribes Claude-specific Conditional Access configurations — what is documented is the Entra ID authentication path and its RBAC roles. The policy patterns above are standard Entra practice applied to that documented surface; confirm feature specifics, licensing requirements, and exact resource targeting in the official Microsoft Entra documentation before enforcement. Compliance outcomes inherit your cloud provider's posture — confirm specifics with your provider.
Where to go next
Get the identity plumbing right in Entra ID authentication for Foundry and managed identity, then round out governance with Azure Policy and the go-live checklist.