Zero trust for AI agents: the identity boundary that finally has to hold

Zero trust was built for humans and services. It assumed a caller with a stable identity, a device you could fingerprint, and a session you could reason about. Agents break all three assumptions at once. And most teams are still trying to fit them into the old model — service accounts, shared tokens, network policies — and calling it zero trust for AI agents. It isn't. It's the same perimeter thinking, wearing a new hat.

We think zero trust for AI agents is a real category, but only if you stop pretending the agent is a user or a service. It's neither. It's a delegated caller acting inside someone else's session, invoking tools that hit systems the original identity already had permission to reach. That framing changes every control you put in place.

The old zero trust model breaks in three places

Microsoft's widely-cited framing of zero trust rests on three moves: verify explicitly, use least-privilege access, and assume breach. (NIST SP 800-207 formalises it as seven tenets, but the three-move version is what most teams actually build against.) All of them assume you can name the caller.

With agents, the caller is a probabilistic system running inside a session that belongs to a human. When a user asks their agent to "pull last quarter's pipeline and email it to finance," the tool call that hits Salesforce isn't from the user directly, and it isn't from a service either. It's from the agent, acting on the user's behalf, using the user's permissions, at a moment the user didn't explicitly authorise line-by-line.

The three breaks:

• Identity collapses. Teams issue the agent a service account. Now every tool call looks like it came from agent-prod-01, not the user. Audit logs lie. Row-level security stops working. Row-level anything stops working.
• Least privilege becomes meaningless. If the agent holds a token that can reach every user's data, "least privilege" is scoped to the whole tenant, not the requesting user. That's not least privilege. That's a shared admin key with a mission statement.
• Assume breach becomes unactionable. When something goes wrong, you can't answer whose session did the bad thing. The agent identity absorbed the blast radius of every user it ever ran on behalf of.

If your zero trust API access agents story ends at "we gave the agent an OAuth client credentials token," you don't have zero trust. You have a very well-documented shared account.

Delegated identity is the load-bearing idea

The fix isn't complicated to state. It's operationally hard. Every tool call an agent makes should execute as the authenticated user who initiated the session — not as the agent itself. The agent is a caller. The identity is the user's. The permissions the downstream API enforces are the permissions the user actually has.

That's the shift. Agent zero trust architecture stops being about giving the agent its own place in your IAM diagram and starts being about the agent being a conduit for a real user's identity, into systems that already know how to authorise that user.

This is why we've written before that agent identity and user identity are a boundary security reviews will demand. Collapsing them is the single most common failure we see. It looks fine in a demo. It fails the first serious pen test.

When delegated identity works, four things fall into place:

• Existing authorisation logic in the downstream API still applies. Row-level security, tenant scoping, feature entitlements — all of it works because the caller is a real user.
• Audit trails are honest. "User X's agent called endpoint Y at time Z" is a sentence you can write.
• Revoking a user revokes their agent's reach. No orphaned service credentials.
• The blast radius of a compromised agent is bounded by the permissions of whoever's session it was in — not by the union of everyone's permissions.

Zero trust agent permissions live at the tool call, not the network

The second thing most teams get wrong: they try to enforce zero trust at the network layer for agents. VPCs, mTLS between the agent and the model, private endpoints. All fine. None of it is the important boundary.

The important boundary is the tool call. That's where the agent stops reasoning and starts acting on a real system. And it's the only place with enough context to answer the questions zero trust actually asks:

• Which user is this being done on behalf of?
• What tool is being invoked and with what arguments?
• Does the user's identity carry the permission this action requires?
• Is this call consistent with the session's stated intent?

A network policy can't answer any of those. An API gateway (the difference matters) can answer the first two on a good day. The tools layer is the only place where all four are visible at once — because the tools layer is where identity, tool definition, arguments, and downstream call meet.

This is the concrete version of zero trust agent permissions: authorisation decisions get made where the tool executes, using the user's real credentials, against the real API. Not at a policy engine three hops upstream that's guessing.

How Pontil fits

This is the layer we built. Pontil is a Tools-as-a-Service platform — we make SaaS products accessible to AI agents, and the runtime executes every tool call as the authenticated user, never as a shared service account. That's not a feature we bolted on. It's the architecture.

The consequence: existing API-level authorisation keeps working. Audit logs name real people. Revocation is a solved problem, because it was already a solved problem for users — the agent just inherits it. And the boundary a security review will ask about — whose identity is this call actually running as? — has an answer that survives scrutiny.

Zero trust for AI agents is a category worth taking seriously. But it only holds if the identity boundary holds. Everything else follows from that one decision.

What follows from this

If you're designing agent access to your own product right now, the test isn't whether you have a policy engine, a gateway, or a nice diagram. The test is a single question: when the agent calls the API, whose identity is on the request?

If the answer is "the agent's," you're going to have the conversation eventually. Better to have it before the pen test, before the enterprise deal, before the incident. The rewrite isn't the whole product. It's the runtime boundary that decides whether zero trust is a claim you can defend or a slide you have to walk back.