MCP published a stable “Enterprise-Managed Authorization” spec; the other machine-to-machine identity drafts—including an OAuth client-credentials draft and two open proposals—remain unfinished. For anyone trying to run autonomous agents with the Model Context Protocol, that means today’s protocol can verify a human user but offers no ready-to-use way to prove an unattended process is who it claims to be.
Why the roadmap matters
The Model Context Protocol (MCP) roadmap lists agent identity and security among its top priorities. Four items were slated for release: a human-centric browser flow, an OAuth client-credentials flow for services, a DPoP-based token binding, and a workload-identity federation mechanism. Only the first—Enterprise-Managed Authorization—has reached stable status.
What the stable spec actually does
Enterprise-Managed Authorization lets IT admins grant server access from a single console instead of having each employee approve every connection. The flow uses a browser redirect and a user login, so a person at a laptop can authenticate and then the server trusts that user’s session.
The limitation is obvious: the process needs a human at a keyboard. An agent that runs overnight, processes data, or responds to alerts has no one to click a login button. Consequently, any deployment that depends on unattended agents cannot use the only spec that MCP currently guarantees.
The draft options and their drawbacks
Two draft extensions aim to give agents their own identity:
- SEP-1932 (DPoP) – binds tokens to a public-private key pair, making stolen tokens useless.
- SEP-1933 (Workload Identity Federation) – lets agents inherit identities already provisioned in cloud platforms.
Both live as open pull requests; neither has been merged into the official spec. In the meantime, the only other documented option is an OAuth client-credentials flow that requires pre-registered secrets. Storing those secrets where an agent can read them creates a classic attack surface: if the secret leaks, any attacker can impersonate the agent.
Practical steps for production today
Because the protocol does not yet provide a native agent identity, teams can still secure agents by moving identity management outside MCP:
- Issue verifiable identities at the workload layer. Systems like SPIRE generate short-lived certificates tied to the host’s trust root, eliminating static secrets.
- Terminate credentials at a gateway. A front-end service holds the API key or token and forwards requests on behalf of the agent, keeping the secret out of the runtime environment.
- Authorize based on the verified identity, not the token content. Separate authentication (who is calling) from authorization (what they may do) so policy can be enforced even if the authentication method changes.
What to watch next
The two open pull requests – DPoP binding and workload-identity federation – are the only paths to a true machine-to-machine identity standard within MCP. If the community merges them, agents will be able to prove possession of a private key or inherit cloud-issued identities without exposing secrets. Until then, any production deployment must rely on external identity frameworks or accept the risk of static credentials.
The takeaway is clear: MCP can currently authenticate the person behind a request, but it does not yet authenticate the software making the request. Teams that need secure autonomous agents should not wait for the spec to land; they must build identity at the workload layer today and keep an eye on the pending DPoP and federation proposals.