RBAC Contract

Two matrices live here, and they answer different questions:

Runtime matrix (service managed identities)

Every component authenticates with a managed identity (user-assigned preferred) and least-privilege RBAC - no admin keys, no connection strings on the control/data plane.

• Scope Foundry User to the AI account (not a single project) so the backend can invoke any hosted agent in it. Foundry User is the renamed Azure AI User; in Bicep, reference built-in roles by definition ID, never by display name.
• Model inference depends on the inference path. Project-brokered inference as the agent identity is covered by implicit access — no role needed. BYOK direct inference (the Copilot SDK / MAF agent calling the model endpoint with a token from DefaultAzureCredential) authenticates as the runtime instance managed identity, which has no implicit access — grant it Cognitive Services OpenAI User at the AI account scope or inference fails with 401 PermissionDenied. The blueprint principal rejects role assignments (PrincipalTypeNotSupported); use its client ID only in MCP Easy Auth allow-lists. azd only auto-assigns Foundry User to the shared project agent identity, so create the runtime instance rows in the idempotent postdeploy hook (grants after deploy).
• Scope Cognitive Services OpenAI User to the AI account hosting the model deployment.
• Tool/MCP and default Foundry IQ grounding access are authorized against the agentIdentityId, not the runtime MI — Agent Service brokers an agent-identity token for AgenticIdentityToken/AgenticIdentity connections. On publish, the agent can get a new agentIdentityId; repeat these assignments (shared-project roles don’t carry over).
• Runtime instance MI Search access is an escape hatch, not the baseline. Grant Search Index Data Reader to the runtime instance MI only when the agent performs direct in-code Search / Foundry IQ retrieval instead of consuming the brokered toolbox grounding tool. The instance identity is minted at deploy/publish time, so make that grant reproducible in a postdeploy hook if the escape hatch is used. See foundry-iq-grounding.md.
• Scope AcrPull to the registry and use managed-identity image pull - keep the ACR admin user disabled.
• Assign roles to each app/agent’s identity, not to a shared principal, so the matrix stays least-privilege and auditable.

Deployer prerequisites (pre-flight)

Every row of the runtime matrix above is created by the deployment, which means the caller running the loop needs rights both to create the resources and to write those role assignments. Missing caller rights do not fail cleanly at the start - they fail on the first operation that needs them, after partial resources exist.

These assignments must therefore be verified before provisioning by the RBAC pre-flight, which diffs this table against the caller’s effective assignments and reports every gap in one list.

• Broader satisfies narrower. Owner satisfies Contributor and Role Based Access Control Administrator; User Access Administrator satisfies Role Based Access Control Administrator; Foundry Owner satisfies both Foundry rows; Owner, Contributor and Cognitive Services Contributor satisfy the account row. A fully-permissioned caller therefore reports no gaps rather than a wall of false positives.
• Control plane is not data plane. Owner, Contributor and Foundry Account Owner carry no dataActions, so a subscription Owner still cannot create agents, skills or toolboxes until it also holds Foundry User on the project. Foundry User carries no write actions, so it needs an account control-plane role to create project connections.
• Match role definition IDs. The Azure AI roles were renamed to Foundry roles and the old display names no longer resolve; the pre-flight and the Bicep use built-in role definition IDs.
• Inheritance counts. An assignment at the subscription applies to the resource group and to the Foundry account and project beneath it; the pre-flight resolves effective (inherited and group-derived) assignments, not just direct ones.
• An existing resource group replaces the subscription rows. When the run deploys into a group that already exists, its rows apply instead; subscription grants still satisfy them through inheritance. SDD creates rg-<env>, so its first provision checks the subscription rows.
• Foundry scopes only exist after the account/project do. On a greenfield run the account and project are created by the deployment, so the pre-flight checks the inherited subscription-scoped rights that will allow their creation, and re-checks the concrete Foundry scopes when they are supplied (a brownfield run against an existing project).
• Grant these to the caller once, up front - do not work around a gap by falling back to admin keys or connection strings, which would break the keyless contract above.