Zero trust for AI agents means no agent is trusted by default: every tool call, retrieval, and outbound action is authenticated, authorized, and inspected before it touches a system, regardless of which agent issued it or what it claims to be doing. The principle is unchanged from the human case. Almost every control built to implement it assumes a human, and that assumption is where the model breaks.
This is a control map rather than a manifesto. It covers what the foundational documents actually say about non-human subjects, which of their controls an agent can and cannot satisfy, and what to put in place of the ones it cannot.
Can you apply NIST SP 800-207 to autonomous agents?
Yes, and more directly than most people realize, because NIST wrote about AI agents in the original document and almost nobody cites it.
NIST Special Publication 800-207, Zero Trust Architecture, was published in August 2020 and has never been revised. Section 5.7 is titled "Use of Non-person Entities (NPE) in ZTA Administration." It is two pages long, and it describes the agent security problem two years before ChatGPT shipped:
"Artificial intelligence and other software-based agents are being deployed to manage security issues on enterprise networks. These components need to interact with the management components of ZTA (e.g., policy engine, policy administrator), sometimes in lieu of a human administrator. How these components authenticate themselves in an enterprise implementing a ZTA is an open issue."
It then names the attack:
"The associated risk is that an attacker will be able to induce or coerce an NPE to perform some task that the attacker is not privileged to perform. The software agent may have a lower bar for authentication (e.g., API key versus MFA) to perform administrative or security-related tasks compared with a human user. If an attacker can interact with the agent, they could theoretically trick the agent into allowing the attacker greater access or into performing some task on behalf of the attacker."
Inducing a software agent to perform a task the attacker is not privileged to perform is prompt injection. A lower authentication bar for a non-human identity is the credential gap every agent deployment still has. Performing a task on behalf of the attacker is the confused deputy. All three are named, in the foundational zero-trust document, in 2020. Any vendor telling you agents are a category the standards never anticipated has not read section 5.7.
So the answer is not that NIST ignores agents. It is narrower and more useful: NIST permits non-human subjects and then calibrates every control and every example to human tempo and human authenticators. Tenet 4 explicitly allows that "client identity can include the user account (or service identity) and any associated attributes assigned by the enterprise to that account or artifacts to authenticate automated tasks." Section 3.3 defines subjects as covering "human and processes." The permission is there. The calibration is not.
How is zero trust for AI agents different from zero trust for users?
Three of the seven tenets survive contact with an agent unchanged. Three need rebuilding. One quietly inverts.
| NIST tenet | Holds for agents? | What changes |
|---|---|---|
| 1. All data sources and computing services are resources | Yes | Add tools, MCP servers and retrieval indexes to the resource inventory |
| 2. All communication secured regardless of location | Yes | Unchanged |
| 3. Access granted on a per-session basis | No | Agent work has no session boundary; scope has to bind to a task instead |
| 4. Access determined by dynamic policy | Partly | Behavioral attributes are calibrated to human rates and produce noise at machine rates |
| 5. Enterprise monitors integrity of all owned assets | Yes | The asset now includes the tool schema, which can change between calls |
| 6. Authentication and authorization dynamic and strictly enforced | No | Its named control is MFA, which no workload can perform |
| 7. Collect information to improve posture | Yes, and it matters more | The record has to reconstruct a decision chain, not just an access |
Last verified: September 2026.
Tenet 6 is the one that simply does not translate. Its text ties dynamic enforcement to identity and access management, and the concrete control it names is multifactor authentication. An agent has no second factor. It has a secret, and a secret is one factor no matter how long it is.
CISA's Zero Trust Maturity Model makes this visible in a way that is almost uncomfortable to read side by side. Version 2.0, published April 2023, defines identity in section 5.1 as "an attribute or set of attributes that uniquely describes an agency user or entity, including non-person entities." Non-person entities are explicitly in scope. Then Table 2 sets the Optimal state for authentication as "Agency continuously validates identity with phishing-resistant MFA, not just when access is initially granted," with the Advanced stage specifying FIDO2 or PIV.
A workload cannot present a PIV card. A workload cannot satisfy FIDO2 user verification, because the user verification step is the part that requires a user. An organization running autonomous agents therefore cannot reach Optimal on the identity pillar for those identities, not through underinvestment, but because the rubric has no row for them. The same document says as much on page 11: "Methodologies such as recommendations to best incorporate machine learning and artificial intelligence capabilities within zero trust solutions are not included in this model."
That is not a criticism of CISA. It is a scoping statement, published plainly. It does mean that an agency or enterprise measuring agent identity against the ZTMM is measuring against a ruler that was not built for the object.
What does continuous verification look like at machine speed?
This is where the human calibration does real damage, and NIST's own worked example shows exactly how.
Section 3.3.1 describes a contextual trust algorithm, one that weighs a subject's recent history rather than judging each request alone. NIST recommends it: "Ideally, a ZTA trust algorithm should be contextual." Then it illustrates the idea:
"For example, if an employee in the HR department of an agency normally accesses 20 to 30 employee records in a typical workday, a contextual TA may send an alert if the access requests suddenly exceed 100 records in a day."
One hundred records in a day is the anomaly threshold. A support agent doing legitimate work clears that in the first minute of its first run. Every behavioral baseline inherited from user analytics has this property: the agent's normal is the human's incident.
Which leaves two failure modes, and NIST names both of them in section 5.7: "false positives (innocuous actions mistaken for attacks) and false negatives (attacks mistaken for normal activity)." Raise the thresholds until the agent's legitimate volume fits and you have built a control that alerts on nothing. Leave them where a human sits and the queue fills in an hour and gets muted by Friday. Volume anomaly detection, transplanted directly from user behavior analytics, degenerates into one or the other.
What replaces it is not a better threshold. It is a different question. Instead of asking whether this volume is unusual, ask whether this specific action is permitted for this task, right now, given what this agent has already touched. That evaluation happens per call rather than per session, which is why it has to run in the path of the action rather than in a report afterward. A daily report that an agent read 4,000 records tells you about something that finished yesterday.
The useful signals at machine speed are shape rather than volume. An agent that reads from an untrusted source and then writes outbound is a shape. An agent calling a tool it has never called in that task class is a shape. An agent whose retrieved context changed the tools it selected is a shape. None of those require a baseline of normal.
What identity does an AI agent authenticate with?
The honest answer as of September 2026 is that the standards are mid-argument, and the argument is worth following because it determines what you can build now.
The distinction that matters is old. RFC 8693, OAuth 2.0 Token Exchange, published January 2020, separates impersonation from delegation:
"When principal A impersonates principal B, A is given all the rights that B has within some defined rights context and is indistinguishable from B in that context."
Against delegation, where "principal A still has its own identity separate from B, and it is explicitly understood that while B may have delegated some of its rights to A, any actions taken are being taken by A representing B." The RFC then adds a sentence that reads differently in 2026 than it did when it was written: "In a sense, A is an agent for B."
Impersonation is what most agent deployments actually do, and it is the wrong choice. If the agent is indistinguishable from the user, your audit trail records the user doing things the user never asked for, and the blast radius of a compromised agent is the full set of that user's rights. Delegation keeps both identities in the record. That is the difference between an incident you can reconstruct and one you can only apologize for, and it is why recording which human identity the agent was acting under is a design requirement rather than a logging nicety.
There is a trap here that catches experienced architects. Microsoft's on-behalf-of flow is widely assumed to be RFC 8693 token exchange. It is not: it uses the RFC 7523 jwt-bearer assertion grant plus a Microsoft-specific requested_token_use parameter. More importantly, Microsoft's own documentation states the constraint directly: "the OBO flow only works for user principals." An autonomous agent with no signed-in user cannot use it and must fall back to client credentials, which erases the user from everything downstream. If your delegation design assumed OBO would carry user context through an autonomous agent, it will not.
For workload identity itself, SPIFFE is the mature option, a CNCF graduated project since August 2022, issuing identities as URIs of the form spiffe://trust-domain/path. One property deserves more attention than it gets. The specification states that trust domain names "are nominally self-registered, unlike public DNS there is no delegating authority," and that consequently "there is no guarantee of global uniqueness nor is there any technical means for preventing distinct trust domains from using identical trust domain names." Inside one organization that is fine. Across a partner boundary, a SPIFFE ID is not self-validating and you need an out-of-band agreement about whose trust domain is whose.
The live development is at the IETF. On 15 September 2026 the WIMSE working group adopted draft-ietf-wimse-aims-00, "AI Identity Management System," co-authored by people at Defakto Security, AWS, Zscaler, Ping Identity, OpenAI, and Okta. The author list is the signal. It frames an agent plainly as "a workload that iteratively interacts with a Large Language Model (LLM) and a set of Tools, Services and Resources," and carries one normative rule most current architectures violate:
"The Large Language Model MUST NOT have access to an agent's credentials or to credentials that may be needed to access tools and services. This prevents the Large Language Model from using, exposing, or being manipulated via prompt injection into disclosing the credentials."
It is a draft, not an RFC, and no WIMSE document has reached RFC status. Treat it as direction rather than obligation. But if you are designing agent identity this quarter, that MUST NOT is the cheapest thing on this page to comply with, and the most expensive to retrofit. Our deeper treatment of the identity problem is in the case against treating agents as non-human identities.
How do you scope permissions per task instead of per agent?
Tenet 3 says access is granted per session, with least privilege, and that "authentication and authorization to one resource will not automatically grant access to a different resource." Agents do not have sessions in any sense the tenet would recognize. A long-running agent may work for hours across dozens of resources under one grant, which is the opposite of what the tenet asks for.
The protocol layer has now made this explicit rather than implied. MCP, as of the 2026-07-28 revision, is a stateless protocol: "A server processes each request independently; no state should be inferred from previous requests, even those on the same connection or stream." It goes further, warning that "an open connection, such as a STDIO process, is not a conversation or session." If your authorization model binds scope to a connection, the protocol has told you that binding is unsound.
So bind it to the task. Three rules do most of the work.
Effective authority never exceeds the invoking user. If a support agent can read any account because its service principal can, then any user who can read one account has just been handed the ability to read all of them by asking the agent nicely. This is the single most common real finding in agent deployments and it is an authorization design error, not a runtime one.
Credentials are minted per call, not held. A standing token with a broad scope is a token an injected instruction can spend. Exchange the caller's context for a downscoped credential at the moment of the call, so the token issued for a refund lookup carries the entitlement for that one account and expires in minutes. Your identity provider already implements the flows; the work is wiring the agent runtime to call them per action instead of once at startup.
Irreversible actions are a separate class. Reads and builds can flow. Deletes, transfers, sends, deploys, and credential use are held for approval regardless of scope, because the cost of being wrong is not symmetric. Defining that class once and enforcing it per repository or per system is what scoping permissions per task rather than per agent means mechanically.
Trust boundaries matter here too. An agent that reaches tools through MCP servers has a boundary at every server, and governing every MCP server your agents connect to is where those boundaries get enforced rather than assumed.
Do you need a human in the loop for a zero-trust agent?
Not everywhere, and treating human approval as the primary control is how organizations end up with approval fatigue and a rubber stamp.
Gate on reversibility, not on risk score. An action that can be undone with a known procedure does not need a human. An action that cannot be undone does, every time, regardless of how confident the model is. That is a small list in most estates: production deletes, fund movement, outbound communication to external parties, credential issuance, infrastructure destruction, and force pushes.
The gate also has to sit below the agent rather than inside it. An approval prompt the agent itself renders is an approval the agent can be persuaded to skip. Auto-run settings and aggressive modes exist in most agent frameworks precisely to remove friction, which means a control that lives in the framework is a control the user can turn off.
Everything else should be governed by policy that runs without a person, because a control that requires a human at machine speed is a control that will be disabled in week three.
The five controls, in the order they pay off
If you implement in this order, each step makes the next cheaper.
1. Inventory. You cannot apply a tenet to an agent you have not found. Agents are created by developers, not procured by IT, so the register is always shorter than reality.
2. Delegated identity. Every agent action carries both the agent and the human it acts for. Delegation, not impersonation. This is the control that makes every later one auditable.
3. Per-call scoping. Short-lived credentials minted per action, never exceeding the invoking user's authority.
4. Action-level enforcement. Policy evaluated on the tool call and its arguments, in the path, before the action lands. Shape-based rather than volume-based.
5. A reconstructable record. Tenet 7 is not optional for agents, because the decision chain is the only way to answer what happened. A record that shows an action without showing the retrieved context that prompted it cannot answer that question.
For a version of this you can hand to an architecture board, our agent governance framework puts the same controls into a document with a control matrix, and the production playbook covers the implementation sequence in more detail. If you want to know where your own estate sits before committing to a program, the agent risk calculator scores exposure from five inputs.
What the standards have not settled
Here is the state of play as of September 2026, and it is stranger than a simple gap.
Every standards body working on agents has independently converged on the same small set of controls: give each agent a cryptographically distinct identity, authenticate agent-to-service calls with mutual TLS, grant the minimum scope required, and keep credentials short-lived. That is zero trust in substance. Not one of them has published it as zero trust.
The zero-trust documents never got an AI update. SP 800-207 has not been revised since August 2020. The AI documents cite zero trust once and move on. In May 2026 CISA published "Careful Adoption of Agentic AI Services" with the Australian Signals Directorate leading and the NSA, NCSC-UK, NCSC-NZ and Canada's Cyber Center co-sealing. It is the only Five Eyes guidance whose entire subject is agentic AI security. Its complete zero-trust content is two cross-references, both in the threat modeling section, telling readers to "harmonize agentic AI controls with existing security frameworks, national standards and allied agreements, such as the National Institute of Standards and Technology (NIST) Zero Trust Architecture standard" and to "map agentic AI controls with existing security frameworks and national standards to ensure alignment with Zero Trust principles and allied agreements."
The substance is in that document. Its identity management section asks you to "construct each agent as a distinct principal, a cryptographically anchored identity with its own unique keys or certificates," to "apply role-based identity management and limit agent permissions to the minimum scope required for approved tasks," and to "authenticate all inter-agent and agent-to-service API calls using mutual transport layer security to ensure non-repudiation." Those are three of the four controls above. They are simply never assembled into a model.
NIST's own agent identity work is younger than most people assume. In February 2026 the NCCoE published a concept paper, "Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization," as an initial public draft with a comment period that closed in April. Eleven pages. It is NIST asking rather than NIST answering, and the questions it asks are the ones your architecture review is already stuck on:
"How do we establish 'least privilege' for an agent, especially when its required actions might not be fully predictable when deployed?"
"What are the mechanisms for an agent to prove its authority to perform a specific action?"
"How might an agent convey the intent of its actions?"
"How do we bind agent identity with human identity to support 'human-in-the-loop' authorizations?"
Now read that third question next to the IETF draft. In February 2026 NIST asks how an agent might convey the intent of its actions. In September 2026 the WIMSE working group answers, in effect, that it will not be solving that, stating that translating an agent's mission into authorization requirements "is out of scope of this specification." Two standards bodies, seven months apart, arrive at the same unsolved problem and both decline to take it.
That is not a criticism of either. It is the most useful fact on this page, because it tells you where the burden actually sits. No standard is going to tell you how to turn "handle this customer's refund" into a permission set in the next twelve months. Until one does, that translation is an engineering decision your team owns, and the safest version of it is a narrow allowlist per task class rather than a broad grant with a promise of good behavior.
Two smaller cautions while you read the field. The most on-point zero-trust-for-agents paper in circulation sits on the Cloud Security Alliance's Lab Space, which CSA describes as independent community projects rather than official publications, so weigh it as community research and not as guidance. And OWASP's non-human identity work and its agentic AI work are separate efforts that do not cross-reference each other, which is worth knowing before you assume a single OWASP position exists.
The principle was never the problem. Zero trust says verify explicitly, grant least privilege, and assume breach, and all three are exactly right for something that acts thousands of times a minute on instructions partly written by strangers. The problem is that the controls underneath were built for someone who types, and the bodies that wrote them have not yet rebuilt them for something that does not. You do not get to wait. For the wider program view, our agentic AI governance guide sets this alongside the rest, and the annotated OWASP agentic list covers the threat side.