Zero Trust for Non-Human Identities

Zero Trust has guided how organisations protect people and applications for years. As agent populations grow in scope, volume, and variety, that same discipline has to extend to agents specifically, and this article is about exactly how.

1 · Zero Trust, in one sentence

Zero Trust means never assuming a request is safe simply because it is already inside the network, or because the requester already holds some access; every request is verified on its own merits, every time. As the scope, volume, and variety of agents keeps growing, so does the need to secure exactly what those agents can reach, and Microsoft Entra Agent ID provides the guardrails that extend Zero Trust principles to agents specifically. The foundation underneath it all is familiar from earlier in this series: least privilege, giving an agent only the access rights to the apps and resources it actually needs.

2 · Four capabilities Entra Agent ID adds

On top of that baseline, four concrete capabilities apply Zero Trust to agents in practice. Conditional Access for agents lets policies be written specifically for agent identities. Policies can also target agent resources and trigger based on agent risk, a calculated risk level rather than a fixed rule. Identity Protection for agents automatically detects and responds to risky behaviour, such as an agent reaching for an unfamiliar resource or attempting an unusually high number of sign-ins. And network-level controls, through a secure web and AI gateway, apply web content filtering, threat intelligence filtering, and file filtering directly to an agent’s traffic.

3 · Two identity patterns: interactive and autonomous

Agent identity requirements vary depending on how an agent actually operates, and there are two recognised patterns. An interactive agent acts on behalf of a specific user, so its access is evaluated in that user’s context; it acquires tokens carrying both user and agent context together. An autonomous agent operates independently and authenticates on its own, using its blueprint’s credentials rather than borrowing a user’s context.

Microsoft Entra supports both patterns through Entra Agent ID, standardising how each is created and managed so that, regardless of which pattern an agent follows, it becomes a well-defined participant in the identity system rather than an unmanaged or unknown actor. The developer ecosystem for both is the same one already familiar from the Microsoft identity platform: register blueprints, provision identities, acquire tokens, all through Microsoft Graph, which is what makes an agent secure by design from its very first line of code, rather than retrofitted after it is already deployed.

4 · Sponsor versus owner: two distinct roles

A second key idea keeps two human roles behind every agent deliberately separate. A sponsor is a human user, or supported group, holding business accountability for the agent’s lifecycle: deciding when the agent is no longer needed, approving extensions when its access is about to expire, and authorising its suspension during an incident. An owner is different: responsible for the agent’s technical operations and incident response.

Keeping these separate is not bureaucratic overhead; it is what makes sponsorship the genuine entry point for identity governance. Lifecycle workflows route a departing sponsor’s notifications to their manager automatically. Access-package expiry escalations are sent to the sponsor specifically. And entitlement-management approvers rely on the sponsor relationship to validate that access should continue. Every agent identity and every agent identity blueprint requires at least one sponsor for exactly this reason.

5 · Tag every agent at the moment it is provisioned

A very practical recommendation closes the picture: establish an operational process to tag new agents as they are provisioned, using custom security attributes assigned right at creation. Doing this means an agent is labelled, filterable, and covered by Conditional Access rules that key off those tags from its very first moment of existence, rather than becoming yet another untracked identity that governance has to catch up with later, echoing the “register at birth” discipline from earlier in this series, now expressed as a concrete tagging habit at enterprise scale.