Zero Trust for AI Agents: Identity and Access with Microsoft Entra

Every enterprise that experimented with copilots in 2024 is now deploying agents that act — reading mailboxes, creating tickets, running remediation scripts, and chaining calls across SaaS APIs with minimal human supervision. Microsoft's own framing at Ignite 2025 was telling: the introduction of Microsoft Entra Agent ID was billed as "the largest expansion of Microsoft Entra capabilities to date," explicitly extending Zero Trust principles to AI workloads. That is not marketing hyperbole so much as an admission that the identity stack we built for humans and daemons does not survive contact with autonomous, tool-wielding software.

This article walks through why agentic AI breaks traditional identity assumptions, how Entra Agent ID models the agent identity lifecycle, how to apply least privilege and Conditional Access to agents, how to secure tool invocation, what monitoring and deprovisioning look like, and how it all assembles into a Zero Trust reference architecture.

Why agentic AI breaks traditional identity assumptions#

Classical IAM rests on a handful of assumptions that agents quietly violate:

• Identities are long-lived and few. Humans and service principals number in the thousands and change slowly. Agents are ephemeral, numerous, and often spawned per task or per team — the "shadow AI" problem is an identity problem before it is anything else.
• Authentication signals exist. Conditional Access leans on interactive sessions, devices, locations, and MFA. An autonomous agent acquiring tokens at 3 a.m. has none of these signals, as Microsoft's Zero Trust guidance for AI points out — classic trust signals simply don't fire.
• Intent is stable. A service account does what its code does. An agent's behavior is shaped at runtime by prompts, retrieved context, and tool outputs — all of which are attacker-influenceable via prompt injection.
• Blast radius is bounded. Agents chain tools across systems and sometimes tenants. Microsoft's least-privilege pattern for AI agents names the resulting failure modes precisely: identity ambiguity (which principal did that?), permission creep across aggregated roles, over-broad tool access, weak audit trails, and slow revocation.

The practical consequence: running agents under shared secrets, borrowed user tokens, or a single over-privileged service principal collapses accountability exactly when you need it most — during an incident.

Microsoft Entra Agent ID and the agent identity lifecycle#

Entra Agent ID, announced in preview at Build 2025 and expanded substantially at Ignite 2025, makes agents first-class principals in the directory. Per the agent identities overview, an agent identity is a special kind of service principal with a few distinctive properties:

• No credentials of its own. Agent identities authenticate exclusively via federated identity credentials issued by an agent identity blueprint. The blueprint holds the credentials (FIC, certificates, or client secrets) and acquires tokens on the agent's behalf. This inverts the usual sprawl problem: you rotate credentials in one place, not per agent instance.
• A blueprint as a reusable template. Every agent identity is stamped from a blueprint that records the kind of agent, its publisher, offered roles, and consented Microsoft Graph permissions. Deploy five regional instances of a "Sales Assistant Agent" and you get five agent identities under one blueprint — so an admin can apply a Conditional Access policy, disable, or revoke a permission grant for all Sales Assistant Agents in one operation. That is the scaling story for agent governance.
• A sponsor. Each agent identity records the human or group accountable for it — the person you call at 2 a.m. when the agent starts exfiltrating SharePoint.
• Single-tenant by design. Agent identities can only be issued tokens in the tenant where they are created. Blueprints can be multitenant (published to other tenants, which mint tenant-local agent identities), but the identities themselves never roam — a clean containment boundary for cross-tenant risk.
• An optional agent's user account. For systems that strictly require a user object (Exchange mailboxes, Teams presence), an agent can be given a 1:1-linked user account decorated as an AI agent — explicitly labeled, not masquerading as a person.

The lifecycle mirrors joiner–mover–leaver, compressed: register the blueprint (or onboard one from the Agent Registry), instantiate agent identities from it, operate with blueprint-mediated tokens, and retire by disabling or deleting identities — with blueprint-level disablement as the fleet-wide kill switch. The platform supports three token acquisition patterns: autonomous app tokens (subject is the agent), user tokens where the subject is a user and the actor is the agent identity, and incoming tokens where the agent is the audience. That actor/subject split is what preserves "on behalf of" attribution end-to-end.

Least privilege and Conditional Access for agents#

Least privilege for agents is a design activity, not a cleanup task. The least-privilege pattern recommends task-based roles scoped to resource, data, and action boundaries; separation of read and write roles; and time-limited privilege through just-in-time elevation (e.g., Entra Privileged Identity Management) so high-impact rights exist only for the duration of a workflow.

Conditional Access has been extended to agent identities with a crucial adaptation: since device, location, and MFA signals don't exist for agents, risk becomes the primary signal. Microsoft Entra ID Protection for agents continuously evaluates agent behavior and emits a risk level, detecting offline risk types such as unfamiliar resource access, sign-in spikes, and failed access attempts. A dedicated Conditional Access template blocks high-risk agent identities, so a compromised agent loses token access without waiting for a human to notice.

Be clear-eyed about current limits, as the community documentation on Conditional Access for agent identities spells out: these policies control whether an agent identity can acquire a token and can block specific or risky agents — they do not enforce MFA, authentication strength, device/location conditions, or session controls. Design accordingly: agent CA is an identity-perimeter gate, and the real enforcement must also live at the resource and tool layers.

Securing tool and plugin invocation#

Tools are where agent risk concentrates. A single prompt injection in a retrieved document can turn "summarize this workspace" into "export this workspace" if the agent can invoke any available tool. The controls that matter:

1. Tool allowlists, not tool catalogs. Deny unreviewed tools and plugins by default; allowlist only the actions the workflow needs ("create/update ticket" but never "delete"). Microsoft's guidance is explicit that high-impact actions — delete, export, privilege change — should be gated by approval or JIT elevation.
2. Re-validate authorization at every hop. Do not trust the orchestrator's decision downstream. Each tool and API should independently check the token's subject, actor, roles, and scopes. The orchestrator → tool → downstream service chain is only as strong as its weakest unchecked hop.
3. Use the agent token claims. The agent identity platform issues tokens where the subject may be the user and the actor is the agent. Resource servers should log and authorize against both — this is how you distinguish "Alice asked the agent to read her calendar" from "the agent acted autonomously."
4. Consent scoping via blueprints. Because Graph permissions are granted on the blueprint and inherited by its agent identities, the consent surface is reviewable and uniform — and revocable at fleet scale.
5. Prompt-injection defense in depth. Identity controls contain the blast radius but don't prevent malicious instructions. Pair them with content-layer defenses like the AI Prompt Shield capabilities in Entra Internet Access and runtime detections in Microsoft Defender.

Monitoring and deprovisioning agent identities#

You cannot govern what you cannot see. Agent activity lands in the surfaces you already operate: Entra sign-in and audit logs capture agent events, with a dedicated agentSignIn resource type carrying agent-specific properties, while audit events are recorded under the base identity type (agent identity creation appears as "Create service principal"). Stream these into Microsoft Sentinel alongside your workload identity detections.

For behavior analytics, the Risky Agents report in ID Protection lets admins confirm compromise, confirm safe, dismiss risk, or disable the agent directly. The discipline to build:

• Log the right fields: agent identity, blueprint, role, effective scope, action, resource, correlation ID, and the on-behalf-of user. "The chat said X" is not an audit trail; the tool-call chain is.
• Test revocation like you test failover. Measure mean time to disable an agent identity including token invalidation. Verify the blueprint-level kill switch actually cuts off every instance.
• Deprovision on change, not just on departure. Re-review access whenever the workflow, tool set, data scope, or environment materially changes. Orphaned agents with standing Graph permissions are the new orphaned service accounts.
• Watch for agents without identity. Entra's Agent Registry and the "manage agents without identity" guidance exist precisely because discovery — finding the OAuth apps and shared secrets that are really agents — precedes governance.

A Zero Trust reference architecture for AI agents#

Putting it together, mapped to the three Zero Trust principles:

Verify explicitly. Every agent is a first-class Entra agent identity minted from a registered blueprint, with a named sponsor. Tokens flow blueprint → agent identity → resource, with user-delegated calls carrying the agent as actor. No shared secrets, no borrowed user sessions.

Use least-privilege access. Task-scoped RBAC with read/write separation, tool and action allowlists enforced at each hop, JIT elevation via PIM for destructive operations, and consent managed at the blueprint. Conditional Access gates token issuance; risk-based policies block high-risk agents automatically.

Assume breach. Single-tenant identities bound lateral movement. ID Protection for agents watches behavior continuously; sign-in and audit logs flow to Sentinel with correlation IDs across the orchestrator → tool → resource chain; blueprint-level disablement and credential rotation provide a tested, fast kill switch; and Microsoft Agent 365 provides the control plane — registry, access control, and monitoring — across Copilot Studio, Foundry, and third-party agents.

The throughline is simple: agents are not a feature of your identity system; they are a new identity population. Treat them with the same rigor you (should) apply to humans and workload identities — unique identities, named owners, scoped access, continuous evaluation, and rehearsed revocation — and the agentic enterprise becomes governable rather than merely exciting.