On Whose Behalf? The Identity Question Agentic AI's Login Handshake Skips

Ask an identity provider “who is calling?” and it answers instantly for a human user or a service account. Ask the same question of an AI agent three hops into a delegation chain — Agent A asked Agent B to ask Agent C to update a record — and most stacks can only answer the first half. They can name the agent making the call. They usually can’t name whose authority it’s supposedly using to make it, once that authority has passed through more than one hand.

That gap has a name in classic identity engineering — “on-behalf-of” delegation — and it’s been solved before, for humans delegating to services. Agentic AI reopens the problem, at a scale and speed nothing before it produced, because agents now delegate to other agents routinely, and each handoff is a chance for the original “on whose behalf” to get quietly dropped.

Two different questions, one handshake usually answers only one

Every login handshake an agent goes through — an MCP OAuth grant, an A2A client-credentials exchange — is built to answer:

“Is this caller who it claims to be?”

That’s authentication, and modern agent protocols do it well. What the same handshake usually leaves silent is a second, separate question:

“On whose authority, and for whose benefit, is this specific call being made?”

For a single agent calling a single tool once, the two questions collapse into the same answer — the agent is acting for the user who invoked it, full stop. The moment a chain forms, they split apart. Agent A is authenticated as Agent A. When A asks B to act, B’s handshake with A proves B is talking to A — it says nothing about whether the human or workspace A claims to represent is real, still authorized, or even the same principal three calls later.

Where delegated identity gets lost

This isn’t a hypothetical protocol gap. It’s the default outcome of wiring agents together without deciding, at every hop, how “acting on behalf of” is supposed to travel:

• The flattened service identity. An agent authenticates to a downstream API using its own client credential, not a token that carries the original user’s identity forward. The API sees “the automation platform” made the call — it never sees which of the platform’s thousands of users the call was actually for. This is the same tenant-crossing pattern we’ve written about for data ownership, but the root cause here is specifically identity: the credential authenticates the agent, not the delegation.
• The A2A relay that doesn’t relay identity. Under Agent2Agent, Agent B’s handshake with Agent C proves B is B. If B’s own task was itself done on behalf of a specific customer, and nothing in the message/send payload or token carries that fact forward, Agent C — and every log it produces — has no way to answer “which customer was this for” without walking back up a chain that may not be reconstructable at all.
• The stale delegation. A human grants an agent authority to act for them — approve invoices, answer tickets, book meetings — for the duration of a task or a session. The agent keeps calling with that authority long after the human’s own session ended, their role changed, or they left the company, because nothing tied the delegation’s validity to a fact that gets checked on every call. It’s the same expiry problem behind agent offboarding, applied one layer earlier — before revocation is even the issue, it’s whether the delegation was still live in the first place.
• The borrowed-authority escalation. An agent with a narrow task-scoped credential calls a second agent that happens to hold broader standing access, and the request looks, from the second agent’s side, like any other authenticated call. Nothing distinguishes “acting on behalf of a specific, narrowly-scoped request” from “acting with my own full authority” — which is the confused deputy problem restated at the identity layer instead of the tool-call layer.

None of these require a broken handshake or a stolen token. They’re what happens when every hop authenticates correctly and nobody designed for delegated identity to survive the hop.

Why this is a governance and data-ownership problem, not just plumbing

The practical cost shows up exactly where audit and traceability matter most: an incident review, a customer dispute, a regulator’s question. “Which agent made this call” is a much weaker answer than “which agent made this call, on whose authority, for whose benefit” — and the difference is the whole answer to whether an action was within scope. A credential that authenticates perfectly and a delegation that’s actually still valid are two different facts, and most agent stacks today only check the first one.

This also compounds with A2A’s administrative reach: an agent that can configure another agent’s collections or policies, acting on a delegation that quietly expired three steps up the chain, isn’t just making a wrong tool call — it’s making administrative changes under an authority nobody can verify was ever real at the point it was used.

The business case: identity that survives the hop

Fullmakt sits as a broker between every agent and every credentialed call, which is exactly the position needed to carry delegated identity through a chain instead of losing it at the first hop:

• Delegation-bound credentials, not just agent-bound ones. A scoped credential Fullmakt resolves can carry the “acting on behalf of” fact as part of what’s issued — the workspace, the requesting user, the task — not just which agent is asking. A call authenticates as both “this agent” and “this delegation,” and a downstream system can tell the two apart.
• Policy that checks the delegation, not just the caller. The same policy engine that gates a tool call can require that the underlying delegation is still live — the human session hasn’t ended, the role hasn’t changed, the grant hasn’t expired — before issuing the credential for that call, closing the stale-delegation gap at the point of issuance rather than hoping it gets caught downstream.
• A traceable chain of custody across every hop. Because Fullmakt brokers the credential at each step of an A2A delegation chain, the record isn’t “Agent C made a call” — it’s “Agent C made this call, under a credential Fullmakt issued for Agent B’s request, issued in turn for this original user’s delegation,” reconstructable from broker-side metadata instead of from logs scattered across three separately-operated agents.
• One place identity and authorization both run through. Because issuance and audit sit at the same chokepoint, “who is this agent” and “on whose authority is it acting right now” are answered by the same system, instead of authentication living in one stack and delegation living nowhere.
• Instant cut-off of a delegation, not just a credential. If a delegation turns out to be stale or the human who granted it is gone, Fullmakt can invalidate everything issued under it — including sub-agent calls further down an A2A chain — without hunting down every credential that delegation ever produced.

The commercial argument is the same chokepoint logic that runs through every governance gap agentic AI opens up: if every call already passes through a broker to get a credential, that’s the right place to make “who is this for” travel with the call, instead of a fact that gets checked once at the top of a chain and trusted forever after.

FAQ

What does “on whose behalf” mean for an AI agent? It’s the question of who or what authorized a specific agentic action and who it’s meant to benefit — distinct from “which agent made the API call.” A login handshake typically proves the second thing and stays silent on the first, especially once one agent delegates to another.

Isn’t this the same as scoping a credential narrowly? Related but not identical. Scoping limits what a credential can reach. Delegated identity is about whether the authority behind the call is still valid and traceable to its origin — a narrowly scoped credential can still be used long after the delegation that justified it should have expired.

Does OAuth already solve this with token exchange? OAuth’s on-behalf-of and token-exchange patterns provide the building blocks, but they have to actually be used at every hop of an agent chain, and most MCP and A2A integrations today authenticate the agent without propagating the underlying delegation. The protocol support existing isn’t the same as it being applied consistently.

Why does this get worse with A2A specifically? Because A2A lets one agent’s authority get exercised through another agent’s call, sometimes several layers deep, and each hop is a place the “on whose behalf” fact can be dropped unless something deliberately carries it forward.

How would an audit trail catch a stale delegation? Only if the trail records the delegation itself, not just the credential used — which requires checking the delegation’s validity at issuance time, on every call, rather than assuming that because a credential authenticates successfully, the authority behind it is still current.

A login handshake that proves an agent’s identity is necessary and not enough. The question that actually determines whether an action was in scope — on whose behalf, under what still-valid authority — has to be answered at the same chokepoint where the credential is issued, on every call, or it quietly stops being answered at all.