Identity in Agentic Systems: The Hardest Unsolved Problem

Identity is the problem the agentic field has talked about least and the one that will, in retrospect, have determined how widely the technology gets deployed. Most current agentic systems do not have a serious answer to the question “on whose behalf is this agent acting, with what authority, against what budget.” Most current marketing implies the question is solved. The gap between those two facts is the gap between the agentic systems shipping today and the agentic systems regulators will eventually require.

This piece is an attempt to write down what identity has to do in the agentic context, why the field has not solved it, and what a working solution would look like.

What identity has to do

A working identity model for agents has to answer five questions for any action the system takes.

Who is the agent acting for? Every action carries an identity — a user, a service, a tenant. The identity is not optional. It is the foundation of every other answer.

With what scopes? The acting identity has a set of permissions that may be narrower than the underlying user has. An agent acting on behalf of a user should not, by default, have all of the user’s powers. The scope of delegation is part of the identity context.

With what budget? The acting identity carries a spending limit — in tokens, in tool calls, in dollars. The budget is enforced by the platform, not by the agent’s good behavior.

With what oversight? Some actions are auto-approved. Some require human confirmation. Some are entirely forbidden. The oversight model is part of the identity context.

With what audit lineage? Every action’s identity context is captured in the log. The log is queryable by the user, by the operator, by an auditor, and (where relevant) by a regulator.

A system that does not answer all five of these is not identity-aware. It is identity-implicit, which is to say that the platform is making decisions about identity in code, without exposing them, and you are trusting the platform’s defaults.

Why the field has not solved it

There are three structural reasons identity has lagged the rest of the agentic stack.

The first is that the original LLM API model did not have an identity layer. A model call was a stateless function call against an API key. The API key was the model provider’s customer; everything below that was the customer’s problem. This created the impression that identity was a downstream concern, to be solved at the application layer. The application layer never solved it because the application layer thought the model layer would.

The second is that agentic frameworks were initially built by ML engineers, not distributed-systems engineers. The ML engineering culture has not, historically, had identity at the center of its mental model. The distributed-systems culture would have made identity a first-class primitive from day one. The field is still importing the discipline.

The third is that identity in agentic systems is structurally harder than identity in traditional applications. A traditional application has a clear principal — the user who logged in. An agentic system has multiple principals at once: the human user, the agent that the user authorized, the sub-agents that agent spawned, the tools those sub-agents called. Each layer has its own identity context, and the contexts have to compose into a coherent audit lineage. This is not a problem that you can solve with a session cookie.

What a working identity model looks like

A working identity model in an agentic system has, in our reading, the following properties.

Per-user OAuth at the platform boundary. The platform does not store the user’s credentials. The user grants scoped OAuth access to the integrations the platform needs. The platform acts against those tokens, not against a shared key. This is the substrate. Without it, every later identity decision is built on sand.

Delegated identities for agents. When an agent is spawned to do work, it gets an identity. The identity is derived from the user’s but is narrower. It includes a subset of the user’s scopes, a subset of the user’s tools, and a spending cap. The identity is the agent’s, not the user’s, even though it derives from the user’s.

Inter-agent permissions. When one agent calls another, the call carries the calling agent’s identity. The callee can decide whether to act on the call based on the caller’s identity, scopes, and budget. Inter-agent permissions are not just message passing; they are authorization decisions.

A typed audit log. Every action carries the identity context that produced it. The log is structured. It is queryable. It is exportable. Reconstruction of “who did what, with what authority” is a database query, not a forensic exercise.

A revocation path. Identities can be revoked. Tokens can be invalidated. Agents can be killed. The revocation propagates: revoking an agent’s identity revokes the identities of any sub-agents it spawned.

A system with these five properties is identity-aware in the operational sense. A system with three or four is partially identity-aware. A system with one or two — most current products — is identity-implicit and should not be deployed in any context where identity matters.

What the protocols do and do not handle

MCP, the most mature protocol in the agentic stack, has begun to draw the right outline but does not yet enforce it. The current spec treats identity as the host’s responsibility. The host is the application talking to the MCP server. The host is expected to know who the user is. The MCP server is expected to trust the host. This is fine for the local-tool case (a server running on the user’s machine, called by a host the user controls). It is not fine for the remote-tool case (a server hosted by a third party, called by an agent acting on behalf of a user with scoped delegation).

The MCP working group is aware of this and is, as best we can read the public materials, treating it as a near-term priority. The shape of the eventual solution will likely involve a token format that carries identity context, scope claims, and possibly spending information; a standard way for servers to verify the token; and a standard way for the host to mint tokens on behalf of users. None of this is shipped. All of it is in flight.

The A2A protocol conversations have not yet, to our knowledge, converged on an identity model. They likely will, and the model will likely be a layer on top of the MCP-derived identity work. The architectural shape suggests that identity will be the connective tissue between the tool-call layer (MCP) and the agent-call layer (A2A) — a single token format used by both, scoped differently by each.

Where the bundled platforms are

The bundled-platform layer has more freedom to ship identity than the protocol layer, because it controls both the host and the agents. Several platforms have begun to do real identity work, partly because their enterprise customers have asked and partly because the architectural payoff is large.

A pattern we are seeing across the more serious bundled products is the move from per-user OAuth at the platform boundary to per-agent delegated identities one layer down. The first move — per-user OAuth — gives the platform a real principal to act for. The second move — per-agent delegation — gives the platform a real principal to log against. Both are necessary. Neither is widespread.

The hyperscaler-internal platforms have, in our on-background conversations, mostly shipped real per-agent identity already, because the internal compliance regimes have required it. The commercial market is catching up.

What is at stake

The honest stake is regulatory. Identity in agentic systems is the property regulators will eventually require, and the field has not yet shipped it broadly. There are three scenarios.

In the first, the bundled platforms ship real identity ahead of regulatory pressure. The frameworks follow. The protocols catch up. By the time regulators ask, the answer is in production. This is the best outcome and it is, in our reading, plausible but not certain.

In the second, regulators ask before the field is ready. The platforms ship rushed identity layers under deadline pressure. The protocols consolidate around whatever the largest vendor shipped first, which is unlikely to be the architecturally best choice. The category ends up with a bad identity story that is hard to replace because everything is built on it. This is the outcome we should be most concerned about.

In the third, the agentic systems get deployed in domains where identity does not matter — internal tools, hobby projects, low-stakes content work — and the enterprise market simply does not adopt the technology until the identity problem is solved. This is the slow-rollout outcome. It is the most likely if neither of the first two happens cleanly.

The work to ensure the first scenario is the work the field should be doing now. Per-user OAuth at the platform boundary. Delegated identities for agents. Inter-agent permissions. Typed audit logs. Revocation paths. None of this is mysterious. All of it is unglamorous, expensive, and the prerequisite for the deployment scale the marketing has been promising.

Practical advice for builders

If you are building an agentic system today and you want it to be identity-aware:

• Do not use shared keys. Every integration should be per-user OAuth or per-tenant credentials. Shared keys are a permanent debt.

• Capture the identity context at every layer. The user, the agent, the scopes, the budget, the oversight rules. Log all of it. Make the logging non-optional.

• Design for delegation now, even if you only have one layer today. When you ship multi-agent, the identity model has to compose. Retrofitting delegation onto a system that did not anticipate it is more expensive than building delegation in.

• Build a revocation path. The day a user wants to revoke an agent’s access — because the agent misbehaved, because the user’s role changed, because the agent’s spending got out of hand — your system should handle the revocation cleanly. If your platform cannot do this, you are not identity-aware.

• Pick platforms that have made this a priority. When evaluating an agentic platform, ask the identity question. If the answer is vague, walk away. The platforms that have made identity a first-class concern will be visible from the architecture.

The identity problem is not the field’s most visible problem. It will be the field’s most consequential. The work is happening, slowly, in the platforms and the working groups. It is not happening in the press cycle. The publications that cover it — the Review tries to be one — will be the ones that helped the category cross the threshold from interesting demo to deployable infrastructure. The work is unglamorous. It is also exactly the work that has to be done.