Agent-scope role assignments

Most people describe Foundry's access model as having two scopes: the resource and
the project. There are three.

The third scope

Foundry resource → Foundry project → agent.

The agent scope is a real assignable scope, with a real URI:

/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.CognitiveServices
  /accounts/<account>/projects/<project>/agents/<agent>

Any role that can be assigned at project scope can be assigned here. And the
practical use is specific: assigning Foundry Agent Consumer at agent scope grants
a principal access to one agent's endpoints without granting access to every agent
in the project.

If you have five agents in a project and one of them serves an external partner,
this is how the partner gets that one and nothing else.

The limitation is as testable as the capability

Microsoft is explicit, and the constraint is easy to miss:

"The system currently assesses agent-scope role assignments only for agent
endpoint access."

An assignment at agent scope does not grant broader control-plane or management
permissions. Whatever role you assign there, only its endpoint-access implications
are evaluated.

Which means agent scope is a consumption control, not a development control. It
governs who may call an agent. It says nothing about what that agent may reach.

Two different questions that sound like one

This is the part worth slowing down on, because a question can mean either.

"Revoke one agent without affecting the others."

If it means who may call this agent — that is the consumption end, and agent-scope
role assignment is the mechanism.

If it means what this agent may reach — that is the build end, and the mechanism is
the agent's own managed identity. Scoping who may call an agent and scoping what
an agent may do are genuinely different problems with genuinely different answers.

The scenario will tell you which. A question about external users, partners or
service principals calling an endpoint is the first. A question about a compromised
agent reaching a storage account is the second.

Where this fits

Card 6 posed "can I revoke one agent without affecting the others" as the test of
whether you have real per-agent identity. This card is the concrete answer at one
end of it — Foundry gives you a real scope, with a documented limit, and it is worth
knowing both halves.

The trap

Assigning a broad role at agent scope and assuming it has been usefully narrowed.

It has not been narrowed in the way you might expect — the scope is narrow, but
only the endpoint-access portion of the role is evaluated there at all. If you need
to constrain management permissions, agent scope is not the tool, and a design that
relies on it for that will pass review on paper and do nothing in practice.