AI Agents Need Zero Trust Too: Containing the Non-Human Worker

01 Agents Reach Production, Carrying Real Credentials

Through 2025 and into 2026, AI agents crossed a line that matters more to security engineers than any benchmark: they started doing things. Not drafting text for a human to review, but executing - opening pull requests, triaging tickets, reconciling invoices, querying production databases, filing external requests on a customer's behalf. Every one of those actions is performed under some credential, and that credential was almost always designed for a person.

Enterprises spent the last decade rebuilding access control around zero-trust principles: verify explicitly, grant least privilege, assume breach. The framework was engineered for human users with laptops and for servers with fixed workloads. It was never designed for the principal now asking for access - a non-deterministic program that plans, improvises, and can chain a dozen tools together in seconds.

This article is about containment: what breaks when the requester is software holding human-level permissions, and how zero-trust controls extend to agent runtimes. The reliability debate - whether agents are dependable enough for production at all - is a separate question, and it is not the question here. Assume the agent works. Assume it is useful. Then ask what happens on the day it is wrong, manipulated, or compromised, and what the access-control system does about it.

The uncomfortable answer, in most current deployments, is: far too much. Agents typically operate through inherited credentials - the developer's deploy key, the service account minted for an integration, the OAuth consent a user granted once and forgot. Blast radius, not raw capability, is the enterprise risk.

02 Where Human-Centric Access Models Fail

Access control inherited its mental model from people. Authentication assumes a human at a keyboard, capable of completing a challenge and legally accountable for what follows. Multi-factor verification works because a person is present. Session timeouts exist because human intent has a natural span, and a request approved at nine in the morning says little about authority at five in the afternoon. Role-based access control maps scopes to job titles, on the theory that a title predicts what a person needs to touch.

Agents violate each assumption. There is no keyboard and no person present; an agent may initiate thousands of actions per hour, at machine speed, in parallel, without fatigue or attention limits. Intent does not persist across a session - it is re-derived token by token from context, which means the same identity can behave radically differently from one call to the next. And a job title does not predict an agent's needs, because the agent is not the role: it is a delegate acting for a role, with a reach that depends entirely on which tools it was wired to.

The deepest failure is consent. A user approving an OAuth prompt sees one screen at one moment; the agent then exercises those scopes continuously, at a volume no human review anticipated. Credential hygiene erodes just as fast: keys copied into agent configuration, tokens pasted into prompts, secrets cached alongside the documents they unlock. None of this is exotic - it is the default convenience path. That is precisely why containment has to be designed in, because nothing in the human-centric stack pushes back on it.

03 Agent Identity: Defining Who Is Asking

Zero trust begins with explicit verification, so the first engineering task is definitional: when an agent calls a tool, who is asking? A useful answer has three layers, and collapsing them is the root cause of most agent-access failures.

The first layer is the human principal - the accountable owner on whose behalf the agent acts. This layer carries liability and audit accountability, but it should never be the credential the agent presents, because that collapses a delegate's authority into a person's identity. The second layer is the agent workload itself: which agent software, built by whom, running in which deployment environment. This is workload identity in the classic sense - the same discipline long applied to microservices - and it is the layer that should appear in access logs as the requester.

The third layer is the run: the specific task, session, or plan the agent is currently executing. Two invocations of the same agent may deserve entirely different permissions - summarizing a ticket versus executing a refund - so short-lived credentials minted per task, bound to a task identifier, are the natural unit of verification.

With those layers separated, verification becomes concrete: attest the runtime image, bind each request to a workload identity and a task identifier, and let policy evaluate all three. Who is asking stops being a philosophical puzzle and becomes a set of checkable attributes - which is exactly the shift zero trust has always demanded of every new class of principal.

04 Least Privilege for Tools, Not Just Data

Classical least privilege asks what data a principal may read. For agents the binding constraint is tool surface: what actions it may take, in which systems, with which side effects. A scoping model built for read access is nearly useless when the principal can write, transact, and delete.

Practical tool scoping starts with enumeration: every tool an agent can call becomes a discrete, named permission, reviewed like any other grant. Read-shaped tools get broad distribution; write-shaped tools get per-environment scopes, so an agent authorized in staging never carries production authority. Destructive or irreversible actions - payments, deletions, external communications - sit behind explicit elevation, granted per task and expiring with it.

Deny-by-default egress matters as much as tool scopes. An agent that can reach arbitrary network endpoints can exfiltrate whatever its context holds, so allow-lists of APIs and domains belong in the policy layer, not the prompt. Prompt-level instructions - do not call this API - are suggestions; policy enforcement is architecture.

Finally, agents should never hold raw secrets. Credentials belong to a broker that mints narrowly scoped, short-lived tokens per tool call, so the agent's context window never becomes a keychain. This is the same pattern that moved database passwords out of application code a decade ago; agents simply raise the stakes, because anything in context is both a credential store and, potentially, an exfiltration target. Least privilege for agents is less a new theory than an old discipline applied at machine speed.

05 Blast Radius: Designing for the Bad Day

Assume breach, the third zero-trust tenet, turns a blunt question: if the agent is wrong, hijacked, or prompt-injected right now, what is the maximum damage before anything stops it? That ceiling is the blast radius, and it is a design output - chosen, not inherited.

The chart sketches the problem. A human developer interactively holds a handful of permission scopes at once. A legacy service account holds more, but at least runs a fixed, inspectable workload. An autonomous agent runtime accumulates tool credentials across systems - code, infrastructure, data, communications - because its value comes from reach. Unless someone deliberately intervenes, the agent is the most privileged principal in the building.

Containment then becomes a set of budgets. Rate limits cap how many actions per minute an agent can take. Quotas cap cumulative financial exposure. Sandboxing confines code execution to throwaway environments. Credential partitioning ensures the identity authenticating to the data warehouse is not the same identity authenticating to email. And irreversible actions route through a human gate, sized so approval stays meaningful - a queue of four decisions a day, not four thousand.

The design goal is asymmetry: an agent should be able to do a great deal that is reversible and very little that is not, without anyone standing by. Measured that way, most current deployments fail not because agents are dangerous but because nobody ever drew the boundary. The permission set is the boundary; draw it on purpose.

06 Audit Trails for Non-Deterministic Actors

Forensics after an incident - and the continuous monitoring zero trust requires - both depend on audit trails. Agent trails need more columns than human trails, because an agent's action is the end of a reasoning chain, not the beginning of one.

For a person, who, what, and when is usually enough. For an agent, the decision context is the record: the prompt, the retrieved documents, the plan the model produced, the tool arguments it chose, the model version that made the choice. Non-determinism is the reason. The same input can yield different actions across runs, so reconstructing why an agent transferred funds requires the artifacts of that particular decision, not just the fact of the transfer.

Three practices make trails usable. Correlation identifiers should thread the entire chain - user request, plan, subtasks, tool calls - so one incident reconstructs as one story rather than disconnected API entries. Decision context should be captured to an immutable store, because logs the agent can influence are logs an attacker can influence. And anomaly detection needs retuning: velocity and volume thresholds calibrated for humans will never fire on an agent operating normally at fifty actions per minute, so baselines must be learned per workload.

There is a governance dividend, too. Rich decision-context trails are what make agent autonomy reviewable at all - they turn opaque behavior into evidence for policy tuning, incident response, and the standing question every security team will eventually ask: what, exactly, has this software been doing with its privileges?

07 Mapping to NIST SP 800-207 - and What to Do Now

NIST SP 800-207, the canonical statement of zero-trust architecture, predates agentic AI by years yet maps onto it with almost no translation. Its tenets read as if written for agents: every data source and computation service is a resource; communication is secured regardless of network location; access is granted per session; access decisions weigh dynamic attributes - identity, workload state, behavior - rather than network position; and everything is continuously monitored for integrity.

The standard's logical components slot directly into an agent runtime. The agent is the client. The policy enforcement point (PEP) sits in front of the tool gateway, wrapping every tool call. The policy decision point (PDP) evaluates each call against policy, drawing attributes - workload identity, task scope, egress target, action reversibility - from policy information points. The architecture does not care that the client is non-deterministic; it only requires that no request reaches a resource without a fresh decision.

The costs are real: per-call evaluation adds latency, approval workflows tax usability, and authoring policy for behavior that is not deterministic is genuinely hard. None of that changes the sequence. Inventory every agent and the credentials it touches. Issue workload identities; stop sharing human accounts. Broker credentials per task. Wrap tool gateways in enforcement points. Define blast-radius budgets and rehearse revocation - killing an agent mid-run should be a drilled operation, not an improvisation.

Zero trust, as a framework, has treated agents as first-class principals from day one: an untrusted requester asking for per-session access to a resource, judged by dynamic attributes. The remaining work is not theoretical. It is treating the non-human worker that way in production, starting with the next agent your organization ships.