Zero trust is well-understood for human users and network perimeters. Applying it to AI agents — entities that act autonomously, spawn sub-agents, and operate across trust boundaries — requires a more precise framework.
The zero-trust security model, formalized by John Kindervag at Forrester in 2010 and codified by NIST in SP 800-207, is built on a simple premise: never trust, always verify. Every access request — regardless of whether it originates inside or outside the network perimeter — must be authenticated, authorized, and continuously validated.
This model works extremely well for human users and static workloads. It works less well — in its current form — for autonomous AI agents, for three reasons that are structural, not incidental.
First, AI agents act at machine speed. A human user might make dozens of access requests per hour. An agent executing a complex multi-step task might make thousands. Traditional zero-trust implementations that involve human-in-the-loop verification or introduce meaningful latency per request will break agent workflows entirely.
Second, AI agents spawn other agents. A top-level orchestrator agent delegates to specialized sub-agents, which may in turn invoke tools, APIs, or further sub-agents. The chain of custody for authorization is non-linear and dynamic. A human user has one identity. An agent workflow may involve dozens of transient identities, each inheriting permissions from its parent in ways that must be controlled and auditable.
Third, AI agent behavior is stochastic. A human user generally does the same thing when they click the same button. An AI agent, depending on its model, context, and input, may take meaningfully different actions in response to the same starting conditions. This makes behavioral anomaly detection harder and static permission scopes less reliable as the sole control.
NIST SP 800-207 identifies five core tenets of zero trust. Here is what each requires in the context of AI agent systems.
For agents, this means every tool the agent can invoke — not just traditional IT resources like files and APIs, but language model inference endpoints, code execution environments, web browsing capabilities, and external service integrations — must be treated as a protected resource requiring authorization.
Most agent security frameworks stop at API access. A genuine zero-trust implementation covers the full tool surface: every capability the agent can exercise is a resource, and access to that resource is governed by explicit policy.
Agent-to-tool communication must be encrypted and authenticated regardless of whether it traverses a network boundary. An agent calling a function running in the same container should be held to the same communication security standard as an agent calling an external API. This prevents lateral movement: a compromised component in the agent's execution environment cannot leverage implicit trust to escalate its access.
This is where most agent deployments deviate most significantly from zero-trust principles. Long-lived credentials that persist across agent sessions violate this tenet directly. A proper implementation issues credentials scoped to the specific task, valid for the duration of the task, and automatically expired at task completion. The agent is re-authorized on each new task invocation — it cannot carry forward permissions from a prior session.
Static role assignments are insufficient for agent systems where behavior is context-dependent. A dynamic policy engine evaluates each access request against the agent's current context: what task is it executing, what data has it already accessed, what is its declared purpose, and does this specific action fall within that purpose?
This is the principle behind attribute-based access control (ABAC) as applied to agents. Rather than "agent-type-X can access resource-Y," the policy is "agent-type-X executing task-class-Z may access resource-Y when the data sensitivity is below threshold-T and the action type is read-only." The richness of the policy is what makes zero trust meaningful rather than theatrical.
For agents, this means continuous telemetry on every action taken, fed into a real-time analysis pipeline that can detect deviations from expected behavior. The monitoring must cover not just "did the agent authenticate successfully" but "is the agent's behavior consistent with its declared purpose, its historical baseline, and the current policy?"
The most architecturally complex challenge in applying zero trust to agent systems is the delegation chain. When an orchestrator agent spawns a sub-agent, the sub-agent needs authorization to act. There are three common approaches, with very different security properties.
The orchestrator passes its own credentials to the sub-agent. The sub-agent operates with the orchestrator's full permissions. This is the simplest implementation and the most dangerous: it violates least-privilege completely and means a compromised sub-agent has the full blast radius of the orchestrator.
The sub-agent operates under an ambient authorization context inherited from the orchestrator, without explicit credential passing. This avoids credential exposure but creates an implicit trust assumption: the authorization framework trusts that any agent operating within the orchestrator's workflow is authorized to take any action the orchestrator could take. This is vulnerable to prompt injection attacks that convince a sub-agent it has been delegated permissions it was never explicitly granted.
The orchestrator requests a delegation token from an authorization service, specifying the sub-agent's identity and the restricted permission scope it should operate under. The sub-agent receives a token that is both narrower than the orchestrator's permissions (least-privilege delegation) and cryptographically bound to the sub-agent's identity (preventing forgery). This is the zero-trust-correct approach: every entity in the chain has an explicit, limited, verifiable authorization context.
Scoped delegation tokens are more complex to implement but they are the only approach that maintains zero-trust properties through multi-agent workflows. The orchestrator cannot grant permissions it does not hold (no privilege escalation), the sub-agent cannot exceed its delegated scope (containment), and the entire delegation chain is auditable (accountability).
No discussion of zero trust for AI agents is complete without addressing prompt injection — the class of attack where an adversary embeds instructions in data the agent processes, hijacking the agent's behavior.
From a zero-trust perspective, prompt injection is a trust boundary violation. The agent is treating instructions embedded in untrusted data (a webpage, a document, an email) with the same authority as instructions from its authorized principal (the operator). Zero trust demands that the source of every instruction be verified against policy before it is acted upon.
The architectural defense is an instruction authority model: the agent is trained or prompted to distinguish between authorized instruction sources (its system prompt, the operator's tool definitions) and data sources (everything it reads or receives as external input). Instructions from data sources are not executed without explicit operator authorization. This is a form of access control applied to the agent's instruction-following behavior, and it is as essential to zero-trust agent security as network-level access controls are to traditional zero trust.
For engineering teams moving from zero-trust aspiration to zero-trust implementation in agent systems, the highest-leverage investments in order of impact are:
Zero trust for AI agents is not a product you buy — it is an architecture you design. The agents that operate with this architecture are not just more secure; they are more trustworthy, more governable, and more ready for the enterprise scrutiny that agentic AI systems will increasingly face.
Autonomous agents can read files, call APIs, and modify databases — all without a human in the loop. Without a stable, verifiable identity attached to each agent, your audit trail is fiction and your blast radius is unlimited.
125 days until the EU AI Act applies to production AI systems — and most teams deploying agents haven't done the one thing they need to do first: check if they're classified as high-risk under Annex III.
