AI Agent Identity: Why a Shared API Key Doesn't Scale

An agent reads your calendar, drafts a reply, and books a meeting room, all inside one workflow. When the room-booking API logs that request, what does it actually record? Most setups answer with one flat fact: a service account named agent-bot made the call. Not you, not the teammate who triggered it, just the bot. AI agent identity and delegated authentication is the layer that closes that gap: proving which human an agent is really acting for, not just that some agent called the API.

What does it mean for an AI agent to have an identity?#

An AI agent having an identity means a downstream system can name the specific actor behind a request, separate from whether that actor is allowed to do it. Today most agents skip this entirely: they inherit one static credential, and every call looks identical whether a human approved it or a prompt injection triggered it.

That distinction, identity versus authorization, is not academic. Scoped credentials and sandboxing cap what an agent can reach once it acts. Identity is the layer underneath: which actor is behind this specific call, and on whose authority. A perfectly scoped credential is still anonymous the moment it fires if nothing records who it was scoped to that day. Security teams have started calling this whole category non-human identity, credentials that belong to a workload instead of a person, and agents are the fastest-growing member of that category in 2026.

Every number here is read from the primary source or the original research, not a summary of a summary.

The numbers above are not about this site's own agents. They are published research on the wider MCP and agent ecosystem, and they explain why the identity gap is still the default setup in mid-2026, not a rare misconfiguration.

Why does one shared API key break down once more than one person uses the agent?#

A single API key or service account covering every user means every call is indistinguishable from every other call. You cannot see which person triggered a bad action, cannot revoke one person's access without cutting off everyone sharing the key, and cannot apply a per-user rate limit because the downstream system only ever sees one caller.

This is not hypothetical. A 2025 analysis of over 5,200 public MCP server implementations found 88% require some credential, but 53% rely on long-lived static API keys or personal access tokens, and only 8.5% use OAuth at all. Source That is the shared-secret pattern at scale: most agent tooling today cannot tell one caller from another even if it wanted to.

The same four failure modes show up whether the shared credential is an API key, a bot token, or a client-credentials grant.

Security researchers have a name for the failure mode this invites: a confused deputy, a program holding broad authority that a less-trusted input tricks into misusing it. It is a decades-old access-control concept, not a new one, and an agent holding one static, over-broad credential is a textbook case. Narrowing that credential to a specific, verifiable actor is the difference between a contained mistake and a shared master key walking out the door.

What is the difference between the agent's own identity and a delegated identity?#

Two different patterns both get called agent identity, and mixing them up causes real design mistakes. A workload identity is the agent's own accountable credential, like a named service account. A delegated identity carries a specific human's authority through the agent for one call, then it expires. Most production systems need both, for different calls.

Microsoft Entra Agent ID, generally available since April 2026, is built around the first pattern: every agent gets its own governed identity, with its own sign-in and audit trail, the same way an employee account works. Source That answers "which agent did this," but not "which human asked for it."

RFC 8693's own text draws this line explicitly: impersonation collapses two identities into one, delegation keeps both visible.

RFC 8693, the OAuth 2.0 Token Exchange standard published in 2020, defines the second pattern precisely. It separates impersonation, where the agent becomes indistinguishable from the user, from delegation, where the token's act claim keeps both identities visible: the agent is acting, and the user is who it is acting for. Source

How does OAuth 2.0 Token Exchange (RFC 8693) actually express delegation?#

RFC 8693 lets an agent trade one token for another at an authorization server's token endpoint, and it defines two JSON claims for this exact case. The act claim names who is really acting inside a token issued to someone else. The may_act claim pre-authorizes which actors are allowed to act on a given subject's behalf.

That is a meaningful difference from most access patterns teams already use. A static API key carries no identity beyond itself. An OAuth client-credentials grant proves the agent's own identity but says nothing about a human. Only a delegated token, minted per RFC 8693 or a compatible profile, carries both at once.

Nothing here requires building a token exchange server from scratch. The next section covers a live implementation of this exact pattern shipping in production tools right now.

What does delegated authentication look like in production right now?#

It is running today, not theoretical. An emerging IETF standard called ID-JAG lets an identity provider issue a short-lived token naming the agent, the user, and the exact downstream app it is good for, built directly on RFC 8693 token exchange. As of June 2026, Okta, Claude, and VS Code shipped it as clients.

ID-JAG stands for Identity Assertion JWT Authorization Grant, an OAuth working-group draft from authors at Okta, Ping Identity, and independent contributors. Source It answers a specific gap: your identity provider and a target app both trust the same sign-in system, but have no direct trust relationship with each other.

This is the shipped version of RFC 8693 delegation, not a hypothetical one, live since June 2026.

By June 2026, apps including Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase were named among the first to accept it, alongside Okta as the identity provider and Claude and VS Code as clients requesting it. Source None of this requires a small team to write its own token-exchange server. It requires picking an identity provider and downstream apps that already speak this language, and checking whether yours do yet.

Where do MCP, A2A, and vendor identity platforms fit into this?#

MCP, A2A, and vendor identity platforms solve 3 different pieces of this puzzle, and confusing them wastes setup time. MCP's OAuth layer secures the connection between a client and one MCP server. A2A lets independent agents discover and hand off tasks to each other. Neither one, by itself, proves which human an action was for.

MCP's 2026 spec update covers that transport-level auth mechanics in full: OAuth 2.1, audience-bound tokens, protected resource metadata. It is real progress, but it stops at the MCP server's front door. A2A is a separate concern again, about one agent finding and calling another agent, not about carrying a human's identity through the chain.

If you would rather configure this than build it, Microsoft Entra Agent ID, Okta's Cross App Access, and Auth0's Auth for GenAI all package some version of workload identity plus delegated tokens behind a dashboard. None of them replace the concepts above; they just save a small team from hand-rolling RFC 8693 itself.

Three checks decide it: who the call is for, whether it touches that person's own data, and whether your identity provider can mint a per-user token.

Does this agent need delegated identity, or is a service account enough?#

Not every agent needs full delegation, and building it where a scoped service account would do just adds complexity for no payoff. The honest test is 3 questions: is this call acting for one specific person, does it touch that person's own data or account, and can your identity provider actually mint a per-user token today?

Walk those 3 questions in order, using the flowchart above. An agent running its own scheduled report or syncing its own inbox never needs a delegated identity; a scoped service credential and a sandboxed runtime are the right layer here. An agent that reads or changes a specific person's account, files, or money is a different case, and that is exactly where a shared credential turns into the confused-deputy problem from earlier in this post.

Once delegation is the right call, pair it with a way to see what actually happened. A trace id from agent observability tells you what a run did; the delegated token's subject claim tells you whose authority it did it under. Together they produce the audit trail a shared API key can never generate on its own.

What should you set up this week?#

Pick the one integration in your stack where more than one person's actions currently funnel through a single shared credential. That is this week's task, not a full delegation rollout. Add a per-user log line first, even a manual one, so you can see the gap before you spend a weekend closing it properly.

If you are a solo builder running one agent for yourself, a single scoped credential is still the right answer, and nothing in this post asks you to add delegation you do not need yet. The moment a second person, client, or teammate starts triggering the same agent, that credential stops being a shortcut and starts being a liability with your name on it.

Start with the flowchart above on your riskiest integration, not all of them at once. The standards and the shipped examples in this post exist so a small team configures this instead of inventing it from scratch.