Zero Trust for AI Agents: What to Verify When There Is No Session

The agent that worries you is authorized. It holds a service account you provisioned, calls tools you approved, and reaches destinations someone signed off on. Zero trust asks two questions at every decision point, who is this and what are they allowed to do, and an agent redirected by trusted input answers both correctly every time.

For a person those questions fire at a session boundary, where context gets re-checked. An agent on Kubernetes has no such boundary. Its token is mounted at start and refreshed on a timer with no decision attached, and the process runs for weeks.

What follows is what short-lived per-tool tokens fix, what they leave open, and the third question a zero trust program has to ask when the actor never logs in.

What zero trust asks of a workload

Zero trust asks two questions at every access decision: who is making this request, and is this requester allowed to make it. Both questions sit ahead of the connection in NIST’s architecture document, which describes authentication and authorization as discrete functions performed before a session to an enterprise resource is established.

For a workload, the first question resolves to a workload identity and the second to a set of entitlements attached to it. A service account presents a token, the API server or the cloud IAM plane checks the signature and the binding, then checks what that principal is permitted to do, and the request either proceeds or does not.

Both checks test standing: who the requester is, and what it holds permission to do. Conduct sits outside both of them. That is not a defect in the model, because for most of the workloads you run, standing and conduct are close enough to identical that the distinction never surfaces. A deployment does what its image says it does, every time.

Where the verification events are when the workload is a person

A person produces events all day, and each event is a place the two questions get asked again. They log in, and that is the first decision. Opening a privileged console triggers a step-up. When their laptop falls out of compliance and the platform evaluates access continuously, the next resource request re-opens the decision that the earlier posture supported.

Each of those moments carries the same structure: something happens, the policy engine notices, and trust is re-established or withdrawn before work continues. Between the moments, trust is inherited. A session is the thing that carries the last decision forward until the next event forces a new one.

That inheritance is why zero trust for people works with a finite number of decisions. The events arrive often enough, and close enough to the risky actions, that the gap between decisions stays small. Continuous verification, in practice, means verification at boundaries.

An agent has no session boundary

An agent workload starts and its credential is already there. The ServiceAccount admission controller attaches a projected volume to the pod, and the kubelet fetches a time-bound token from the TokenRequest API to fill it. That token is bound to the pod, scoped to the API server as its audience, and expires after a defined lifespan that defaults to one hour.

One hour sounds like a boundary. It is not one, because the kubelet refreshes the token before it expires, on its own, as a provisioning operation. Nothing about the refresh asks whether this workload should still be trusted. No posture is re-evaluated, no context is re-checked, and no engine is given the chance to say no. The credential is reissued because the pod is still running, and the pod is still running because nobody deleted it.

A token issued through TokenRequest has no revocation path of its own, and the documented way to end its validity is to delete the pod it is bound to. So the agent’s real credential lifetime is the lifetime of the process, which for a long-running agent is measured in weeks.

Stack those facts and the gap is structural. A person accumulates decision points as a by-product of working. An agent accumulates none. Its identity was verified once, at a moment when it had done nothing yet, and every hour since then the system has renewed that verdict without re-examining it.

What short-lived per-tool tokens fix

Per-tool credentials close part of that gap, and the part they close is real. Instead of one mounted token that opens everything the agent is entitled to, the agent requests a credential for a specific tool or API when it needs one, from a broker that issues it with a short expiry and a narrow scope.

That request is a genuine decision point, and it buys three things the mounted token cannot. The broker can refuse, which gives you a place to enforce policy that exists outside the agent’s own process. The credential expires on a timescale shorter than the incident, which shrinks what a leaked secret is worth. The broker logs every issuance, which gives you a record of what the agent asked for that does not depend on what the agent says it did.

Take that improvement seriously, then look at what the decision point evaluates. The broker asks who is requesting this credential and whether this requester is entitled to it. Both answers come back clean, because the requester is the agent you provisioned and the tool is one you approved for it. A stolen credential fails those checks. An agent using its own credential for work you never intended passes them, at every renewal, however short you make the interval.

Asking the same two questions more often produces the same two answers more often.

The agent that passes both checks while doing the wrong thing

The failure mode this leaves open has a name. Coercion is what happens when trusted input redirects an authorized agent’s capability: a support ticket, a web page, a document in a RAG index, or a tool response carries instructions the agent treats as work, and the agent goes and does that work with the permissions you gave it. Every individual step is allowed. The sequence is the attack.

There is no compromise to detect here. No credential was stolen, no container was escaped, no permission was escalated. The identity is correct and the entitlements are correct, which is why both checks pass.

The third question: is this agent behaving like itself

The reference you need is already being produced, every hour, by the agent itself. Coercion is detectable as a change in how an agent acts. The coercion breakdown makes the case for why prior behavior is the only available reference for a control like this, so what follows is the binding: what the reference is made of, what it is held against, and what a deviation from it is allowed to decide.

The reference is a profile of one agent’s observed activity at runtime. The processes it spawns, the files and secrets paths it touches, the destinations it opens connections to, and the volume and shape of the calls it makes. All of that is visible at the kernel and network layer whatever the agent framework is, which keeps the reference outside the process being judged. A tool invocation shows up there as the work it does: the request it sends, the path it reads, the process it starts.

The profile is learned per agent. ARMO builds it as an Application Profile DNA (APD™), assembled from what the workload actually did across an observation period, and it is the same primitive behind per-agent guardrails. A generic profile of how AI workloads behave would describe the framework rather than the job, and every agent in your cluster shares the framework.

The profile is held against the workload object the agent runs as, which is what makes a deviation attributable to something a responder can act on.

The profile produces evidence, weighted by what deviated from it. An agent that has never read a credential path reading one is a strong signal by itself. An agent opening a connection to a destination outside everything it has ever reached is close behind. A new file read inside a directory the agent already works in is weak alone and means something only in company. Treating all three as equal is how a behavioral control earns the same reputation as the rule-based tooling it replaced.

So the third question stands alongside the first two, and its answer is the one that changes while the agent is still running. Producing that answer is the job of runtime behavioral security for AI workloads.

Where behavior sits in a zero trust program

A behavioral signal enters a zero trust program in three places, and only one of them is the access decision itself: as a case a human reads, as policy input, and as an enforcement state held per agent.

A case a human reads is where to start, and for most teams it is where to stay for the first few months. A deviation arrives with the surrounding activity attached, the identity it ran as, the sequence that preceded it, and the destinations involved, which is the same material an investigation would assemble by hand across the detection surfaces. A human decides what it means. The cost of being wrong is an hour of someone’s time.

Policy input is the next step and it runs offline. Observed behavior becomes a proposed permission set, a proposed egress list, a proposed set of tools, and those proposals get reviewed and applied through the mechanisms you already use for policy. That is runtime-derived least privilege, and it tightens what the agent can do before any decision engine is involved, so the tightening survives even if the behavioral signal is never wired to anything.

An enforcement state held per agent is the third, and it lives on the workload itself. Each agent sits in observation or in enforcement for a defined set of actions, and the order runs from observing everything to enforcing narrowly on the paths that are never legitimate, which is the progressive enforcement sequence.

Wiring a behavioral signal directly into a policy decision point is an architectural choice, and it is a bigger one than it looks, because a false positive at that junction is an outage. The signal is worth having long before you make that call.

Verification has to include what the agent is doing

A zero trust program for agents is complete when it can answer three questions about a workload that never logs in: who it is, what it is entitled to, and whether it is behaving like itself. The first two you already answer, and the machinery that answers them transfers: a distinct identity per agent workload, entitlements cut to its job, credentials issued per tool where the tooling supports it. That is the direction standards bodies are converging on for agent authorization as well.

The third question is the one the architecture does not currently ask, and it is the only one of the three whose answer can change between the moment an agent starts and the moment somebody deletes the pod. An agent that has been redirected still holds the right identity and the right permissions. What it stops holding is its own pattern of work, and that is the thing left to verify. ARMO’s AI workload security learns that pattern per agent and runs it in Audit first, so you see what your agents are doing before anything gets blocked.

FAQ

How do I give each agent its own identity without rebuilding my auth stack? You mostly do not need to. A dedicated Kubernetes ServiceAccount per agent workload, bound to a cloud role through workload identity federation, gives you a distinct principal without a new identity provider. Most of the work is hygiene: one agent per workload object and one ServiceAccount per workload object, so that the principal and the thing whose behavior you are watching are the same object. Namespace default ServiceAccounts defeat this quietly and are the first thing to audit.

How long before a behavioral reference for an agent is usable? It depends on how varied the agent’s legitimate work is, and for a production agent on a steady workload the honest range is one to two weeks of observation before deviations are worth acting on. Agents with weekly or monthly task types need at least one full cycle. Observe for that whole period and treat early deviations as a question about the reference rather than a finding about the agent.

What do I do about an agent whose legitimate behavior changes every release? Bind the reference to the workload object so that a rollout is an event you can see, then treat the rollout as the boundary between expected change and unexpected change. A deviation that starts at a rollout is a re-baseline. A deviation that starts without one is a finding. Model and tool changes deserve the same treatment even when the image does not change, and that is the case worth instrumenting first.

Where does a behavioral signal go in a zero trust architecture I already run? Treat it as an additional input to the policy decision point and start by sending it somewhere a human reads. The useful first integration is the case management path: deviations arrive as cases with the surrounding activity attached, and the team decides. Wiring behavior directly into an authorization decision is a later and bigger step, because a false positive there takes a service down.

How do I roll this out without blocking a production agent? Observe across every agent workload first and enforce nothing. Then enforce on the narrow set that is never legitimate for that agent, which is usually credential paths and destinations outside the observed egress list, and only on the highest-privilege workloads to begin with. Every block a developer or operator sees should carry the reason and the observed baseline it violated, or the program loses its welcome in the first week.