MCP and the Identity Gap: Impersonation Is Not Delegation

AI agents are forcing software engineers to confront an old identity problem in a new form.

When a person asks an agent to perform an action, there are at least two meaningful identities in the interaction:

1. The human who authorized or initiated the request.
2. The agent that interpreted the request and performed the action.

Those identities may be related, but they are not interchangeable.

Today, much of the authentication infrastructure being used for agentic systems collapses them into one. The agent receives a token representing the user, then calls a downstream service as though it were that user. The result is convenient, familiar, and increasingly difficult to defend.

The industry says the agent is acting on behalf of the user. The authorization system often records only the user as the actor.

Those are not the same thing.

OAuth already has a vocabulary for this

This is not a completely new problem. OAuth 2.0 Token Exchange, defined in RFC 8693, explicitly distinguishes between impersonation and delegation. The RFC describes token exchange mechanisms for both models and provides a way to express delegation semantics in security tokens. The distinction is straightforward.

Impersonation means the acting party becomes indistinguishable from the subject. The downstream system sees the user. The agent disappears.

Delegation means one party acts on behalf of another while remaining a distinct actor. The downstream system should be able to establish both who authorized the action and who actually performed it.

That difference matters because software systems do not merely need to know whether an action was permitted. They need to know who acted, under whose authority, for what purpose, and with what constraints. A user may authorize an agent to answer a question about a particular dataset. That does not mean the agent should inherit every permission the user has. Nor does it mean the agent should be able to perform every action the user could perform manually.

Delegation creates room for those distinctions. Impersonation erases them.

MCP is using delegation language without consistently modeling delegation

MCP’s common authorization flow is user-centric. It allows a client to make requests to an MCP server on behalf of a resource owner, but it does not consistently require the resource server to receive and enforce a distinct identity for the agent performing the action. That is a reasonable starting point for securing an interactive application. It is less satisfying as a complete identity model for autonomous or semi-autonomous agents.

The problem is not that MCP uses OAuth. The problem is that the common authorization pattern does not require the resource server to receive or enforce a distinct identity for the agent that is actually making the request.

In practice, the token often answers one question:
Which user is this request associated with?

It does not necessarily answer the equally important question:
Which agent performed this action?

In deployments where the downstream service receives only the user’s identity, the result is functionally similar to user impersonation, even if the application describes the relationship as delegation. The distinction becomes especially important when an agent is not a passive interface. Agents plan, select tools, construct queries, interpret results, retry failed actions, and sometimes continue operating after the original user interaction has ended.

An agent is not simply a new user interface. It is an actor.

If the architecture treats agents as first-class identities in one part of the control plane, then hides them behind human credentials at the data plane, the system is talking out of both sides of its mouth.

Why impersonation breaks down for agents

1. It creates privilege inflation

A user’s permissions are designed around what that person may do across many contexts. An agent usually needs a much narrower set of permissions for a specific task. If the agent impersonates the user, it inherits the entire permission set. A privileged user produces a privileged agent, even when the task requires only a small subset of that authority. This undermines least privilege. It also makes temporary, purpose-bound access difficult to implement because the agent is carrying the user’s standing permissions into every interaction.

Delegation allows the system to apply additional constraints:

• What the user is allowed to do
• What the agent is allowed to do
• Which resource is being accessed
• What task or purpose is authorized
• How long the authority should remain valid
• Whether the action requires additional approval

The effective authority should be the result of those constraints, not simply a copy of the user’s access.

2. It makes audit trails ambiguous

A log entry that says alice@example.com accessed payroll data is incomplete if an agent performed the query. Did Alice personally run the query? Did she ask an agent to retrieve the information? Which agent acted? Which tool did it invoke? What instructions or policy governed the action? Those questions are not forensic details. They are part of the event itself.

A useful audit record for agentic activity needs to preserve at least two identities:

• The human principal who delegated or initiated the action
• The agent that actually performed it

It may also need the delegation chain, the task context, the scopes granted, the policy decision, and the resulting data access. Without that information, organizations cannot reliably distinguish a user mistake from an agent error, a compromised agent, a malicious tool, or a policy failure. They may know that an action occurred, but not which control should be revoked or which identity should be investigated.

3. It confuses human intent with machine behavior

A human may authorize an agent to “prepare a report.” The agent may decide which systems to query, which filters to apply, and which tools to invoke. The user’s authorization is relevant, but it does not fully describe what happened.

The agent introduced its own behavior into the process. It may have interpreted the request incorrectly, followed an unsafe instruction, selected an overly broad query, or continued operating after the user’s immediate attention moved elsewhere.

That does not make the agent a legal or moral person. It does make the agent a meaningful security actor. Security models should describe the system as it operates, not as we wish it operated.

What a real delegation model should preserve

A proper agent authorization model does not need to replace user consent or eliminate identity providers. It needs to preserve the relationship between the identities involved.

At minimum, a delegated token or request should be able to express:

• The human principal
• The agent actor
• The intended audience or resource
• The permissions and constraints granted
• The purpose or task context, where available
• The delegation lifetime
• The authority to delegate
• The chain of actors, if multiple agents are involved

The resource server should be able to make an authorization decision using both the delegator and the actor. Logging systems should record both. Policy engines should be able to distinguish a human action from an agent action performed under delegated authority.

This does not mean every system needs to implement the same claims or token format. It does mean that the protocol must preserve the semantics instead of discarding them at the boundary. A user-centric token may be enough for simple applications. It is not enough as the default identity model for software that can independently reason, plan, and act.

The uncomfortable design choice

There is a temptation to treat impersonation as a temporary implementation detail. It works with existing permissions, existing APIs, and existing audit systems. It avoids creating new agent identities and new authorization flows.

That convenience is exactly why it is dangerous.

Temporary shortcuts have a way of becoming permanent architecture. Once applications, data platforms, audit systems, and compliance processes are built around the assumption that every action belongs to a human user, introducing agent identity later becomes expensive and disruptive.

The better time to model the agent is before the system depends on pretending it is not there.

MCP and the broader agent ecosystem are already moving toward more explicit delegated authorization. That is progress. But delegated authorization should not stop at the consent screen or token issuance step. The distinction must survive all the way to the resource server, policy decision, and audit record.

Agents should be first-class actors

The central question is not whether an agent is “a user.” It is not. The question is whether the agent is an actor whose behavior affects security, authorization, privacy, and accountability. The answer is clearly yes.

If an agent is an actor, then our protocols should represent it as one.

The human should remain visible as the principal who authorized the work. The agent should remain visible as the actor that performed it. The system should enforce the boundaries between them rather than collapsing both identities into a single credential.

Delegation is not a cosmetic improvement to impersonation. It is a more accurate model of what is actually happening. And when software architecture fails to model what is actually happening, it eventually paints itself into a corner.