Does an Entra ID role assignment export satisfy an access control requirement for AI?

It satisfies part of it. The export establishes which principals hold which roles at which scope. An assessor also wants confirmation that key-based authentication is disabled or compensated for, because Microsoft states that such a credential grants full access without role restrictions. Beyond that, the export says nothing about what content a permitted principal sent to a model, which is a separate control with separate evidence.

Why does assigning Foundry Agent Consumer through the Azure portal create a finding?

Microsoft documents that the Azure portal currently supports assigning that role only at Foundry account scope. Project scope grants access to every agent endpoint in the project, and agent scope grants access to one endpoint. A team intending agent-level least privilege but assigning through the portal ends up at account scope. The CLI path with an explicit scope URI is the documented route, and the assignment method belongs in the evidence record.

Which role is needed to fine-tune and deploy a model?

Fine-tuning requires data plane permissions and deploying a fine-tuned model requires control plane permissions. Foundry Owner is the only built-in role holding both. The alternative Microsoft documents is assigning Foundry User for the data plane and Foundry Account Owner for the control plane, which keeps the combination visible in the assignment record rather than hidden inside a single high-privilege role.

Where does DeepInspect fit in a Foundry deployment?

DeepInspect evaluates HTTP traffic between authenticated users or agents and LLM endpoints, including Foundry deployments reached through it, and applies policy to application-supplied identity and content classification before forwarding. Entra ID configuration, role assignment hygiene, managed identity setup, and the accuracy of model output stay on the Azure and customer side of that boundary.

Azure AI Foundry Compliance: RBAC Scope, Key Auth, and the Evidence Gap

Microsoft's role-based access control documentation for Foundry carries a caveat that should be the first line of any compliance review: RBAC roles apply when you authenticate using Microsoft Entra ID, and if you use key-based authentication instead, the credential grants full access without role restrictions. Every role table below that sentence describes a control that a single static API credential bypasses entirely.

Establishing which authentication mode is actually in use is therefore the first evidence item, not a footnote.

TL;DR

A static API credential authenticating to a Foundry resource grants full access with no role restrictions, so a role assignment export proves nothing until Entra ID authentication is confirmed.
Microsoft renamed the Foundry RBAC roles recently, and the documentation advises using role definition GUIDs rather than names in code during the rollout.
Three scopes exist: Foundry resource, Foundry project, and individual agent, and agent-scope assignments are currently evaluated only for agent endpoint access.
Foundry Agent Consumer is the least-privilege role for principals that only call agent endpoints, and the Azure portal currently assigns it only at account scope.
RBAC answers who may call the endpoint, and the content of a given request stays outside every role definition.

The authentication mode decides how much RBAC proves

The Foundry RBAC documentation recommends Entra ID authentication for granular access control, and states directly that such a credential grants full access without role restrictions. A compliance file that opens with a role assignment export and never establishes the authentication mode has assumed its own conclusion.

The test is short. Pull the account's credential usage, confirm whether static credentials are issued and to which workloads, and record the disablement decision with an owner and a date. Microsoft's disable local authentication guidance documents the account-level switch that removes the option outright. Where a static credential remains in use for a legacy integration, that integration needs a separate compensating control and a scheduled removal date in the risk register.

Microsoft also flags that the role names changed. 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. Role IDs and permissions are unchanged. Any automation matching on role name rather than GUID is fragile during the rename rollout, and Microsoft says so explicitly.

The five built-in roles and what each carries

Foundry Agent Consumer grants access to interact with agent endpoints in a project and nothing else. No project creation, no account creation, no data actions, no role assignment, not even reader access to projects and accounts.

Foundry User adds reader access to project and resource plus data actions for the project, which is the role Microsoft describes as least-privilege for developers building and testing agents.

Foundry Project Manager adds publishing agents and the conditional ability to assign the Foundry User role. Publishing an agent requires this role at minimum, held at resource scope.

Foundry Account Owner creates projects and accounts and manages models, and notably cannot perform data actions inside a project. Foundry Owner is the only built-in role holding both control plane and data plane permissions, which is why Microsoft names it as the single built-in role sufficient to fine-tune and then deploy a fine-tuned model.

Microsoft also warns against two roles that look right and are not. Roles beginning with Cognitive Services target AI Services resources directly, and the Azure AI Developer role is scoped to Azure Machine Learning workspaces and Foundry hubs rather than Foundry projects or hosted agents.

Scope is where least privilege is actually won or lost

Three scopes apply, and Azure evaluates them through the resource hierarchy inheritance model that applies to every Azure role assignment. The Foundry resource is the top-level administrative, security and monitoring boundary. The Foundry project organises work and enforces access for APIs, tools and developer workflows. The agent scope applies to one agent.

Agent scope carries a limitation worth recording verbatim in the control description: role assignments at that scope are currently evaluated only for agent endpoint access, and grant no broader control plane or management permission. The scope identifier is the subscription path, followed by the resource group, the Microsoft.CognitiveServices provider, the account name, the project name, and finally the agent name.

There is a portal gap here that changes practice. Microsoft states the Azure portal currently supports assigning Foundry Agent Consumer only at account scope, and directs teams to the Azure CLI for project or agent scope, using the role definition GUID and an explicit scope string. A team that assigns least-privilege roles through the portal alone is granting account-scope access while believing it granted agent-scope access. That mismatch belongs in a findings list.

The evidence package RBAC does not produce

Role assignments establish that a principal was permitted to reach an endpoint. A compliance reviewer sampling one transaction needs more than that: the originating identity and timestamp, the project and deployment reached, the content classification of the prompt, the policy version in force, the decision outcome, and a matching denied test.

Nothing in the role model evaluates prompt content. A Foundry User with legitimate data-plane permissions can send regulated data to an approved deployment, and every access control in the chain will record a pass. That is the post-authentication gap in its plainest form, and no amount of role tuning closes it.

Our Azure AI Foundry security material covers the control side of this. Compliance review asks the adjacent question of who approved each control, when it was last tested, and which artefact proves the result. The AI governance audit framework supplies the structure for holding those together.

What to sample this quarter

Pick one production project. Export role assignments at resource, project and agent scope, and check each against the named persona it was meant to serve. Microsoft's own mapping puts developers on Foundry User at project scope with Reader at resource scope, and agent consumers on Foundry Agent Consumer at project or agent scope.

Then confirm the authentication path for each assignment, because a workload still holding a static account credential renders its role assignment decorative. Record the finding either way.

Finish with a denied test. Send a controlled payload whose classification is prohibited for the selected deployment, retain the refusal record, and repeat it after a permission change. I would rather read one denied test with a timestamp than ten pages of role tables, and most reviews I see contain the tables and not the test.

DeepInspect

DeepInspect provides an independent policy decision at the HTTP AI request boundary. For Foundry traffic deliberately routed through it, DeepInspect evaluates the supplied identity and role against organisational policy for the content classification and model authorisation before the request reaches the deployment.

Each decision produces a signed, tamper-evident record held outside the calling application's write path. That record pairs with the role assignment export and the configuration snapshot to answer what a role table cannot: which content this identity sent to which model, under which policy version, with what outcome.

Book a technical deep dive at deepinspect.ai.