What Is Zero-Trust Security for AI Agents?

Zero trust was built for a world of users, devices, and services. Autonomous AI agents break most of its assumptions. An agent is not a human at a keyboard whose behavior you can reason about, and it is not a static microservice with a fixed set of calls. It is a process that takes a goal, decides on its own which tools to invoke and in what order, and acts with authority delegated from the user or system that launched it. Give it a broad token for the session and it will use every scope that token carries, in combinations nobody anticipated, whenever its reasoning leads there.

That is the gap. Most agent deployments authenticate the agent once, hand it a credential, and then trust every tool call it makes for the rest of the session. The model's next action is only as safe as the reasoning that produced it, and that reasoning can be steered by a prompt injection, a poisoned document, or a tool result the agent did not expect. Standing trust plus unpredictable behavior is the precise condition zero trust was designed to eliminate.

This article applies zero-trust principles to agents concretely: why the perimeter model fails for them, what each pillar means when the actor is a non-human agent calling tools, and how a gateway enforces per-call authorization, scoped access, egress control, and audit on every single action.

Want per-call authorization and strong identity for every AI agent and tool call? Book a demo.

Why agents break the perimeter model

The perimeter model grants trust based on location or an initial authentication: once you are inside the network, or once you have logged in, you are trusted for what follows. It already strained under remote work and microservices. Agents break it outright for three reasons.

They act with delegated authority. An agent runs on behalf of a user or a system and inherits some slice of that principal's permissions. If the delegation is coarse, the whole session's worth of actions carries the user's full authority, whether or not any given action needed it.

They call tools, which means they take real actions. An agent is not just answering questions. It reads databases, sends messages, writes to systems, moves money, triggers workflows. Each tool call is an action with consequences, and the agent decides on each one dynamically.

They chain actions in ways you cannot enumerate ahead of time. The output of one tool becomes the input to the agent's next decision. A read can lead to a write; a search result can introduce an instruction. You cannot pre-approve the call graph because the agent builds it at runtime, partly from data it just received.

Put those together and a standing session token is a loaded weapon. If an injected instruction convinces the agent to call delete_records or transfer_funds, a session-scoped token that includes those permissions will let the call through, because nothing re-checks the specific action against the specific context. The problem is not that the agent was authenticated; it is that authentication was treated as authorization for everything that followed.

The zero-trust pillars, applied to agents

Zero trust is usually stated as a handful of principles: never trust, always verify; least privilege; per-request authorization; assume breach; and audit everything. Here is what each one means when the actor is an agent.

Never trust, always verify. Do not trust an agent because it authenticated at the start of the session or because it is running inside your network. Verify its identity and its authority on every request. The agent's reasoning is not a trust anchor; it can be manipulated by the very data the agent is processing.

Least privilege. Grant the agent only the permissions a given task needs, and only for as long as it needs them. An agent summarizing invoices needs read access to invoices, not write access to the payments system. Least privilege for agents is scoped to the action, not granted for the session.

Per-request authorization. Authorize each tool call individually, with the full context: which agent, acting for which user, calling which tool, with which arguments, right now. This is the pillar that most directly answers the chained-action problem, because every link in the chain is evaluated, not just the first.

Assume breach. Design as though the agent is already partially compromised, because prompt injection makes that a routine condition, not an edge case. If you assume the agent may be steered into a malicious call, you stop relying on the agent to police itself and move the control outside it.

Audit everything. Every action an agent takes must be attributable and logged: who it was for, which identity made the call, what was requested, and what the policy decided. Without this you cannot investigate an incident or prove compliance, and you cannot tell a legitimate action from a subverted one after the fact.

Pillar one: strong agent identity

Everything downstream depends on knowing who the actor is, and for agents that is harder than for humans. An agent is a non-human identity. It needs a credential that is its own, not a human's API key borrowed for convenience, and not a shared secret baked into an image.

Done well, an agent has a distinct, verifiable identity, and the system also knows the human or service on whose behalf it is acting. That dual identity, the agent plus the delegating principal, is what lets authorization be meaningful. Established non-human-identity mechanisms apply here: workload identity frameworks such as SPIFFE issue short-lived, verifiable identities to services, and OAuth 2.1 patterns govern how delegated authority is represented and passed. The specifics of establishing and propagating that identity are covered in AI agent identity and MCP authentication.

The anti-pattern is the shared, long-lived key. When ten agents share one API key, you cannot attribute an action to a specific agent, you cannot revoke one agent without breaking the others, and you cannot scope permissions per agent. Identity is the pillar that makes every other pillar enforceable, so it comes first.

See how TrueFoundry enforces least-privilege, scoped access for agents at the gateway. Book a demo.

Pillar two: per-call authorization, not a standing token

This is the heart of zero trust for agents, and the sharpest break from how most systems work today.

The common pattern issues the agent a token at session start carrying every permission it might need, then trusts every call that token accompanies. Zero trust replaces that with authorization on each call. When the agent wants to invoke a tool, the request, carrying the agent's identity and the delegating user's identity, is evaluated against policy before it executes. The policy can consider the tool, the specific arguments, the user's own permissions, and the context.

Concretely, "is this agent allowed to call the database tool" is the wrong question. The right one is "is this agent, acting for this user, allowed to run this specific query against this table right now." A read of the user's own records: allow. A read of another user's records, or a DELETE: deny, regardless of the fact that the agent holds a database tool in its catalog.

This is where fine-grained authorization models matter. Role-based access control gives a baseline, but agent actions often need attribute- and task-based decisions that consider the specific request. The trade-offs between these models are laid out in RBAC vs ABAC and fine-grained authorization. For agents specifically, scoping authority to the task the agent is currently performing, rather than to a broad role, is the idea behind task-based access control: the agent gets the authority for the task in front of it and nothing more.

Pillar three: scoped and just-in-time tool access

Least privilege becomes real through two mechanisms: scope and time.

Scope narrows what a grant covers. Instead of "access to the CRM," the grant is "read access to the contacts this user owns." The narrower the scope, the less an agent can do if its reasoning is subverted, and the less an attacker gains from a single poisoned instruction.

Time narrows how long a grant lasts. Just-in-time access issues a short-lived credential for the action at hand and lets it expire, rather than holding a long-lived token that remains valid, and stealable, for the whole session and beyond. A credential that lives for one call and ten seconds is far less useful to an attacker than one that lives for the session.

Together they bound the blast radius on both axes. A compromised agent with a scoped, just-in-time grant can do one narrow thing for a short window. The same agent with a broad, session-long token can do everything that token allows for as long as the session runs.

Pillar four: egress control

Agents reach outward, to tool servers, APIs, and external endpoints, and that outbound path is its own control surface. Egress control governs where an agent can send data and which external destinations it can reach.

Without it, a subverted agent can exfiltrate: an injected instruction tells it to send the context it has gathered to an attacker-controlled endpoint, and nothing stops the outbound call. With egress control, the agent can only reach approved destinations, and attempts to reach others are blocked and logged. In an MCP context this also means governing which tool servers an agent may connect to at all, so it cannot be redirected to an impersonated or malicious server. This ties directly to enterprise MCP governance, where controlling and auditing tool-server access is the core function.

Pillar five: continuous verification and audit

Zero trust is not a one-time gate; it is continuous. Each request is re-verified, and every decision is recorded.

The audit trail for agents has to answer, for any action: which agent did this, for which user, which tool and arguments were involved, what did policy decide, and when. That record serves two masters. For security, it is how you investigate whether an action was legitimate or the product of a subverted chain. For compliance, it is the evidence that access was controlled and attributable. Because agents act fast and in volume, the audit has to be automatic and complete; sampling will miss the one call that mattered.

How a gateway enforces zero trust

The reason a gateway is the natural enforcement point is the same reason it works for other cross-cutting controls: it is the single layer every agent tool call passes through. Enforcing zero trust in each agent's code would mean trusting every agent to police itself, which is exactly the assumption zero trust rejects. Moving enforcement to the gateway puts the control outside the thing that might be compromised.

Walk one tool call through it. The agent, holding its own identity, asks to invoke a tool. The gateway receives the call with the agent's identity and the delegating user's identity propagated in. It evaluates policy for this specific call: is this agent, for this user, permitted this tool with these arguments. If yes, it issues a scoped, short-lived grant, forwards the call, and controls the egress destination. If no, it denies the call and returns a defined error. Either way, the decision is written to the audit trail, tagged by user, team, and model.

This is how TrueFoundry's AI gateway and MCP gateway are built: identity propagation, fine-grained authorization on each tool call, governed tool access and egress control, and per-request observability with a full audit trail, all enforced at the layer the traffic already flows through. Because the data plane can run in your own environment (SaaS, VPC, on-prem, or air-gapped), the enforcement point and the audit stay inside your boundary.

Where teams get this wrong

Authenticating the agent, then trusting the session. The single most common mistake. One login, a broad token, and every subsequent tool call is waved through. This is standing trust, the exact thing zero trust removes, and it means a prompt injection mid-session inherits the full token.

Giving agents human-shaped credentials. Reusing a human's API key, or a shared service key, for an agent destroys attribution and scoping. You cannot say which agent did what, and you cannot revoke or narrow one agent without affecting others. Agents need their own non-human identities.

Role-based access as the whole story. A coarse role ("agents can use the database") authorizes the tool, not the action. Zero trust needs the decision to consider the specific call, the arguments, and the user it is for, which is where attribute- and task-based authorization come in.

Enforcing in the agent's own code. If the policy check lives inside the agent, a subverted agent can be reasoned around it. Assume-breach means the enforcement point must be outside the agent, on the call path, where the agent cannot talk its way past it.

No egress control. Teams lock down what an agent can read and forget where it can send. Exfiltration happens on the outbound path. Without egress control, a subverted agent's final step, shipping the data out, has nothing standing in its way.

Conclusion

Zero trust for AI agents is a single idea applied relentlessly: no action is trusted because of who the actor is or that it authenticated earlier. Every tool call is verified against a real agent identity and authorized on its own merits, with the least privilege the task needs, for the shortest time it needs it, and every decision is recorded. The pillars are the familiar ones; what changes is that the actor acts autonomously, takes real actions, and may be steered by the data it processes.

The practical consequence is architectural. Because you must assume the agent can be subverted, enforcement belongs outside the agent, at the gateway every tool call passes through, where identity is propagated, each call is authorized with full context, access is scoped and short-lived, egress is controlled, and the audit trail is complete. Build it there and a compromised agent is bounded to one narrow action instead of everything a session token allows.

Bring zero-trust to your AI agents. Book a demo.