Why multi-agent systems need verifiable delegation, not just valid tokens
A human prompts an agent. That agent delegates to another agent. A sub-agent calls a tool, which calls an API, which touches real data and real systems.
Now the key question:
Who is acting at each step, and on whose authority?
Most teams answer this with one of two lines:
- “We use OAuth through MCP.”
- “Our platform handles access controls.”
Both can be true. Neither is enough for multi-step agent workflows.
OAuth can show that a client is authorized. It does not automatically show:
- which agent instance is acting now,
- how authority was delegated,
- whether permissions were reduced at each handoff,
- or whether one compromised sub-agent can be revoked without breaking everything.
That is the identity problem.
The Multi-Step Gap
MCP auth improvements matter. Better OAuth alignment, stronger defaults, and less token pass-through are real progress.
But in many production chains, the pattern still looks like this:
- an orchestrator gets broad user-approved access,
- delegates to a specialist,
- specialist actions still appear as “valid token + generic client context” to downstream tools.
So ask:
- Does the specialist only have the scope it needs?
- Can downstream services verify the full delegation chain?
- Can you revoke one bad sub-agent delegation without taking down the whole workflow?
- If legal or audit asks tomorrow, can you prove who delegated what at each step?
For many teams, the answer is still “it depends.”
Authorization vs Identity
Authorization asks: can this client access this resource?
Identity asks: who is acting, how did they get authority, and what is the verifiable chain back to the initiating user?
OAuth and OIDC can carry richer delegation context in theory. The gap is practical interoperability across frameworks, vendors, and tools.
Single-agent systems can sometimes tolerate this ambiguity. Long-running multi-agent workflows usually cannot.
What Is Improving
There is real momentum:
- MCP auth work is improving baseline hygiene.
- Identity providers and cloud platforms are shipping agent-focused patterns.
- OpenID AIIM work outlines major design gaps.
- Authenticated Delegation research proposes concrete chain-based models.
This is good progress. But we still lack a widely interoperable trust layer for agent delegation across boundaries.
What a Real Agent Identity Layer Needs
At minimum:
Verifiable agent identity
Not just app identity. The acting agent context must be attestable.Delegation-chain tokens with scope attenuation
Authority should only narrow at each step, never expand.Runtime attestation for high-trust paths
For regulated and cross-org actions, verify runtime integrity before sensitive operations.Signed action receipts
Tamper-evident records of initiator, delegates, scopes, action, and time.Granular revocation
Revoke a compromised sub-agent without tearing down upstream access.
What Teams Can Do Now
Even before standards converge:
- Minimize scope per agent and task.
- Keep human checkpoints for high-impact actions.
- Log delegation events with scope and timestamps.
- Prefer short-lived credentials over broad long-lived bearer tokens.
- Run incident drills for sub-agent compromise and partial revocation.
Quick self-test:
- Can you prove the full human-to-agent delegation chain for one specific action?
- Can you revoke one sub-agent cleanly?
- Do tools verify chain context, or only broad credentials?
- Do you have evidence strong enough for audit and legal review?
The Pre-Breach Window
This moment resembles early payment infrastructure:
- speed-first patterns win early,
- then incidents and regulation force architectural change.
We are still in the pre-breach window.
The choice is straightforward:
build strong delegation controls now, or retrofit under pressure later.
If you are building multi-agent systems and working through delegation identity, I would love to compare notes.
Views are my own.