The MUST that Never Made it into MCP's New Tasks Extension
Affected Vendor(s)
Model Context Protocol
Affected Product(s)
MCP Tasks
Summary
MCP's new Tasks extension has a missing requirement resulting in no authorization enforcement in its normative text; nothing obliges a compliant server to check who is requesting a task.
The missing requirement was written down twice but never shipped. SEP-2663's Security Implications carries four bullet points, the published spec carries only three of them as byte-identical, but missing the second bullet point.
This wasn't an oversight nobody saw. The conformance suite lists the Auth binding MUST by name and excludes it as untestable at the wire layer, making this seem more an accidental oversight rather than deliberate omission
Anyone holding an MCP taskId can read the task's full result, subscribe to its push notifications, inject responses into it, as well as cancel it. There's no defined error for exists-but-it-is-not-yours, so even a careful implementer can't avoid shipping a taskId existence oracle.
Developers using MCP should avoid letting the taskId be the only access control. Authorize every task request against the authenticated principal, key stored state on a server-derived user identifier, generate IDs with a CSPRNG, and return the same error for not-yours as for doesn't-exist.