Zero-trust security rests on a deceptively simple premise: don’t trust anything by default, verify everything explicitly, and grant access with the minimum scope required for the task at hand.

NIST SP 800-207, the definitive U.S. government document on zero-trust architecture published in August 2020, articulates this through seven core tenets. All data sources and computing services are treated as resources. All communication is secured regardless of network location. Access to individual resources is granted on a per-session basis. Access decisions are driven by dynamic policy that accounts for behavioral and environmental signals. The enterprise continuously monitors asset integrity and posture. Authentication and authorization are dynamic and re-evaluated before access is allowed. And the enterprise collects and uses information about assets and communications to improve its posture over time.

These tenets were written for a world where the entity requesting access is a human, or a service acting on behalf of a human, with a stable identity that can be bound to a credential. AI agents fit none of those assumptions cleanly — and the mismatch creates a new class of architectural vulnerabilities that standard zero-trust implementations don’t address.

Why Agents Break the Zero-Trust Model

The original zero-trust model assumes that identity is the starting point. A user authenticates once per session. That session has a defined scope. The policy engine evaluates that identity against the resource being requested and either permits or denies.

AI agents operate differently in every dimension of this model.

Identity is ambiguous. A zero-trust policy engine can resolve a human user to a known identity — a certificate, a hardware token, a username with MFA. When an LLM agent makes an API call, what is the identity being verified? The model weights? The system prompt? The orchestration framework? The user who initiated the task? An agent’s “identity” is a composite of its training, its runtime configuration, and the task it was given — none of which map cleanly to a principal in an IAM policy.

Sessions are long-lived and unbounded. Human sessions are typically short — a login, some actions, a logout. Zero-trust policy enforcement points assume they can re-challenge on reasonable intervals. An agent running a complex multi-step task may hold a session open for hours, making thousands of API calls across dozens of tools. Each call expands the blast radius if the session was compromised or if the agent’s behavior deviates from its intended scope.

Agents spawn other agents. A multi-agent system introduces trust chaining problems that zero-trust’s user-centric model doesn’t anticipate. When an orchestrator agent spawns a sub-agent, what permissions should the sub-agent inherit? In traditional OS security, privilege inheritance is a solved problem with explicit primitives (setuid, capability sets). In multi-agent systems, permission inheritance is largely implicit — the sub-agent inherits the orchestrator’s credentials, or gets fresh credentials from the same identity pool, with little structural enforcement of scope narrowing.

Authority is ambient, not per-action. Traditional zero-trust enforcement points verify identity before granting access to a resource. They do not typically verify intent at each action boundary. An agent authenticated to read your email is also structurally positioned to forward it — both actions use the same credential. The gap between “permitted to read” and “permitted to forward to an external address” requires a level of semantic policy enforcement that standard network-layer zero-trust doesn’t provide.

These gaps aren’t theoretical. They’re the substrate for the attack classes described in our posts on the confused deputy problem in LLM tool use and multi-agent trust escalation. This post treats zero-trust architecture as the framework for addressing them systematically.

The Agent Identity Problem

Before you can enforce zero-trust for agents, you need a workable definition of agent identity. This is harder than it sounds.

For human users, identity is bound to a credential that the human possesses and controls. For services, identity is typically bound to a cryptographic certificate or a cloud IAM role attached to the compute instance. For AI agents, neither model applies directly.

Consider what makes a given agent instance unique:

• The model version it’s running (a different checkpoint of the same model may behave differently)
• The system prompt it received (which configures its behavior and scope)
• The task it was given (which defines what it’s supposed to do)
• The session it was initiated in (which determines what context it has access to)
• The tools it was provisioned with (which determine what it can do)

None of these individually constitute identity in a cryptographic sense. But all of them together define the trust context in which the agent should be operating.

A practical approach to agent identity, adapted from SPIFFE (Secure Production Identity Framework for Everyone, a CNCF graduated project), treats identity as a workload identity rather than a user identity. SPIFFE defines a workload identity through the SPIFFE Verifiable Identity Document (SVID) — a cryptographically signed document that attests to the identity of a running workload. The runtime environment (SPIRE, the SPIFFE Runtime Environment) continuously issues and renews these certificates to workloads based on attestation from the underlying infrastructure.

Adapted to agents, this model suggests: each agent instance should receive a short-lived, cryptographically verifiable identity document at spawn time. This document attests:

• What model configuration was used
• What system prompt hash was loaded
• What tools were provisioned
• What task scope was authorized
• When the identity expires

The identity document becomes the anchor for all subsequent authorization decisions. A policy enforcement point receiving a request from the agent can verify the document signature, check that the requested action falls within the provisioned tool scope, and reject the request if any attestation fails.

This is not yet standard in any major agent platform, but the components exist. AWS Bedrock agents can be assigned dedicated IAM execution roles — one role per agent type, scoped to the tools that agent class requires. Google Vertex AI agent service accounts provide a similar model. The gap is in the cryptographic binding between the runtime agent instance and its authorized scope; today, that binding is usually enforced at the framework level (if at all) rather than cryptographically.

Microsegmentation: Scoping Tool Access Per-Task, Not Per-Session

Traditional microsegmentation isolates network segments to contain lateral movement. For agents, the equivalent is tool microsegmentation: ensuring that each agent has access only to the tools required for its current task, rather than the full set of tools provisioned for its session.

The distinction matters because agents tend to be provisioned with broad tool sets at session initialization. An agent framework might provision an agent with access to read files, write files, execute code, query APIs, send messages, and manage calendar entries — because some tasks require all of these. But most individual tasks require only a subset. If the agent is manipulated (via prompt injection, confused deputy attack, or behavioral deviation) into using a tool outside the intended task scope, a broad provisioning grants the attacker the full surface.

The microsegmentation model instead provisions tools on a per-task, per-action basis:

Short-lived, scoped credentials per tool call. Rather than giving an agent a long-lived credential for the GitHub API, issue a short-lived token scoped to the minimum necessary action each time the agent is authorized to make a call. Importantly, downstream APIs rarely support per-resource, per-call scoping natively — enforcing this level of granularity requires a brokered enforcement layer (a proxy or sidecar that holds the master credential, validates the agent’s authorization, and issues constrained requests to the downstream API on the agent’s behalf). The authorization decision happens at the moment of tool invocation, not at session start.

Capability tokens rather than ambient authority. The object-capability security model distinguishes between ambient authority (the agent can do anything it has credentials for) and capability-based authority (the agent can only do what it was explicitly handed a capability to do). In practice, this means the framework — not the model — holds the master credentials and issues per-call tokens based on the current task context.

Explicit allowlists per task type. The policy engine maintains a mapping from task types to permitted tool sets. A “summarize document” task gets read access to the document store; it does not get write access, execution access, or network access. Attempting to use a tool outside the task’s allowlist fails at the enforcement point rather than executing.

AWS Bedrock’s IAM execution roles for agents approximate this model: each agent configuration is assigned an IAM role with identity-based policies that scope its permissions to specific Lambda action group functions, S3 prefixes, and Bedrock model ARNs. The trust relationship in the role’s trust policy controls which Bedrock service principals can assume it. Each agent configuration should get its own scoped execution role rather than sharing a broad one. The limitation is that these controls are still session-level, not per-call — the enforcement happens at the IAM role boundary when the role is assumed, not at each individual tool invocation.

Continuous Authorization: Checking Intent at Every Action Boundary

The most significant gap between traditional zero-trust and what agents require is at the authorization granularity level. Traditional zero-trust verifies identity before granting access to a resource. What agents need is verification of intent before executing each action.

NIST SP 800-207’s sixth tenet states that authentication and authorization are dynamic and strictly enforced before access is allowed. For human users, this typically means periodic re-authentication and policy re-evaluation based on session signals (anomalous location, unusual time of access, behavioral risk scoring). For agents, the equivalent is per-action intent verification.

What continuous authorization looks like in practice:

Each time an agent is about to invoke a tool, a policy enforcement point evaluates whether the action is consistent with:

1. The agent’s provisioned task scope
2. The actions taken so far in the session
3. The current state of any resources the action would affect
4. Whether the action was anticipated by the task plan, or represents a deviation

This is roughly analogous to Open Policy Agent (OPA) applied to agent actions: a declarative policy language evaluates each proposed tool call against a set of rules and either authorizes, denies, or escalates for human confirmation.

The escalation path is important. Not all anomalous actions are attacks. An agent might reach for a tool outside its typical scope because the task requires it — a legitimate edge case. Continuous authorization should support escalation to a confirmation gate (the user is asked to approve this specific action before it executes) rather than hard blocking everything outside a narrow allowlist.

Behavioral deviation detection adds another layer. An agent that has been making consistent API calls to read documents suddenly attempting to write to an external endpoint is a behavioral signal. A session that started with 10-second tool call intervals suddenly issuing 200 calls in 5 seconds is a signal. These signals don’t necessarily mean an attack is underway, but they should trigger increased scrutiny — tightening the policy enforcement threshold for subsequent calls, requiring confirmation for higher-risk actions, or suspending the session for review.

Mid-session revocation is the most aggressive control. If behavioral signals exceed a threshold, the authorization system should be able to revoke the agent’s session credentials before the session terminates naturally. Short-lived credentials reduce the window of exposure from a compromised session, but they do not provide immediate revocation without a real-time check — a 60-second credential still has up to 60 seconds of remaining validity. True mid-session revocation requires that enforcement points actively consult a revocation or token introspection endpoint before each call, or that the enforcement layer be positioned to drop the session connection directly. Short expiries and real-time revocation checks are complementary, not alternatives. A session that cannot be revoked mid-flight is a session that cannot be contained after an incident begins.

Cross-Agent Trust: The Orchestrator/Sub-Agent Boundary

Multi-agent architectures introduce a trust hierarchy problem that NIST SP 800-207’s user-centric model doesn’t address. When an orchestrator spawns a sub-agent, what claims does the sub-agent inherit, and how are those claims verified?

The multi-agent trust escalation post covers the attack classes in detail. Here we focus on the zero-trust architectural framing.

The zero-trust principle that applies here is explicit verification over implicit trust. An orchestrator trusting a sub-agent’s output implicitly — treating the sub-agent as fully trusted because the orchestrator spawned it — reproduces exactly the kind of implicit trust that zero-trust architecture was designed to eliminate.

Instead, cross-agent communication should carry explicit attestation:

Signed message envelopes. Every message from a sub-agent to an orchestrator should be signed using the private key bound to the sub-agent’s identity, with the corresponding identity document (the SVID or equivalent) presented for verification. The orchestrator verifies the signature against the identity document before acting on the message. This prevents message spoofing — an attacker-controlled source claiming to be a trusted sub-agent cannot forge a valid signature without the private key that the legitimate sub-agent holds.

Provenance chains. An agent’s identity document should include the identity of the parent that spawned it, creating a verifiable chain of provenance. A sub-agent claiming to be authorized for a specific scope should be able to demonstrate that its parent held that scope and explicitly delegated it. Permission that wasn’t delegated can’t be claimed.

Scope narrowing at spawn time. The POLP (principle of least privilege) applied to sub-agents means that each sub-agent should receive at most the permissions of its parent — and typically less, scoped to the sub-task being delegated. A parent agent with full read access to a document store spawning a sub-agent to summarize a single document should delegate read access to that document, not to the entire store. This prevents permission laundering, where a chain of delegations is used to aggregate permissions that no single principal would be granted.

Output validation before action. An orchestrator should not take actions directly based on sub-agent output without validation. If a sub-agent returns a tool call recommendation (“execute this code to proceed”), the orchestrator’s policy enforcement point should evaluate that recommendation against the current task scope before executing it — not simply forward it to the execution layer. This closes the confused orchestrator attack class, where adversarial content in the sub-agent’s input is reflected back in its output and then executed by the orchestrator.

Implementation Playbook

Bringing this together into a practical architecture, here is a reference implementation pattern:

1. Workload identity at agent spawn. Each agent instance receives a SVID-style identity document at initialization, issued by the agent orchestration framework. The document is signed with a private key held by the framework, includes the agent’s provisioned tool set and task scope, and carries a short expiration (15-60 minutes maximum). The agent presents this document with every tool call.

2. Tool-level enforcement points. Each tool integration (file system access, API call, code execution, message sending) operates behind a policy enforcement point that validates the agent’s identity document before executing the call. The enforcement point checks: Is this agent authorized for this tool class? Does the specific requested action fall within the document’s scope? Has the session exceeded any behavioral thresholds?

3. Short-lived tool credentials. The enforcement point issues a short-lived credential for the specific tool call if authorization passes. This credential (a JWT, a signed URL, a temporary IAM role assumption) expires in seconds and carries no further authority. The agent’s master identity document never directly authenticates to downstream systems; only the per-call issued credential does.

4. Audit log at every action boundary. Every tool call — authorized and denied — is logged with the agent’s identity document hash, the specific action requested, the authorization decision, and the tool call result. This log is the forensic record for incident investigation and the behavioral baseline for anomaly detection. Log retention and access controls on the audit log itself are security-critical: an agent that can write to its own audit log can erase its tracks.

5. Cross-agent message signing. In multi-agent configurations, every inter-agent message is signed with the sender’s identity document. Orchestrators validate signatures before processing sub-agent responses. The framework enforces scope narrowing at sub-agent spawn time.

6. Escalation and revocation gates. The system maintains a revocation list and a confirmation gate mechanism. Sessions can be suspended on behavioral anomaly detection. Actions outside a defined scope require user confirmation before execution. Revocation takes effect at the enforcement point level — revoked identity documents are rejected immediately.

How Existing Platforms Approach This

AWS Bedrock Agents provides the closest approximation to this model in a production system. Each Bedrock agent is configured with an IAM execution role that scopes its permissions to specific Lambda action group functions, S3 resources, and Bedrock model ARNs. Agents can be assigned separate execution roles per configuration. However, these controls are session-level: the agent authenticates once with its IAM role and holds those permissions for the duration of the session. Per-call scope narrowing and behavioral revocation are not natively supported — they require custom enforcement logic in the action group Lambda functions.

Anthropic’s Claude with OAuth integrations uses a user-delegated OAuth model: the user authorizes Claude to access third-party services, and Claude receives an OAuth access token with the scopes the user granted. This is structurally sound at the human-to-agent boundary, but it doesn’t address agent-to-agent trust: when Claude internally reasons about which tools to call, there’s no enforcement point that validates each call against the specific task scope. The OAuth token’s scope is the only constraint, and it’s session-level rather than per-action.

Google Vertex AI Agent Builder uses service accounts, one per agent configuration, with IAM permissions scoped to the tools the agent configuration requires. Similar to Bedrock, this provides service-level isolation but not per-call or per-task microsegmentation.

SPIFFE/SPIRE is not agent-specific but provides the workload identity infrastructure that a proper agent zero-trust implementation would be built on. SPIRE attestors can verify workload identity based on process attributes, Kubernetes pod labels, cloud instance metadata, and custom attestation plugins. What SPIRE attests to natively is infrastructure identity — the workload is running in this pod, on this node, under this service account. It does not natively attest to mutable application-level claims like which system prompt is loaded or what task scope was authorized at runtime. Binding those application-level claims into the identity requires a separate trusted component: a launcher or orchestration framework that measures those values at agent initialization, signs them, and either embeds them as SVID custom attributes or reissues a SPIRE-backed SVID via a custom attestation plugin whenever the configuration changes. An agent framework built on this model would use SPIRE for the infrastructure attestation layer and layer agent-specific claims on top.

What Zero-Trust for AI Agents Doesn’t Yet Solve

Intellectual honesty requires acknowledging the gaps that this architectural model doesn’t close.

Semantic policy is still hard. An enforcement point that evaluates “is this tool call consistent with the task scope” needs to understand task scope semantically, not just syntactically. Checking that a file write goes to an authorized path is easy. Checking that the content being written is consistent with the agent’s summarization task — and not an exfiltration attempt disguised as a summary — requires semantic understanding that current policy engines don’t provide.

The model is still unauditable. SPIFFE-style identity documents attest to the runtime configuration of an agent. They don’t attest to the model’s internal reasoning. An agent that was properly initialized with the right task scope can still decide, through its internal inference process, to pursue a goal the operator didn’t intend. Zero-trust architecture closes the authorization gap; it doesn’t close the alignment gap.

Long-horizon tasks break the per-session model. A task that takes hours involves state that accumulates across many tool calls. Re-authenticating and re-authorizing at each call boundary is expensive and creates UX friction for legitimate long-running tasks. Calibrating the enforcement granularity — tight enough to catch deviations, loose enough to be usable — is an unsolved operational problem.

Inter-agent message signing has no standard. The cross-agent trust model described above requires that all components of a multi-agent system implement the same signing and verification protocol. In practice, agents are built with heterogeneous frameworks (LangGraph, CrewAI, AutoGen, bespoke orchestration) that don’t share a common inter-agent protocol. Enforcing signing across framework boundaries requires either standardization (which doesn’t exist yet) or gateway-based enforcement (which adds latency and operational complexity).

These gaps are not reasons to avoid implementing zero-trust controls for agent deployments. They’re reasons to be specific about what those controls do and don’t provide, and to layer them with the broader defense-in-depth stack described in our Defense-in-Depth for AI Agents post.

The Verification Principle, Applied to Agents

Zero-trust’s core claim — never trust implicitly, verify explicitly — remains sound when applied to AI agents. The adaptation required is in what gets verified and when.

For human users, verification happens at session boundaries: authenticate the user, authorize the session, re-evaluate periodically. For agents, verification needs to happen at action boundaries: authenticate the agent instance, authorize the specific action, re-evaluate continuously.

The tooling to do this properly doesn’t exist as a coherent product. But the components exist: workload identity infrastructure (SPIFFE/SPIRE), short-lived credentials (any OIDC-compatible issuer), policy enforcement (OPA or equivalent), and behavioral monitoring (your existing observability stack). What’s missing is the glue — agent frameworks that natively integrate with these components rather than treating security as an afterthought to be bolted on by the operator.

Until that integration matures, the practical minimum is: one IAM role per agent configuration, short-lived credentials for every external call, an audit log at every tool invocation, and a human confirmation gate for any action that can’t be reversed. That’s not zero-trust by the NIST SP 800-207 definition, but it’s a meaningful reduction in blast radius — and it’s the foundation on which proper zero-trust for agents can be built.

---

For related reading: The Confused Deputy Problem in LLM Tool Use covers the structural authorization failure mode that zero-trust architecture is designed to prevent. Multi-Agent Trust Escalation covers the specific attack classes that emerge from implicit trust in agent hierarchies. Defense-in-Depth for AI Agents covers the full security stack for agent deployments, of which zero-trust is one architectural layer.