Identity-based access and network boundaries

Domain 4 opens with a bullet that names four mechanisms — identity-based access,
network boundaries, access control policies, and RBAC — and the order is not
accidental. Identity comes first because everything else refines it.

The fact the whole domain rests on

A hosted agent is "assigned a dedicated Microsoft Entra ID (agent identity)" on
deployment, and gets a dedicated endpoint.

That single property is what makes the rest of this possible. An agent with its
own identity can be granted, scoped, audited and revoked. An agent using a shared
service account cannot.

And the test that tells you which you have: can I revoke one agent's access
without affecting the others? If revoking means rotating a secret that seven
agents share, you have one account with seven callers — and during an incident your
only options are to break everything or break nothing.

In plain terms: identity-based access means the agent is a who, not a what.
Everything else in this card is a way of saying what that who is allowed to touch.

RBAC, applied properly

Three principles, and the third is the one people skip.

Least privilege per agent. What does this agent need — not what does the
platform offer.

Scope to the resource, not the subscription. An agent that needs one storage
container should be granted that container. Subscription-level grants are how
lateral movement becomes trivial: one compromised agent reaches everything.

Separate the identities that build from the identities that run. A maker's
permission to create an agent is not the agent's permission to act. Conflate the
two and anyone who can build can also reach whatever any agent can reach — which
quietly makes every developer as privileged as your most privileged automation.

Network: inbound is the half everyone builds

Inbound is who can reach the agent's endpoint. Private endpoints where it should
not be publicly reachable. Foundry documents separate public and private endpoint
requirements for MCP servers, and the same reasoning applies to agents.

Outbound is where the compliance weight sits, because an agent's container can
call anything it can reach. Microsoft puts the responsibility plainly:

"It is your responsibility to manage whether your data will flow outside of your
organization's compliance and geographic boundaries."

So for a regulated deployment the real control is egress: restrict what the
agent can reach outward, allow-list rather than deny-list, and treat any web-facing
tool as a data-egress channel that needs its own justification.

Access control policies

The layer above RBAC — Conditional Access, and the policy engine deciding whether a
given access attempt is permitted right now, given context.

RBAC answers "is this principal allowed to do this at all". Policy answers "should
this particular attempt, from here, at this moment, proceed". For agents that
distinction matters more than it does for people, because an agent's access pattern
is machine-regular and an anomaly in it means something.

The trap

Identity and network are complementary and neither substitutes for the other.

Identity stops an agent doing something it is not entitled to do.

Network stops it reaching somewhere it should never have been able to talk to at
all — which is the control that still holds after the model has been talked into
trying.

A scenario about a prompt-injection attack that persuades an agent to exfiltrate
data is not, in the end, an identity question. The agent had legitimate access to
the data. The control that would have held is the one governing where it could send
it.