MCP DPoP sender-constrained tokens: Sume is bearer-only today

Sume's hosted MCP does not advertise sender-constrained tokens today. Its OAuth access tokens are plain bearer tokens, accepted from the Authorization header only, with the mcp_at_ prefix and a one-hour lifetime. DPoP is a roadmap item on the MCP side, not a Sume feature.

Roadmap wording is from the MCP roadmap (last updated 2026-08-22), read 2026-10-01. Sume details are from the mcp-oauth package and MCP OAuth and API keys.

What does the MCP roadmap say about DPoP?

Under Agent Identity and Enterprise-Ready Security, the roadmap says the Agent Identity working group, which is forming during the roadmap period, should finalize the specification for Demonstrating Proof of Possession (DPoP) and focus on getting widespread adoption. It is a plan, not a shipped protocol feature.

What does Sume's authorization server publish today?

What does bearer-only mean for my client?

Whoever holds the token can use it until it expires, so treat it like a password: do not paste it into prompts, store it in CLI config or forward it to third parties. The docs also say an MCP OAuth token is not a Sume API key. Send it as Authorization: Bearer <token>; the metadata lists header as the only bearer method.

How do I limit the damage of a leaked token?

Keep the grant narrow. Consent leaves Write off by default, so an mcp:read token only sees read-only tools. The short lifetime bounds the rest; see the one-hour token post. I found no DPoP or proof-of-possession field in the Sume metadata, so do not build a client that expects one.