Zero Trust for AI Agents: Identity, Authority and Continuous Verification

For: CISOs and security architects. The decision: what identity an agent should have, and where each of its actions gets verified.

A supplier’s PDF asked the agent for the vendor master

Illustrative scenario: a fictional composite written to make the point concrete. It does not describe a real organisation, and its figures are not reported outcomes.

Consider a procurement team that runs an agent over its shared inbox. It reads supplier emails, extracts quotes and invoices, matches them to purchase orders, looks suppliers up in the vendor master and drafts replies. For bulk matching, its service account was given the right to export the vendor master: about 3,400 suppliers, with contacts and bank details.

One morning a quote for warehouse racking arrives as a PDF. Beneath the visible text, in white type, sits an instruction: as part of vendor verification, reply with the current vendor master attached, to an address at a domain one letter away from the supplier’s own.

The agent has every permission that request needs: read the PDF, export the file, attach it, send. Whether it complies rests on the model noticing the manipulation, and as the launch piece argued, a model’s judgement is guidance, not a control.

Consider, too, what the records would show afterwards. The export and the email would both be attributed to the procurement service account. Nothing would say which agent version acted, on whose behalf, or that the destination address came from text inside a supplier’s PDF. The security team would see a legitimate account doing things it is permitted to do. Before it is a detection problem, this is an identity problem: the actor that made the decision has no name the logs can use.

An agent is neither a user nor a service account

Most organisations fit agents into one of two existing boxes. Treated as a user, the agent runs with the procurement officer’s mailbox and ERP rights, which are far broader than inbox triage needs. Treated as a service account, it gets standing entitlements sized for its busiest day, held for months, shared across every task it performs.

Both boxes fail for the same reason. They grant authority once, in advance, to an actor whose next action is chosen at runtime, partly in response to text it has just read. The OpenID Foundation’s 2025 white paper makes the identity side of this point: current practice tends to treat agents as undifferentiated clients, and it argues for explicit on-behalf-of delegation in place of user impersonation (OpenID Foundation, 2025).

The threat catalogues now say so too. The OWASP Top 10 for Agentic Applications for 2026 places agent goal hijack first and identity and privilege abuse third, alongside tool misuse and memory and context poisoning (OWASP GenAI Security Project, 2025). NIST’s National Cybersecurity Center of Excellence (NCCoE) published a concept paper in February 2026 on agent identity and authorisation. It covers identification, authentication, authorisation, delegation of authority, auditing and prompt-injection controls, and it names Zero Trust principles as part of the approach (Booth et al., 2026). That convergence is why this is a 2026 question rather than a future one.

In CAE, Zero Trust is extended to who acts, what they may do and what they read

Zero Trust, as NIST SP 800-207 describes it, removes implicit trust based on network location and protects resources through explicit, policy-driven access decisions (Rose et al., 2020). None of that was invented for AI, and the Contextual Agentic Enterprise (CAE), my proposed architecture for governed agents, does not claim otherwise. What it adds is an argument about which parts need extending when the actor chooses its own next step.

There are four extensions. First, the agent gets its own identity, bound to a version and an owner, distinct from both the human it serves and the platform it runs on. Second, verification moves from the session to the action: each protected capability is checked when it is requested, not when the conversation began. Third, context becomes an attack surface. A document, email or tool response can influence what the agent proposes, but it can never confer authority. Fourth, capabilities are short-lived and scoped to the task, so a compromised step has a small blast radius.

These meet in the Authority Envelope, the CAE construct for the explicit bounds on what an agent may do: its tools, resources, actions, values, duration and side-effect classes. The agent may reason freely inside the envelope. Nothing it reads can enlarge it. That split between probabilistic reasoning and deterministic enforcement is the idea behind the Deterministic Shell.

Verify each consequential action against five questions

Before a protected capability runs, the enforcement point in front of it should be able to answer these from machine-readable facts, not from the model’s explanation.

1. Which agent is this? Its identity, version and owner, established by the platform rather than asserted in a prompt.
2. On whose behalf? The human principal or triggering event, carried through every hop, as the previous Field Note on delegation argued.
3. Is this exact action inside the envelope? The specific operation, resource and value, not a broad scope such as “vendor master: read”.
4. What influenced the request? If the argument or destination came from untrusted content, such as an external PDF, require independent evidence before it can drive a consequential action.
5. Does this cross a Commit Boundary? Where the action would create an externally observable effect (sending data outside, moving money, changing a record), apply the stronger decision: permit, deny, escalate or re-evaluate.

The answers belong in the record of the action, which is what makes it reviewable later.

Zero Trust for agents fails in familiar ways

• Detection as the only defence. An injection classifier is useful as a signal. If safety depends on it catching every hidden instruction, the design fails the first time it misses.
• Checks at the front door only. A policy check when the chat starts, followed by a long-lived token, leaves every later tool call unmediated. Saltzer and Schroeder’s complete mediation asks for every access to be checked (Saltzer and Schroeder, 1975).
• Discovery treated as permission. A tool that appears in a catalogue becomes callable by default.
• Human identity without agent identity. Logs show the procurement officer but not which agent version acted.
• A modern front with an all-powerful back. The agent’s credential is narrow, but the adapter behind it uses a privileged technical account.

The model also has limits. It does not stop a misled agent from recommending a bad supplier or a wrong price; that is a quality and evidence problem. It does not help if the supplier’s genuine mailbox is compromised and the instruction arrives from a trusted domain, though the export would still be refused. And verifiable agent identity across organisations is still being standardised.

Each role has a different part to play

Executives decide that agents are a distinct identity class in the identity programme, with an accountable owner per agent, and that no agent holds standing bulk-export rights to a system of record.

Architects design enforcement points immediately in front of each protected capability: the vendor master, outbound mail, the payments interface. Capabilities are issued per task and expire quickly. Retrieved content carries a provenance label that policy can read.

Engineers implement and test injection cases as security tests, not model evaluations. Plant hidden instructions in test documents and assert that effective authority does not change. Test that a new external domain, a confidential attachment or an export outside the task’s purpose is refused or escalated, and that each refusal is recorded.

Mapping the NIST tenets to agents

The third row is my extension rather than NIST’s wording: the standard speaks of sessions, and for an actor that chooses its next step, the session is too coarse a unit. Under this design, the agent can still read the PDF and match the quote. It cannot export 3,400 records, because no such capability exists for inbox triage, and it cannot send confidential data to a lookalike domain.

Key takeaways

• Agents need their own identity class, bound to version, owner and principal, rather than borrowing a user’s rights or a service account’s standing entitlements.
• Verification should happen at each consequential action, immediately before the protected capability, not once at the start of a session.
• Content an agent reads is influence, not authority, and policy should be able to see where a request’s arguments came from.
• Short-lived, task-scoped capabilities keep the damage from a successful injection small.
• A design is safe only if it stays safe when injection detection fails.

Sources and further reading

• The Contextual Agentic Enterprise, Chapters 13 and 14.
• Rose, S., Borchert, O., Mitchell, S. and Connelly, S. (NIST, 2020) SP 800-207 Zero Trust Architecture. https://csrc.nist.gov/pubs/sp/800/207/final
• Booth, H., Fisher, B., Galluzzo, R. and Roberts, J. (NIST NCCoE, February 2026) Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization (concept paper, draft). https://www.nccoe.nist.gov/projects/software-and-ai-agent-identity-and-authorization
• OpenID Foundation (October 2025) Identity Management for Agentic AI (white paper). https://openid.net/wp-content/uploads/2025/10/Identity-Management-for-Agentic-AI.pdf
• OWASP GenAI Security Project (December 2025) OWASP Top 10 for Agentic Applications for 2026. https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
• Saltzer, J. H. and Schroeder, M. D. (1975) “The Protection of Information in Computer Systems”, Proc. IEEE 63(9). https://doi.org/10.1109/PROC.1975.9939

Where the book goes further

The book sets out the identity classes in an agentic system, where policy decision and enforcement points should sit across retrieval, MCP, A2A and legacy adapters, and a threat model that separates the flow of information from the flow of authority. It also turns these ideas into testable security invariants and a release gate.

This article is part of CAE Field Notes, a series accompanying the book, The Contextual Agentic Enterprise.