RBAC Preflight

Why this exists. An agentic loop run hit RBAC failures on the subscription, then the resource group, then the Foundry project. Each surfaced mid-provisioning, after partial resources already existed, and each had to be chased separately: request a grant, re-run, hit the next one. The whole set of missing assignments was knowable up front. This step makes it knowable up front.

This step is deliberately self-contained — it needs only the caller identity and the scopes in play — so rapid prototyping, SDD Specify and Deploy preflights reuse it unchanged.

What it checks

The runtime matrix describes the solution’s managed identities — principals that do not exist yet before provisioning. The pre-flight checks the other half of the contract: the deployer prerequisites, the rights the caller needs both to create the resources and to write every role assignment the generated Bicep will create.

Concretely:

1. Enumerate required assignments from the deployer-prerequisites table.
2. Resolve effective assignments for the caller at each scope in play — subscription, resource group, Foundry AI account, and Foundry project — including inherited and group-derived ones.
3. Diff required against effective, applying role equivalence (see below).
4. Report every gap at once as principal → scope → role, with a remediation block a subscription owner can run as-is.
5. Fail fast on any gap. Nothing has been provisioned at this point, so there is no partial state to unwind.

Scopes

Greenfield SDD runs create the resource group, account and project, so only the subscription rows apply. Brownfield runs check the concrete scopes as well, which is where per-resource grants diverge from subscription-level ones.

Role equivalence

Roles are matched by built-in role definition ID, not display name. The Azure AI roles were renamed (Azure AI User → Foundry User, Azure AI Project Manager → Foundry Project Manager, Azure AI Account Owner → Foundry Account Owner, Azure AI Owner → Foundry Owner) and the old names no longer resolve in az role assignment create. Legacy names are still accepted in --from-file input. Custom roles are not evaluated: confirm them manually and record the exception.

A requirement is satisfied by an equivalent-or-broader assignment, so a fully-permissioned caller produces no findings rather than a wall of false positives:

Assignments inherited from a broader scope also satisfy a narrower one: subscription Contributor satisfies the resource-group Contributor requirement.

Control plane and data plane are separate. Owner, Contributor, Foundry Account Owner and Cognitive Services Contributor grant Microsoft.CognitiveServices/* actions but no dataActions, so on their own they cannot create agents, skills or toolboxes. Foundry User grants the dataActions but no write actions, so on its own it cannot create project connections. A subscription Owner therefore still needs Foundry User on the project: the gap that surfaced separately, after the subscription and resource-group ones had already been fixed.

Running it

Live mode shells out to the Azure CLI — az ad signed-in-user show to resolve the caller, az group exists for a named resource group, then az role assignment list --assignee <id> --scope <scope> --include-inherited --include-groups per scope. No extra Python dependencies, and az is already present in any azd-driven run. Pass --assignee to check a principal other than the signed-in user (a service principal or CI identity).

--from-file <observed.json> replays a recorded set of assignments (or raw az role assignment list output) instead of calling Azure; raw output names no principal, so pass --assignee with it. Malformed input is an ERROR, never a PASS. Both the pass and the fail path can be exercised without a subscription.

Verdicts

BLOCKED is not a repair loop — unlike the hosted integration checkpoint, the loop cannot grant itself permissions. The correct response is to hand the report to someone who can, then re-run the pre-flight.

Report contract

Print every missing assignment, not the first one — being handed the complete set in one go is the entire point:

Keep all four parts — the principal, one MISSING block per gap naming scope, smallest grant and accepted alternatives, the ready-to-run remediation, and the statement that nothing was created. The grant is the smallest role that completes the requirement given what the caller already holds (Foundry User for a caller who already has Contributor in the example). The remediation block is what turns the report into a single request to a subscription owner instead of a conversation.

Where it sits in the loop

Run it before provisioning, after the target subscription/scopes are known and before any azd provision, resource creation, or Bicep deployment. Optionally wire the same script as a preprovision hook in azure.yaml so a direct azd up is gated too.

Record the verdict in ./.azure/deployment-plan.md, in both modes, so a later failure can be told apart from a permission gap that was accepted and worked around.

Reuse

The step depends only on the caller identity and the scopes in play, and touches no mode-specific state — so both agentic loop modes inherit it without extra wiring.

Source

• Azure built-in roles (opens in a new tab)
• Role Based Access Control Administrator (opens in a new tab)
• List role assignments with Azure CLI (opens in a new tab)
• Microsoft Foundry role-based access control (opens in a new tab)