MCP maintainers turned away a request-signing proposal. 91 days later a bot asked if anyone still cares.
SEP-2752 wanted every MCP request cryptographically signed so a stolen token is worthless. The working group had already picked a different answer, and the thread shows exactly how a fully written security proposal gets demoted to an optional extension nobody owns.
On Monday morning an automated bot in the Model Context Protocol repository posted a message under pull request 2752: the proposal "has been inactive for 91 days." It asked the author whether he was still working on it, whether anything was blocking progress and whether he needed "help finding a sponsor." The proposal in question is SEP-2752, HTTP Message Signing for MCP Client Authentication, and the thread above the bot's notice is a compact record of how the protocol that wires most commercial agents to their tools decides what security it will and will not have.
The proposal, opened on May 19 by a contributor posting as njdawn, is technically specific. It asks MCP to adopt RFC 9421 HTTP Message Signatures as an optional way for a client to prove it holds a private key, instead of handing the server a bearer token on every request. The author lists six structural problems with the bearer model MCP uses today. Secrets are "re-exposed to the server on every request." Anything that terminates TLS, including CDNs, reverse proxies and "corporate egress inspection," sees the token in plaintext. A bearer token "says nothing about the body" of a request. Captured tokens stay "valid until rotation." There is no verifiable client identity. And clients end up holding access tokens "really intended for server to resource-server communication." The stated target use case is high-stakes servers: wallets, payments, secret stores and production database writes, where "a leaked bearer in those settings drains a wallet or exfiltrates secrets with no recovery."
"The bar for revisiting that decision is high"
The response that decided the proposal's fate came on June 7 from D-McAdams, a maintainer active in the protocol's authorization working group. The group, he wrote, had already "debated this space, including HTTP Message Signatures, and landed on DPoP," the OAuth-based proof-of-possession mechanism tracked in a separate proposal. "The bar for revisiting that decision is high." He added that "having two competing PoP mechanisms in the core spec creates implementation burden and ambiguity," that "the working group has made a deliberate choice to standardize on OAuth," and that "a non-OAuth authentication model will face significant resistance in the Auth WG." He offered a door: "Another path that doesn't require changing the core spec is MCP's extension model."
The author took it within hours. That same evening he reframed SEP-2752 as an Extensions Track proposal, "opt-in and disabled by default, so there's no second PoP mechanism imposed on the core spec," and noted that a reference implementation already existed. He asked for fifteen minutes to demo wallet-based use cases from "the crypto/wallet community." The thread shows no reply to that request. The last human comment is dated June 8. The next entry is the bot, three months later. The pull request still carries the "proposal" label, is still open and still lists no sponsor.
What shipped instead
It is fair to ask what the working group's preferred answer has delivered in the meantime. The 2026-07-28 specification, the largest revision in the protocol's history, hardened authorization with issuer validation and bound client credentials to the authorization server that minted them. It did not ship DPoP, and it does not mention proof of possession at all. So as of this week MCP clients still authenticate with bearer tokens, the mechanism SEP-2752 was written to replace, while the approved alternative remains a proposal and the rejected alternative remains an unowned extension.
None of this is a scandal. Standards bodies say no to good ideas all the time, and the maintainer's reasoning about competing mechanisms is the conventional one. The discussion was also more substantive than most. A reviewer posting as dadrus pointed out that RFC 9421, DPoP and mutual TLS all prove that the immediate caller holds a key, and that none of them "establishes who authorised that caller," which is the harder problem when one agent calls a tool on behalf of another agent on behalf of a person. The author's answer was to make identity and key discovery pluggable, with the Web Bot Auth directory model as a "MUST-implement baseline" that is "decentralized" and needs "no central identity authority." That is a real design argument, and it is now sitting in a closed loop with no one assigned to carry it forward.
Why it matters beyond the thread
Agent identity is where the money is heading. Entrust is issuing cryptographic identities to agents. Okta is rolling out Cross App Access so agents can carry authorization between applications. Gateways from Citrix and others are being sold on the promise of governing MCP traffic at the network edge. Every one of those products has to decide whether the thing it inspects is a bearer token it could replay or a signature it cannot. The MCP core has, for now, decided that question by default. The protocol's own deprecation policy promises twelve-month transition windows for anything it removes, which means whatever authentication model it locks in next will be the one enterprise servers live with well into 2028.
The bot's question on Monday was procedural, but it is the right one. Is anyone still working on this? The public record says no, and it also says no one in a position to sponsor it has said why the extensions track was the end of the road rather than the start of one. Neither the author nor the maintainer quoted above has posted in the thread since June. We will update this story if either does.
