10.2 Managed Identities and RBAC for Foundry

Managed Identities and RBAC for Foundry

Quick Answer: Production uses Microsoft Entra ID, not API keys. Control plane = Azure RBAC actions (create the account, deploy models, Private Link). Data plane = dataActions (chat, agents, evaluations). Assign Foundry User (formerly Azure AI User, role ID 53ca6127-db72-4b80-b1b0-d745d6d5456d) to developers and the project managed identity. Owner / Contributor cannot call the playground. Agents and evaluations require Entra ID.

Domain 3's second platform bullet is configure identity and access management with managed identities and RBAC. The same Entra tenant you used for Azure Machine Learning in Chapter 2 now issues tokens for Foundry. The role names on the exam may still say Azure AI User because Microsoft renamed the Foundry roles in 2026; the IDs did not change.

Control plane versus data plane

Azure always splits resource management from using the resource. Foundry makes that split explicit.

Control-plane examples: Foundry resource creation, project creation, account/project capability hosts, model deployment, connection creation. Data-plane examples: building agents, running an evaluation, tracing, fine-tuning.

Trap: granting a developer Contributor on the resource group and expecting the playground to work. Contributor can create the account and deploy models. It does not include Foundry dataActions. The playground returns 403. Pair Contributor (or Foundry Account Owner) with Foundry User, or use Foundry Owner when one person truly needs both planes.

Authentication methods

Foundry supports two ways to prove identity:

• Microsoft Entra ID — OAuth 2.0 bearer tokens for audience https://ai.azure.com/.default. Enables conditional access, MFA, managed identities, per-principal audit, and least-privilege RBAC. Required for Agent Service, evaluations, Toolbox, and managed-identity tool access. Recommended for production.
• API keys — static secrets on the Foundry resource. Language-agnostic and fine for a laptop prototype. All-or-nothing on the resource: a key cannot express "this user may chat but not fine-tune." Keys do not work for agents or evaluations. Rotate them; never commit them.

Token auth needs a custom subdomain on the account. A regional *.cognitiveservices.azure.com endpoint without the subdomain fails with an error that a custom subdomain is required.

Identity types you assign roles to:

• User principal — a human in Entra ID.
• Service principal — an app registration with a certificate (prefer) or client secret.
• System-assigned managed identity — bound to one Azure resource, deleted with the resource. Each Foundry project should have one for runtime calls.
• User-assigned managed identity — a standalone identity you attach to multiple resources (Foundry, App Service, GitHub OIDC). Use it for cross-resource access so you are not copying system-assigned IDs into every Bicep module.

In Python, DefaultAzureCredential() then credential.get_token("https://ai.azure.com/.default") is the production pattern. api-key headers are the prototype pattern.

After every caller is keyless, set disableLocalAuth: true (Bicep property, or Set-AzCognitiveServicesAccount -DisableLocalAuth $true). Azure Policy Foundry Tools resources should have key access disabled can enforce that. Keys then stop working on purpose.

Built-in Foundry roles (current names and old names)

Microsoft renamed the Foundry RBAC roles. Foundry User, Foundry Owner, Foundry Account Owner, and Foundry Project Manager were previously Azure AI User, Azure AI Owner, Azure AI Account Owner, and Azure AI Project Manager. During rollout you may see either string. Use the role definition GUID in CLI and Bicep.

Azure Owner can create accounts and assign any role but still has no Foundry dataActions. Azure Reader can see the account and cannot build. Foundry Account Owner is the platform-admin shape: manage the resource and deployments, then conditionally assign Foundry User when someone needs to build. Fine-tuning a model needs both planes: Foundry Owner alone, or Foundry User plus Foundry Account Owner.

Minimum onboarding Microsoft documents:

1. Foundry User on the Foundry resource to the user principal.
2. Foundry User on the Foundry resource to the project's managed identity.

If the creator is Azure Owner and they create the project in the Foundry portal UI, both assignments are added automatically. SDK/CLI creates do not auto-assign Foundry User — you must az role assignment create.

Assign with the GUID:

az role assignment create \
  --assignee <principal-id> \
  --role "53ca6127-db72-4b80-b1b0-d745d6d5456d" \
  --scope /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.CognitiveServices/accounts/<account>

You can also scope Foundry User to a project ARM ID, or scope Foundry Agent Consumer to a single agent:

/subscriptions/.../accounts/<account>/projects/<project>/agents/<agentName>

Agent-scope assignments are evaluated only for that agent's endpoints. They do not grant control-plane rights.

Roles you should not pick for Foundry projects

Microsoft's RBAC article is blunt:

• Do not assign built-in roles that start with Cognitive Services for Foundry scenarios. Those roles target AI Services resources used directly, not Foundry projects. Cognitive Services OpenAI User is the classic Azure OpenAI data-plane role (Microsoft.CognitiveServices/accounts/OpenAI/*/read style dataActions). On a standalone Azure OpenAI account it still lets you call deployments. On a Foundry project, the role you want is Foundry User.
• Do not use Azure AI Developer for Foundry projects. Despite the name, it is scoped to Azure Machine Learning workspaces and Foundry hubs (including workspaces/hubs/join/action). For Foundry project access, use Foundry User or Foundry Owner.

If a stem still says "Azure AI User on the project," map it to Foundry User. If it says "Azure AI Developer so scientists can join the hub," that is the classic hub join role, not the new project data-plane role.

Managed identities for runtime and connections

The project managed identity is what Agent Service and evaluation jobs present when they call models, Search, Storage, or Cosmos DB. If that identity lacks Foundry User on the account, tool calls 403 even though your user principal can open the portal.

When the agent reads Blob Storage or Search:

• Grant the project identity (or a user-assigned identity attached to the project) Storage Blob Data Reader (or Contributor if it must write) on the storage account.
• Grant a Search data-plane role such as Search Index Data Reader on the Search service.
• Create the Foundry connection with authType: AAD, not a stored admin key.

System-assigned identity is simplest for one project. Choose user-assigned when App Service, a GitHub Actions OIDC federated credential, and the Foundry project must share one principal so you rotate one identity, not three.

Enterprise mapping Microsoft publishes:

• IT admin: Azure Owner on the subscription.
• Platform manager: Foundry Account Owner on the resource.
• Team lead: Foundry Project Manager on the resource (creates projects, publishes agents, can assign Foundry User).
• Developer: Foundry User on the project plus Reader on the account.
• Calling application: Foundry Agent Consumer on the project or agent.

You need Owner or User Access Administrator at the assignment scope to grant these roles. Custom roles can narrow dataActions to Microsoft.CognitiveServices/accounts/AIServices/agents/* when Foundry User is still too broad.

Exam scenario

A squad lead can deploy gpt-4o from the Azure portal (Contributor on the resource group) but every playground chat and agent run returns 403. API keys were disabled by policy (disableLocalAuth: true).

Assign Foundry User to the squad lead and to the project managed identity at the Foundry resource (or project) scope. Keep Contributor for control-plane deploys, or replace it with Foundry Account Owner if they should not have subscription-wide rights. Do not re-enable API keys to "unblock" production, and do not add Cognitive Services OpenAI User as the fix for a Foundry project.

Common trap

Treating Azure AI Developer or Cognitive Services OpenAI User as the Foundry developer role. The first joins hubs; the second is a classic OpenAI data-plane role. Another trap is assigning Foundry User only to people and forgetting the project managed identity, so the portal works and Agent Service cannot reach Search. A third is using API keys for agents — the feature matrix is No for keys on Agent Service and evaluations.