Once your Claude callers authenticate with Microsoft Entra ID (Azure's identity service), what they can do is governed by Azure role-based access control — RBAC. A role assignment has three parts: a principal (user, group, or managed identity), a role (a bundle of permissions), and a scope (where it applies). Foundry has its own purpose-built role set, and Microsoft has been explicit about which older roles you should stop using. One caveat up front: RBAC only binds callers who use Entra ID — an API key bypasses roles entirely, which is why locking this down usually ends with disabling key auth.
The Foundry role taxonomy
The built-in roles were renamed from their "Azure AI" names; the underlying role IDs are unchanged, so existing assignments keep working under the new labels.
| Role | What it's for | Typical persona |
|---|---|---|
| Foundry User (formerly Azure AI User) | Least-privilege builder and inference role — the default for people and workloads that call models | Developers, application identities |
| Foundry Agent Consumer | Interact with agent endpoints only — cannot build or reconfigure | End-user-facing apps consuming a finished agent |
| Foundry Project Manager | Manage a project and its membership | Team leads |
| Foundry Owner / Foundry Account Owner | Full control of the resource and everything in it | Platform administrators |
Foundry User is the role to reach for by default. It carries the stable ID 53ca6127-db72-4b80-b1b0-d745d6d5456d, useful when you assign roles through Bicep, Terraform, or scripts rather than the portal.
The roles Microsoft says not to use
Microsoft warns against assigning roles whose names start with "Cognitive Services", and against the "Azure AI Developer" role, for Foundry-project work — use Foundry User or Foundry Owner instead. These older roles predate the current Foundry resource model and grant permission shapes that don't line up cleanly with projects and agents.
There is one deliberate exception that trips people up: Cognitive Services User remains the documented role for the model-inference Entra ID path specifically. Microsoft's keyless-inference guide requires it at the Foundry resource scope, and Anthropic's Foundry docs name both "Foundry User" and "Cognitive Services User" as the roles whose absence produces a 403 Forbidden. So: for project work, avoid Cognitive Services roles; for pure inference against the resource, Cognitive Services User is still a sanctioned choice. If you build a custom role for inference instead, it needs the data actions Microsoft.CognitiveServices/accounts/MaaS/*. Whatever you assign, allow up to 5 minutes for the assignment to propagate before concluding it didn't work.
Scope: resource, project, or individual agent
Foundry roles can be scoped at three levels, and the scope determines the blast radius of a compromised or over-curious principal:
Resource scope covers the whole Foundry resource — every project and agent inside it. Right for platform admins and for the inference role of a shared service identity, wrong for a single team's developers in a multi-team resource.
Project scope confines the role to one project. This is the natural unit for team-level access: a Foundry User assignment at project scope lets a team build and call models in their own project without touching neighbors.
Individual agent scope is the narrowest: a Foundry Agent Consumer assignment scoped to one agent lets an application invoke exactly that agent's endpoint and nothing else — the right shape for production consumers of a finished agent.
Where to go next
For the token-acquisition side of Entra ID auth, read Entra ID authentication for Claude in Foundry; for the broader resource setup this all hangs off, see the Foundry resource setup guide and the RBAC overview.