Topic starter
27/10/2026 7:09 pm
TL;DR: Possession of a taskId can expose results, notifications, and cancellation rights unless implementers bind every request to the authenticated principal, according to Mindgard research on MCP's new Tasks extension, which ships without a normative authorization requirement. The missing check turns task IDs into capability-like secrets, and that assumption breaks zero trust at the protocol layer.
Editorial analysis by NHI Mgmt Group, based on content published by Mindgard: “Zero Auth != Zero Trust: The MUST that Never Made it into MCP's New Tasks Extension”.
Key questions
Q: What breaks when task IDs are treated as the only access control?
A: Task IDs stop being harmless references and become bearer-like credentials.
Q: Why does missing authorization in a protocol spec matter more than a single implementation bug?
A: A single bug affects one deployment, but a missing requirement in the spec can be reproduced by every conformant implementation.
Q: How can teams tell whether a task system is actually enforcing ownership?
A: Look for a principal-bound decision on every task-related request, not just a capability check or a hard-to-guess identifier.
Practitioner guidance
- Authorize every task request Check each tasks/get, subscriptions/listen, and input-response action against the authenticated principal before returning any state or side effect.
- Bind server state to a derived user identifier Store task ownership against a server-derived identifier instead of a caller-supplied token so that reassignment and impersonation are not possible.
- Make unauthorized and missing look identical Return the same error for not-yours and does-not-exist cases, and apply rate limits so task existence cannot be probed as an oracle.
Bottom line: The core issue is not guessing resistance but missing authorization, which allows task identifiers to function like bearer credentials.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →