First-Class or Ephemeral Is the Wrong Fight

AI agents don’t fit the human identity model or the machine one. They need a governed identity and a disposable, scoped credential — and your auditor is what settles the definition.

From the CIdO — by Nicholas Hunt, Chief Identity Officer, HATSec; Co-founder & CEO, StackBob; IANS Research faculty for IAM

There is a fight underway over what an AI agent is, and most identity teams have been told to pick a side. In one camp, an agent is a first-class identity — a governed object in your directory, with an owner, a lifecycle, and access reviews, managed the way you manage a person. In the other, an agent is ephemeral — an OAuth client that registers, authenticates, does one job with a scoped token, and disappears. Pick the first and you inherit two decades of human governance machinery. Pick the second and you re-architect around dynamic authorization.

Here is the uncomfortable part: the choice is a trap. The vendors telling you to pick have already stopped picking. Microsoft’s Entra Agent ID puts agents in the directory as governed identities — and also issues them “autonomous, on-behalf-of, and user OAuth flows.” Okta, whose Cross App Access is “an extension of OAuth,” now registers those same agents as “a first-class identity layer.” The camps are converging because the premise is wrong. An agent is not a new kind of user to be filed under governance or a new kind of machine to be handed a token. It is a new kind of access — and it needs both answers at once.

Two layers, not two teams

Name the frame and the confusion dissolves: agent identity is two layers of one architecture, not two rival philosophies.

The first layer governs the agent: who owns it, why it exists, whether it’s still needed, when it’s revoked. That is classic identity governance, and the first-class camp is right that agents need it — SailPoint’s guidance is to “treat agent identities like human identities, following joiner-mover-leaver principles with regular certification.” The second layer authorizes the action: what this agent may do right now, in this context, with a short-lived, tightly scoped credential — which is exactly what the ephemeral camp gets right, and what Ping builds with its “Secretless Agentic Identity” issuing dynamic tokens per task.

You need both because either alone fails. A governed identity with a standing, broadly-scoped credential is a breach waiting to happen; a disposable token with no accountable owner is an action no one can answer for. As one practitioner put it plainly, existing infrastructure “forces a binary choice between human and service account, but agents represent something genuinely new.”

CIdO diagram titled 'The two layers of agent identity.' Two side-by-side panels — 'Govern the Agent' (accountable owner, lifecycle, certification) and 'Authorize the Action' (scoped, short-lived, logged credential) — joined by an oxblood 'AND.' Below, an italic pull-quote: 'Two layers of one architecture — not two teams.'

Why you can’t just reuse RBAC

The instinct is to reach for what worked: roles and entitlements. It won’t hold. A role is static and coarse; an agent is dynamic and goal-seeking. The authorization vendor Oso says it directly — “the permissions an agent needs for one narrow task might be dangerously excessive for the next…” An agent that borrows a human’s standing entitlements to get its job done is the oldest failure in security wearing a new coat: the confused deputy, now operating at machine speed. Human RBAC can stay exactly where it is — for humans. The moment an agent acts on behalf of a person, the access has to be scoped down to the task, not inherited wholesale.

That runtime scoping is new infrastructure, and it is arriving fast. The Model Context Protocol now defines an agent’s tool server as “an OAuth 2.1 resource server” with mandatory audience-bound tokens; MCP and AI gateways sit in front of those tools to enforce per-action policy; and the OpenID Foundation ratified AuthZEN 1.0 — a standard for asking one authority, in real time, “is this action allowed?” This is the plumbing agents run on, and it is not the plumbing your SSO was built for.

The auditor settles the argument

Here is where the definition actually gets sharpened — and it isn’t a standards body or a vendor roadmap. It’s your audit.

Every controlled environment you operate rests on one assumption: a privileged action can be traced to an accountable human. SOC 2, as one compliance analysis notes, “expects privileged actions to be attributable to an accountable individual, not to an autonomous agent or generic system account.” Hand your agent a shared service account and you break that on day one — OWASP’s own guidance warns that actions “logged under the service account” obscure who did what. One compliance-vendor analysis found that of eight agent-identity risk categories, “five have zero coverage in either SOC 2 or ISO 27001.”

So the compliance requirement — name the accountable human, prove the action was allowed, keep the evidence — is what forces the architecture into focus. It is why Microsoft makes a business sponsor mandatory: “at least one sponsor is required for each agent identity … ensuring every agent has a designated business owner.” It is why Google Cloud logs agent actions so that “logs show both the agent’s and user’s identities.” The audit doesn’t slow agent adoption down. The audit is the thing telling you what an agent identity has to be: a governed owner plus a scoped, logged action. Be honest about the immature edge, too — the evidence layer is still catching up, and even a vendor’s “compliance” logging may not yet capture the agent’s actual tool calls. Design for that gap now rather than wait.

Off-white CIdO stat card. Eyebrow 'The Compliance Gap' above a large oxblood '5 of 8,' with the line 'agent-identity risk categories have zero coverage in SOC 2 or ISO 27001.' Source tag: DSALTA, 2026. fromthecido.com in the footer.

What to do before you buy anything

You don’t need to rip out human IAM. You need to inventory it against one question your auditor will eventually ask: prove what our agent did last Tuesday — and that it was allowed. Walk the stack. Can your access layer issue and scope short-lived, on-behalf-of tokens? Does your gateway tier speak the agent protocols and enforce per-tool policy? Do you have a single place to decide “is this allowed,” or is that logic scattered across every app? Can you tie every agent action to an accountable human and retain the log? Where the answer is no, you’ve found your evaluation — new agent infrastructure, integrated underneath the human infrastructure that still owns it.

The industry will spend the next year arguing first-class versus ephemeral. Skip the argument. Govern the agent, authorize the action, and build so you can prove both. The teams that win 2026 won’t be the ones who picked the right camp. They’ll be the ones who could answer the auditor.