Zero Trust for AI Agents: Verify, Limit, Contain

Zero trust starts from a simple idea: no request is trusted because of where it comes from. Every access is verified, limited and monitored. AI agents test that idea harder than any other kind of identity. They run inside your network, often with valid credentials, and can be turned against you by a sentence in a document they read. An agent that is trusted because it is "internal" or "ours" is exactly what an attacker wants to control. This guide applies zero trust principles, as set out in NIST SP 800-207, to AI agents: how to verify them, how to limit what they can do, and how to design on the assumption that some of them will be compromised.

Key takeaways

Treat every agent as potentially compromised. Prompt injection means a legitimate, correctly authenticated agent can still act for an attacker.
Verify the agent, the principal it acts for and the request on every access, not just at session start.
Grant the least access for the shortest time, per task, and remove standing privilege.
Put policy enforcement in front of every tool and resource an agent can reach, outside the agent and the model.
Assume breach: segment agents, contain blast radius and be able to cut an agent off in minutes.

Zero trust principles, applied to agents

NIST SP 800-207 describes zero trust through a set of tenets. The table below restates the most relevant ones for AI agents.

Zero trust tenet (NIST SP 800-207)	What it means for AI agents
All data sources and computing services are resources	Every tool, MCP server, API, data store and other agent is a resource with its own access decision, including internal ones.
All communication is secured regardless of network location	Agent-to-tool and agent-to-agent traffic is authenticated and encrypted even inside the same cluster or VPC.
Access is granted per session	Agents receive short-lived, task-scoped access, not standing permissions.
Access is determined by dynamic policy	Decisions consider the agent, its principal, the action, the resource's sensitivity and current behaviour.
The integrity and security posture of all assets is monitored	Agent configuration (model, prompt, tools) and behaviour are monitored; changes affect trust.
Authentication and authorisation are dynamic and strictly enforced	Checks happen per action and are re-evaluated when risk changes.
Collect as much information as possible to improve security posture	Log every agent action with identity, principal and context, and feed it back into policy.

Verify explicitly

Verify the agent

Each agent has its own cryptographic identity, issued by a platform: a workload identity, certificate or OAuth client with private key authentication. No shared secrets, no human credentials. See the Agentic AI Identity Guide.
Where possible, verify what the agent is, not only which credential it holds: attest the workload and bind identity to its approved configuration.
For external agents, verify signed agent metadata and allowlist trusted publishers. See the Multi-Agent and A2A Security Guide.

Verify the principal

Know whose authority the agent is exercising, and check that the user or system still has that authority at the time of the action.
Use delegated tokens that carry both the agent and the user, and propagate the delegation chain in multi-agent systems.

Verify the request

Validate each tool call's action, target and arguments against policy and schema before execution.
Check that the action is consistent with the task the agent was given. An agent asked to summarise a document has no reason to call an email-sending tool.

Use least privilege

No standing privilege: agents hold no admin or broad roles. Access is issued just in time for a task and expires with it.
Least agency: give agents only the tools their purpose needs, even where their credentials would allow more.
Narrowing delegation: authority can only shrink as it passes between agents.
Intersection of user and agent: an agent acting for a user never exceeds that user's access.

The AI Agent Authorisation Guide covers how to implement task-scoped and per-action authorisation.

Assume breach

Design as if some agents will be manipulated or compromised, because some will:

Segment agents: separate identities, memory and network paths for agents with different purposes and sensitivity levels. An agent that reads external content should not share credentials or memory with one that can change production.
Separate reading untrusted content from taking privileged action: where an agent must process external input, limit what it can do in the same task, or pass its output through an independent check before a privileged agent acts on it.
Control egress: restrict which external destinations agents and their tools can reach, to limit exfiltration.
Contain quickly: maintain a kill switch per agent that stops execution and revokes credentials. See the AI Agent Observability and Incident Response Guide.
Protect recovery paths: backups and break-glass accounts must be unreachable from agent identities.

Architecture: policy decision and enforcement for agents

NIST SP 800-207 separates the policy decision point (which decides) from the policy enforcement point (which allows or blocks). For agents, enforcement points should sit:

At the identity provider or authorisation server, which issues only task-appropriate, short-lived tokens.
At a tool or MCP gateway, which checks every tool call against policy before it reaches the backend. See the MCP Security Guide.
At API gateways and service meshes, which authenticate agents and enforce audience and scope.
At the resource, which still enforces object-level permissions.
In the orchestrator, which enforces delegation rules between agents.

A shared policy decision point keeps decisions consistent across these points. The OpenID Foundation's AuthZEN Authorization API 1.0 standardises how enforcement points request decisions. The decision should draw on signals such as the agent's registry record, risk rating, recent behaviour, the principal's status and the data's classification.

Continuous evaluation

Zero trust is not a one-time check. For agents, re-evaluate access when:

The user the agent acts for is disabled, changes role or loses a session.
The agent's configuration changes: new model, new prompt, new tools.
Behaviour deviates from the agent's baseline.
A tool, MCP server or dependency the agent uses is reported compromised.

Short token lifetimes limit exposure between checks. Where supported, the OpenID Shared Signals Framework and Continuous Access Evaluation Profile (CAEP) allow services to receive revocation and risk events immediately rather than waiting for tokens to expire.

Common anti-patterns

Trusted internal agents: internal MCP servers or agent endpoints with no authentication because they are "only on the private network".
Session-level trust: checking authority once when an agent starts, then letting it run for hours.
Prompt-based controls: relying on system prompt instructions instead of enforcement points.
Shared agent credentials: one key or service account across many agents, so one compromise compromises all.
Flat agent networks: any agent can call any other agent or tool.

Practitioner checklist

Give every agent a unique, platform-issued, cryptographic identity; no shared or human credentials.
Authenticate and encrypt all agent-to-tool and agent-to-agent traffic, internal included.
Issue short-lived, task-scoped access; remove all standing admin privilege from agents.
Place policy enforcement in front of every tool and resource, backed by a shared decision point.
Verify the agent, the principal and the request on every action.
Segment agents by purpose and sensitivity; restrict egress.
Re-evaluate access on user, configuration, behaviour and supply chain changes.
Keep a tested kill switch per agent, and keep backups out of agents' reach.

Zero Trust for AI Agents: Applying NIST SP 800-207 to Autonomous Actors