Who’s behind the agent? Identity security for AI agents

For years, enterprise security has relied on a fundamental assumption: when someone takes an action, the system knows who they are. AI agents complicate that assumption because they can act on a person’s behalf while sitting between that person and enterprise systems.

Working in the identity security space, I wanted to understand what that shift means in practice. So I did what has always taught me best: I stopped just reading about it and built with it. I spent a couple of evenings working through Okta’s Auth0 agentic AI lab, wiring up a real agent to real identity controls. What clicked for me was that securing agents doesn’t require abandoning the identity principles we already trust. It requires applying them to a new kind of actor.

The premise of the lab was simple: an AI assistant called Nexus that could search documents, log activity to a CRM, and share files. Realistic, ordinary, enterprise stuff. But the moment an agent can do those things, a familiar question resurfaces: Who, exactly, is doing them?

Service accounts already challenged the connection between a human identity and the actions performed in enterprise systems. AI agents raise the stakes. They introduce a new actor between the employee and critical enterprise systems that, without the right identity controls, can become an anonymous middleman with shared credentials and standing access to almost everything.

And this isn’t a someday problem. Gartner projects that by 2028, at least 15% of day-to-day work decisions will be made autonomously by AI agents, up from essentially none in 2024. Meanwhile, the identity surface is exploding: Palo Alto Networks’ 2026 Identity Security Landscape found that machine identities outnumber human identities 109 to 1. Many organizations still can’t define what their agents can access or when that access is revoked. As agents become more common in enterprise environments, the identity controls governing them become increasingly consequential.

We’ve seen where that road ends: the shared service account, reborn. One credential, a blast radius with no edges, and no attribution. To make it worse, there is an audit trail that offers a single, useless line: “the bot did it.”

An agent shouldn’t be a shared bot with the keys to the kingdom. It should act within the identity and authority of the person it represents.

The question the lab kept forcing me to confront was: How do we let an agent act without letting it become an identity of convenience?

Our view is that every production AI agent should meet four identity requirements:

1. Identifiable: The organization can identify the agent taking the action.
2. Attributable: The action remains traceable to the human the agent is acting for.
3. Policy-governed and least-privileged: The agent receives only the authority permitted by policy for the specific user, resource, and action.
4. Auditable: The organization can reconstruct what the agent did, on whose behalf, with what authority, and what was approved.

The first thing that got me curious was that the lab didn’t start with the user. It started with the agent itself. Before the agent could do anything, I gave its OAuth client a stable, URL-based identifier using a Client ID Metadata Document (CIMD). The document published the client’s metadata, including its name, grant types, redirect URIs, and authentication method. At the same time, Auth0 policies and client grants separately controlled which APIs and scopes it could receive. Instead of an opaque client ID, the agent’s OAuth client now had a stable, human-readable identifier.

CIMD is still an emerging OAuth specification, an IETF Internet-Draft as of August 2026, rather than a finalized RFC, so it may be new to some. But the idea is refreshingly simple: the document identifies and describes an OAuth client; it is not itself an authorization grant. Auth0 configures client grants and API-access policies separately.

It’s a small idea with outsized consequences. If you’ve ever tried to reconstruct who did what from logs full of meaningless GUIDs that change on every deploy, you understand why a stable, human-readable agent identity matters. CIMD is, in effect, a digital business card for software that is discoverable, auditable, and durable across redeployments. When you start imagining not one agent but an army of them, that stability stops being a nicety and becomes an important part of maintaining an environment you can secure.

The next thing the lab made clear was that the agent still needed one well-governed doorway into enterprise tools. That doorway was the Model Context Protocol (MCP) server. MCP isn’t inherently a security boundary, but in this lab, the MCP server was implemented as a policy-enforcement point and a controlled gateway to downstream tools. Instead of the agent accessing each system independently, every tool call passed through MCP, where identity, scopes, and authorization decisions could be applied consistently. Implemented this way, MCP became less of a connector and more of a security checkpoint for the agentic workflow.

The concept that stuck with me the most was On-Behalf-Of (OBO) token exchange. Once my test user logged in, the agent didn’t suddenly become that user, and it didn’t fall back to a service account either. It exchanged the user’s token for a tool-scoped token that preserved the user’s identity all the way to the system of record, a mock CRM in this case. The system on the other end still saw the user, not “Nexus” and to my relief, not “id: the-bot-!@#@.”

That single design choice holds the whole architecture together. Now the employee’s identity survives the trip through the agent, and everything downstream finally has something meaningful to reason with. Credentials can be scoped to the user, and access can be determined based on what that person is actually entitled to do. Identity becomes the control plane, even when AI is carrying the request.

One caveat worth being precise about: OBO preserved the delegation chain and produced an audience-specific downstream token, but it did not, by itself, prove that the user reviewed or approved each individual action. For sensitive or irreversible operations, Client-Initiated Backchannel Authentication (CIBA) and Rich Authorization Requests could separately provide transaction-specific approval and, where appropriate, step-up authentication on the user’s device. I also integrated multifactor authentication (MFA) through my mobile device.

The final piece in this architecture addressed a gap that role-based access control (RBAC) doesn’t always close: roles alone may not capture the relationships that should determine access to a specific resource. In the lab, authorization was handled by Autho0 Fine-Grained Authorization (FGA) relationships rather than roles. Concretely, an agent acting for an identity that owned a resource could read and share it. An identity with no relationship to that resource was cleanly denied access.

What I appreciated was where the authorization decision happened; right at the data boundary, keyed on the human’s identity, before any resource was accessed. A static role doesn’t always capture the context that relationships can. And when an agent is the one asking, that precision helps answer a question every security team eventually asks: How do you stop data from leaking across departments? The point is, we’ve got to answer it before it’s asked.

Spinning down the codespace after the last module, I realized none of this required inventing a new security paradigm. It required applying the principles we already believe in—identity-first, least privilege, verify then trust, only this time to a new kind of actor: an agent. The agent didn’t need to be trusted. It needed to carry a verified identity, request only what it needed, prove approval for irreversible actions, and be told “no” at the data boundary when the relationship wasn’t there.

To be clear, a verified identity answers who is acting and with what authority. Identity controls do not replace broader agent security controls[TM17] such as runtime isolation, tool and input validation, transaction limits, and monitoring.

As organizations rush to put agents into production, the temptation will be to tightly couple them with a shared account and sort out the governance later. I’d gently push back on that. Trust in the agentic era will depend on making every action an agent takes identity-bound, least-privileged, policy-governed, and auditable by default.

Putting an AI agent into production is fundamentally a question of trust. Before that moment, an enterprise should be able to answer four questions with confidence:

1. Identity - Can we reliably identify the agent taking the action
2. Delegation - Can we identify the human it is acting for, and preserve that delegation downstream?
3. Authorization - Can we prove the agent has only the authority permitted for this user, resource, and action?
4. Auditability - Can we reconstruct what the agent did, on whose behalf, why it was allowed, and when explicit approval was required?

The good news, and the reason I walked away optimistic, is that the building blocks already exist. CIMD, MCP, MFA, OBO, and FGA aren’t exotic ideas; they apply identity principles we’ve championed for years to a new kind of workflow. We now must choose to use them before the agents show up, not after.

The gap between how fast agents is arriving and how ready our identity controls are is precisely where I spend my time. At Slalom, we’re helping organizations think through these identity decisions as they move agents into production. The goal isn’t to slow agentic AI adoption, but to make sure the identity controls arrive with it.