Zero Trust for agents

Zero Trust for agents is not a new set of principles. It is the ordinary ones
applied to a thing that behaves differently from a user and differently from a
service — and the syllabus names three specific components.

Per-agent identity scoping

The principle is that each agent is a who, not a what.

And there is one question that tests whether you have actually achieved it:

Can I revoke one agent's access without affecting the others?

If revoking means rotating a secret that seven agents share, you do not have seven
agents. You have one account with seven callers, and your only options during an
incident are to break everything or break nothing.

This is why the hosted-agent property from card 3 matters so much: a hosted agent
gets "a dedicated Microsoft Entra ID (agent identity)" on deployment. Everything
else in the security domain is built on top of that fact.

Lateral movement prevention

Three habits, and the third is the one that gets skipped.

Scope to the resource, not the subscription. An agent that needs one storage
container should be granted that container. A subscription-level grant means one
compromised agent reaches everything, which is the definition of lateral movement
being trivial.

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

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
them and anyone who can build an agent can reach whatever any agent can reach —
which quietly makes every developer as privileged as your most privileged
automation.

Compliance control mapping

The least technical of the three and often the most work: which control satisfies
which obligation, and what evidence a regulator will actually accept.

This is worth designing early rather than reconstructing later, because the
artefacts a review wants — who can reach what, under whose identity, with what
logged — are much easier to produce when the system was built to produce them.

Identity and network do different jobs

Neither substitutes for the other, and the distinction is the most useful sentence
on this card.

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

Network stops an agent 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.

That second clause is the whole argument. Identity assumes the request is what the
agent meant to make. Network does not care what the agent meant.

Outbound is where the data leaves

Inbound protection — private endpoints, restricting who can reach the agent's
endpoint — is the half everyone builds.

The half that carries the compliance weight is outbound, because an agent's
container can call anything it can reach. Microsoft states the responsibility
directly:

"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: 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.

The trap

Inbound private endpoints look like the security answer, and they solve exactly half
the problem.

A scenario about data leaving the organisation, or about residency, or about a
web-grounding tool, is an egress question — and no amount of locking down who can
call the agent addresses where the agent can call out to.