Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)

The MCP spec has a clean Auth story, but only for one edge of the system: client-to-server. Server discovery, dynamic client registration, PKCE-backed auth codes, scoped tokens. Genuinely solved, no asterisks needed.

A talk at MCP Dev Summit Mumbai 2026 by Ayesha Dissanayaka, Associate Director and Lead Architect for Agent Identity at WSO2, pointed at the part that picture leaves out entirely: the MCP host.

What's Actually Solved

In MCP's architecture, one host can run multiple clients, each with its own dedicated connection to a server. For that specific client-server edge, the MCP specification's authorization section covers discovery, registration, validation, and scoped tokens. Real progress, not in dispute.

But the host sits above all of it, managing every client and every credential, and the spec's OAuth diagram doesn't actually draw the host as something with an identity of its own. It's implicit. The container the clients live inside, not an actor that has to authenticate itself.

Ayesha's framing was blunt: that's exactly where enterprise deployments quietly break.

The Default Today: Long-Lived API Keys

Most teams handle this gap the same way. Generate a personal access token, grant the broadest scopes "to be safe," set expiry to a year or never, paste it into an environment variable.

Works fine in a demo.

In production, it's over-privileged, a standing liability for however long it's valid, untraceable to any specific action, and a textbook violation of least privilege.

This matters more now because of what's actually getting built. Enterprise agents split into two access patterns that look identical at the plumbing level but behave nothing alike in practice.

Delegated copilots and async assistants act on a user's behalf, with a human somewhere in the loop.

Shared service agents and autonomous workloads, SRE remediation, security response, ETL pipelines, run on their own permissions with no human anywhere nearby.

A single long-lived key can't tell these apart. It was never designed to.

The Four A's

Ayesha's framework splits the identity problem into four pillars, each answering one plain question about the agent.

Administer asks about the existence of you. Lifecycle mechanics: registration, ownership, suspension, deprovisioning, and whether anyone can even see what agents exist in the first place.

Authenticate asks how we know it's you. Attestation, zero-trust verification, short-lived tokens instead of standing keys, credential rotation, workload identity integration.

Authorize asks what you're allowed to do. Least privilege, just-in-time grants instead of standing access, tool-level scoping instead of blanket permissions, and a clear line between autonomous action and action that needs a human to sign off.

Audit asks whether you can prove what you did. Audit trails, compliance evidence, decision provenance, anomaly detection, the ability to replay what happened after the fact.

Every edge in the system, invoking party to host, host to LLM provider, host to sub-agent, host to internal or external tool, is a place where all four questions need an answer.

Right now, in most deployments, none of them do.

Delegation: Who's Actually Acting

The most concrete mechanism in the talk is the On-Behalf-Of (OBO) information carried in an access token.

One way to achieve this is a user/subject token combined with an agent/actor token, exchanged into one access token carrying both identities.

The resulting JWT has a sub claim for the user, a client_id claim indicating the client, and a nested act claim for the agent acting on their behalf.

Anyone inspecting that token downstream can tell "the user did this" apart from "the agent did this for the user," something a flat API key, or a standard JWT token simply cannot express.

This isn't Ayesha's citing someone else's proposal from the audience. She's a co-author, alongside Thilina Senarath, her colleague at WSO2, of the actual IETF draft this is built on: OAuth 2.0 Extension: On-Behalf-Of User Authorization for AI Agents.

It adds two parameters to the standard authorization code flow.

requested_actor names the specific agent at the consent screen.

actor_token lets the agent authenticate itself when the code gets exchanged for a token.

The user sees exactly which agent they're authorizing, and the resulting token documents the entire delegation chain.

Still an Internet-Draft, not adopted by the OAuth working group, but the core shape (named actor, explicit consent, an act claim) is the part several competing drafts keep landing on independently.

Where the Building Blocks Already Exist

Ayesha's closing point wasn't that the industry needs to invent something new.

RFC 8693 token exchange with actor claims, SPIFFE/SVID workload identity, OBO flows for multi-hop agent chains, back-channel auth for ambient and long-running agents, least-privilege-by-default scoping.

All of it exists today, scattered across different corners of the identity world.

None of it has been assembled into a coherent MCP host story yet.

Her line on the closing slide says it plainly: assemble the pieces before ad-hoc workarounds calcify into the de facto standard nobody actually chose.

What to Actually Do

If you're running an MCP host, the fix isn't exotic.

Stop minting long-lived, broad-scope API keys for the host, and start treating the host as an identity in its own right, something you can name, register, and revoke independently of any one client connection it happens to manage.

If your host serves multiple clients across multiple servers, the four-A's framing doubles as a decent audit checklist.

Can you say who registered this host?

How do you verify it's still the same host?

What's it scoped to do per tool call?

Could you reconstruct what it did last Tuesday?

If the honest answer to any of those is "not really," that's the gap this talk is pointing at.

If you're building agents that act on a user's behalf rather than running fully autonomously, look hard at the OBO pattern specifically.

The line between "user did this" and "agent did this for the user" is nearly impossible to retrofit into an audit trail after the fact.

Much easier to bake into the token layer from day one.

My Take

The client-to-server half of MCP's auth story got solved early and got solved well, which might be exactly why it's easy to mistake for the whole problem.

It isn't.

The host is the piece actually doing the work, juggling clients, holding credentials, deciding what gets called and when, and the spec's current OAuth picture treats it like scenery instead of an actor that needs a name of its own.

What stuck with me about this talk wasn't the four-letter framework.

Frameworks are cheap to produce and tend to say the same four things with different labels.

What got me was that Ayesha's isn't describing this gap from the outside looking in.

She's one of the people actually drafting the IETF extension meant to close part of it.

That's a different kind of credibility than a slide claiming "the ecosystem is converging."

When the person telling you where a standard is headed is also the one writing it, that's worth sitting with for a second.

Acknowledgements

This article draws on a talk delivered by Ayesha, Associate Director and Lead Architect for Agent Identity at WSO2, at MCP Dev Summit Mumbai 2026, with supporting context from her related talk at WSO2Con North America 2026.

Ayesha co-authored the IETF Internet-Draft OAuth 2.0 Extension: On-Behalf-Of User Authorization for AI Agents, which underpins the delegation pattern discussed here.

Thanks to the Agentic AI Foundation and the Linux Foundation for organizing an event where this kind of standards-level thinking gets stage time.