AI agents need their own identity

My days are identity infrastructure. My evenings, lately, are a master’s in AI. They keep colliding on one question: when an agent does something, who did it?

Most organizations answer by accident: the agent runs under a shared service account or a borrowed human token, and the log blames somebody else.

An agent is not a user with a cron job

A service account does one thing, on one system, on a schedule someone wrote down. An agent decides: it picks tools and chains them in orders nobody scripted. The access model built for people, roles reviewed quarterly by a manager, has no purchase here. And machine identities outnumber humans roughly 80 to 1 in a typical enterprise, up from about 50,000 per company in 2021 to about 250,000 in 2025.

So the first requirement is boring: each agent is its own identity, with its own credentials, scopes, and owner. Its own name in the log.

The problem with bearer tokens

A bearer token works for whoever holds the string. Agents log their own HTTP traffic, pass tokens through tool-call chains, cache context into vector stores. One leaky log line hands the string to someone else, and you cannot tell the attacker from the agent.

DPoP (RFC 9449) fixes exactly that failure: the agent signs a proof with a private key on every request, and the token is bound to that key. A token lifted from a log or a trace is inert without the key that never left the agent’s process. In Okta this works on the client-credentials flow that agents live on.

Before DPoP, a token in a log is an incident. After, it’s a string.

One consent, or a hundred?

An assistant that reads your calendar, drafts in your docs tool, and files a ticket needs three apps as you. Per-app OAuth consent, the default every SaaS ships, means long-lived grants scattered across vendors, multiplied by every agent and employee, visible from nowhere.

Cross App Access routes that authority through the identity provider instead: a two-hop exchange in which the IdP issues an assertion scoped to one downstream resource, valid for 300 seconds, and the agent trades it for a narrowly scoped access token. One central consent. One revocation that kills everything the chain would ever mint. Agents need a kill switch more than they need anything else.

Somebody has to own the keys

Somewhere right now, an agent’s key is authenticating faithfully for a person who left months ago; nothing ties the credential to the departure, so no offboarding flow will ever find it. A named owner on record is that tie: departure triggers rotation, not an orphan.

So, who did it? If your logs answer with the agent’s name, backed by a key that never left its process, minted through a chain you can sever in one action, you are ahead of nearly everyone.

This week, in a developer org: create a client-credentials app, require DPoP, script the handshake, then replay the same access token without the proof and watch the 401. Same string, one request works, one fails. That pair of requests is this whole essay, running on your screen.