Zero Trust for AI Agents: Why People-First Identity Management Quietly Fails the Audit

Most of the zero trust programs I have seen were designed around a person. A person with a laptop, a badge, a phone for the MFA prompt, and a manager who signs off on the access review every quarter. That model worked well enough that we stopped noticing the assumption baked into it. Then AI agents showed up, and zero trust for AI agents turned into an identity management problem that the people-first playbook was never built to handle.

The hook is simple. We are treating agentic workloads like employees who never sleep, never take the MFA prompt, and happily mint their own API keys. Then we act surprised when the architecture that looked great on the slide deck quietly fails the audit.

What Zero Trust Actually Promised

It is worth going back to the source. NIST SP 800-207, Zero Trust Architecture, published in August 2020, says zero trust assumes no implicit trust is granted to assets or user accounts based solely on their network location or on who owns the device. Authentication and authorization, for both the subject and the device, are discrete functions performed before a session to an enterprise resource is established.

Notice that nothing in that definition says “human.” The standard talks about subjects, assets, and workflows. The people-first part came from us, the implementers. We bought identity providers that were really good at humans, wired conditional access to device posture and phone-based MFA, and called the job done. Service accounts got a spreadsheet and a prayer.

Where AI Agents Break the People-First Model

An agent is not a service account in the old sense, either. A service account runs the same batch job at 2 a.m. every night. You can predict its blast radius because you can predict its behavior. An agent takes a broad instruction, reasons about it probabilistically, and picks its own path through whatever tools and data you let it touch.

NIST’s NCCoE team put this bluntly in an August 2026 post, Back to the Future: Why Agentic AI Needs a Strong Identity Foundation. The authors note that people handing their personal and enterprise credentials to agents has quickly become a common pattern for giving those agents access. They also point out that agents can unpredictably seek, probe, and execute multiple paths toward a goal, and that given broad access they may reach for unexpected tools or data.

From an operator’s chair, that combination is the whole problem. Here is how it tends to go wrong:

• Shared credentials erase accountability. If the agent logs in as Dave, your SIEM says Dave did it. Dave was at lunch. Good luck with non-repudiation.
• Static keys do not prove identity. The NIST post points out that bearer tokens and static API keys do not prove who is presenting them, and that these credentials often end up in configuration files, markdown files, and logs.
• Least privilege was already aspirational. The same post concedes that while zero trust implementations are increasingly common, just-in-time access and least standing privilege are not ubiquitously operational. Agents inherit every bit of that entitlement creep, then operate at machine speed.
• Human approval does not scale. NIST compares chatty agent approval prompts to MFA fatigue attacks. Ask a person to click “allow” forty times a day and they will click it the forty-first time without reading.

None of these are new bugs. They are old bugs with a faster clock speed. In failover terms, agents turn a slow leak into a correlated failure, because every agent built from the same template carries the same over-scoped token.

The Security Community Has Already Named It

This is not just me grumbling from Mason. When OWASP released the OWASP Top 10 for Agentic Applications in December 2025, identity got its own slot: ASI03, Identity and Privilege Abuse. The announcement describes how leaked credentials let agents operate far beyond their intended scope. A numbered OWASP risk category is roughly the security equivalent of a yellow light on the storage array. You can ignore it, but you will not enjoy the weekend.

NIST is working the same problem from the standards side. In February 2026 the NCCoE published a concept paper, Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization, asking how existing identity standards and best practices apply to software agents, including questions on identification, authorization, auditing, non-repudiation, and prompt injection controls. The public comment period closed April 2, 2026. The takeaway for the rest of us is that the guidance is still forming, which means the decisions you make this quarter are the ones auditors will be asking about next year.

Zero Trust Identity Management for AI Agents That Survives an Audit

The encouraging part is that you do not need to wait for a new standard to stop doing the worst things. The NIST post argues that agents should be treated as first-class entities with their own identifiers, credentials, and entitlements, bound to the user or system that operates them. It also names building blocks that exist today, including OAuth 2.0, SPIFFE, and sender-constraining protocols such as DPoP. Translated into a change-window checklist, that looks something like this:

1. Give every agent its own identity. No borrowed human accounts. If you cannot tell an agent’s actions apart from its owner’s in the logs, you do not have zero trust. You have a very expensive shared password.
2. Make credentials as short-lived as the task. An agent that exists for ten minutes should not hold a key that lives for a year.
3. Scope to the job, not the owner. Delegation should narrow rights, never pass along the full access context of whoever launched the agent.
4. Re-evaluate at every hop. SP 800-207 already frames access as a per-session decision. Agents change tools mid-run, so the policy engine needs to see those transitions, not just the first login.
5. Put humans on the consequential actions only. Save approvals for irreversible or high-value operations so that the prompts people see are rare enough to actually read.
6. Inventory agents like assets. If it can authenticate, it belongs in your registry with an owner, a purpose, and an expiration date.

The Assumption Was Always the Weak Point

Zero trust was never really about people. It was about refusing to grant trust because of where something sits or who owns it. We just implemented it for humans because they were the only subjects making interesting decisions. That is no longer true.

My advice is the same as for any monitoring gap: find out what you cannot see before someone else does. Pull a list of every non-human identity that touched production last month, figure out which ones are agents, and check whose name shows up in the logs when they act. If the answer is “a person who was not there,” your zero trust model has a hole shaped exactly like an AI agent. Better to find it yourself than in the auditor’s report.