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.
At a glance
What this is: This is an analysis of MCP Tasks showing that the extension lacks a normative authorization check, leaving task IDs able to function like bearer credentials for task access.
Why it matters: IAM and security teams should treat task IDs as sensitive capability-like values, because missing per-request authorization in a protocol spec creates a repeatable access-control flaw across every compliant implementation.
Context
MCP Tasks moves long-running work into a separate extension, which shifts the security question from session handling to request-level authority over a task object. The problem is not just whether the task ID is hard to guess, but whether the protocol requires the server to verify who is asking before returning task state or accepting task-related actions.
In that model, a taskId behaves more like a capability than a simple reference token. If the spec lets possession of the identifier stand in for authorization, then the control boundary moves from identity checks to entropy and obscurity, which is a weaker and much less governable security model.
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. If the protocol does not require a per-request ownership check, anyone who learns or guesses the identifier may retrieve results, subscribe to notifications, or influence the task. That creates unauthorized access and makes task state dependent on secret possession rather than identity and policy.
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. That turns a local defect into a category-wide governance failure, because reviewers and implementers have no normative text telling them to enforce the missing control.
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. If the system returns different errors for missing versus unauthorized task IDs, or lets subscriptions expose task data without ownership validation, it is leaking control through its error handling and access model.
Q: Should task lifetime be tied to the credential that created it?
A: Yes, because task state that outlives the issuing credential becomes harder to govern and revoke. If revocation does not end task access, the system can retain authority beyond the session or principal that created it, which creates an avoidable persistence window.
Technical breakdown
Why taskId behaves like a bearer credential
The Tasks extension allows a caller to fetch results, listen for notifications, and submit responses using a taskId. When a protocol makes possession of an identifier sufficient to reach protected state, that identifier stops being a mere label and starts acting like a bearer credential. The core weakness is not only guessing resistance, but the absence of a mandated ownership check on every request. That means a compliant implementation can still leak task contents to the wrong principal if it trusts the ID alone. Practical implication: treat task identifiers as sensitive access-bearing values, not harmless object references.
Practical implication: Bind every task operation to the authenticated principal, not to possession of the identifier alone.
Why capability negotiation is not authorization
The spec requires a client to declare support for the Tasks extension, but that declaration is self-asserted and unrelated to resource ownership. Capability negotiation answers whether a client may speak a feature, not whether it may access a specific task instance. That distinction matters because feature flags can be checked without any identity binding, while authorization must resolve who owns the object being requested. If the protocol stops at capability presence, it leaves a gap between syntax and authority. Practical implication: separate protocol support checks from access-control decisions and never treat one as a substitute for the other.
Practical implication: Keep feature negotiation and authorization as separate controls in implementation and review.
How capability URLs create an existence oracle
The article points out that the protocol defines no distinct error for a task that exists but does not belong to the caller. That omission forces implementers into a bad choice: reveal whether the task exists or lie in a way that still leaks structure. Combined with unconditional retrieval and subscription behavior, that creates an existence oracle, where repeated probes can distinguish live task identifiers from invalid ones. An oracle is not just an information leak; it also helps an attacker test harvested identifiers at scale. Practical implication: make failure responses indistinguishable for missing and unauthorized tasks.
Practical implication: Return the same error for unauthorized and nonexistent task IDs, and rate-limit repeated lookups.
Threat narrative
Attacker objective: The attacker wants to hijack task-bound state and interact with another caller's long-running work as if they owned it.
- Entry occurs when an attacker obtains or guesses a valid taskId and uses it against task endpoints that do not enforce ownership checks.
- Escalation follows when the same identifier grants access to results, notifications, and input channels without a separate authorization decision.
- Impact is unauthorized disclosure, injection, or cancellation of long-running task state that should have remained bound to the original principal.
Breaches seen in the wild
- Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Task IDs have become a capability boundary, not a lookup key: In MCP Tasks, the identifier itself can gate access to results and side effects, which means the governance question shifts from where a task lives to who can exercise it. That is a material change for identity design because object possession can now behave like authority. Practitioners should treat task handles as security-bearing artifacts, not implementation details.
The missing control is authorization, not entropy: The protocol can require unguessable identifiers and still fail if it never requires a per-request ownership check. That distinction matters because entropy reduces discovery, while authorization defines entitlement. When a spec conflates the two, it creates a control plane that looks secure in review but cannot prove who is allowed to act.
Zero trust does not survive when protocol state is unbound from principal identity: Zero trust assumes every request is verified against a trusted identity and policy context, not merely a valid token-shaped string. In this case, the trust decision is deferred into the identifier itself, which is exactly the kind of shortcut zero trust is meant to remove. Zero Trust Identity Guide should be read here as a reminder that request-level authorization must remain explicit.
Capability negotiation is not governance: A client saying it supports Tasks is a feature declaration, not an entitlement assertion. That distinction matters because protocol conformance can be met while ownership checks remain absent, which means governance cannot be inferred from compatibility alone. Security teams should judge task systems by authorization semantics, not by extension support claims.
Capability URLs are the right named concept for this failure mode: The article describes a system where possession of a task identifier can unlock state, notifications, and input handling without an explicit principal check. That is a classic capability URL pattern, and it is dangerous because the governance model becomes indistinguishable from secret possession. The implication is that review processes must inspect who the capability is bound to, not just how hard it is to guess.
From our research library:
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Read next: NHI Lifecycle Management Guide
What this signals
Capability-bound task state: MCP Tasks shows how quickly a protocol becomes harder to govern when an identifier doubles as a permission boundary. Once state, notifications, and cancellation are all reachable through the same task handle, review has to focus on principal binding rather than identifier secrecy. The operational question for teams is whether every task interaction is evaluated against identity and policy at the moment of use.
The bigger lesson is that protocol conformance is not the same as authorization soundness. A spec can look complete while still leaving ownership undefined, which means implementers inherit ambiguity at exactly the point where governance needs precision. Teams should expect more scrutiny of capability-style identifiers in AI tooling, especially where long-lived work crosses service boundaries.
For practitioners
- 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.
- Treat task IDs as non-authoritative Generate task identifiers with a CSPRNG, but never rely on them as the only access control or as proof of entitlement.
Key takeaways
- The core issue is not guessing resistance but missing authorization, which allows task identifiers to function like bearer credentials.
- The article shows how a protocol-level omission can scale into a repeatable control gap across every conformant implementation.
- Teams should bind task actions to the authenticated principal, make unauthorized and missing responses indistinguishable, and stop treating task IDs as the sole access check.
Related NHI Mgmt Group resources: NHI Lifecycle Management Guide · Zero Trust Identity Guide · Guide to SPIFFE and SPIRE · Smithery.ai MCP hosting breach 2025
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centers on task access without a required auth check. |
| NHI-05 — Overprivileged NHI | A taskId that confers broad action rights is effectively over-privileged. | |
| NHI-07 — Long-Lived Secrets | Unbounded task lifetime creates a bearer-like credential that persists too long. | |
| Recommendation — Require principal-bound authorization on every task request before returning task state or side effects. Limit task handles to the minimum action scope and never let possession imply full task control. Tie task validity to credential lifetime and revoke task access when the issuing identity loses authority. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The flaw turns harvested task IDs into a path for unauthorized access and movement within task state. |
| Recommendation — Map task-ID abuse to credential access and lateral movement use cases in detection and review. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | This is fundamentally an authorization-control failure at request time. |
| Recommendation — Enforce request-level entitlements so task actions are approved against identity, not identifier possession. | ||
Key terms
- Capability URL: A capability URL is a link or identifier that grants access by possession rather than by a separate authorization check. In identity governance terms, the object itself becomes the proof of access, so whoever holds it can act unless the system rebinds the request to a principal.
- Principal Binding: Principal binding means a session is tied to a specific identity such as an IAM role or service account rather than to a reusable credential string. For non-human identities, that binding improves attribution, narrows misuse, and makes governance dependent on the source identity rather than secret custody.
- Existence oracle: An existence oracle is an error or response pattern that lets a caller distinguish between a valid resource and a missing one. For task systems, this can help attackers probe whether an identifier exists, even when they are not entitled to know that it does.
- Bearer-like credential: A bearer-like credential is any string or token that grants access to the holder without an additional ownership check. When a task identifier behaves this way, the security model depends on secrecy and guess resistance instead of explicit authorization.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org