An MCP extension that lets a server return a task handle for work that continues after the original request. In governance terms, it creates a durable execution object that can be checked, updated, or cancelled, which means lifecycle, expiry, and ownership controls matter as much as the task itself.
Expanded Definition
In MCP, the Tasks extension turns an otherwise synchronous interaction into a durable execution object that can be observed and managed after the initial call returns. That changes the governance model: the server is no longer just answering a request, it is maintaining state about ongoing work, including who owns it, how long it may exist, and whether it can be resumed or cancelled. In practice, this sits closer to workflow control than to a simple API response, and definitions vary across vendors because some implementations emphasise status polling while others emphasise lifecycle operations and cancellation semantics.
The key distinction is that a task handle is not the work itself. It is the control surface for work that continues elsewhere, which makes expiry, retries, and authorization boundaries central to safe use. The closest external reference point is NIST SP 800-53 Rev 5 Security and Privacy Controls, especially for access control and system integrity expectations, because the extension creates state that must be protected like any other governed resource. The most common misapplication is treating the task handle as a lightweight convenience token, which occurs when teams ignore ownership, expiry, and cancellation rules.
Examples and Use Cases
Implementing the Tasks extension rigorously often introduces lifecycle overhead, requiring organisations to weigh operational flexibility against the cost of tracking state, permissions, and expiry.
- A long-running model evaluation job returns a task handle so the client can check progress without holding an open connection.
- An agent delegates a file-processing workflow to an MCP server and later cancels it when the user revokes consent.
- A governed automation platform uses task status to enforce approval gates before a privileged action completes.
- Security teams review task metadata to detect abandoned work, especially when a task outlives the user session that created it.
- Developers document task ownership and retention rules so a second operator can safely resume or terminate the work if the original requester disappears.
These patterns are easier to understand when paired with broader NHI risks such as secret leakage and unmanaged service execution. NHIMG notes that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, a useful reminder that durable handles and credentials often fail together. Related examples of hidden credential exposure are documented in Hard-Coded Secrets in VSCode Extensions, while NIST SP 800-53 Rev 5 Security and Privacy Controls is useful for mapping the access-control expectations that should govern task state.
Why It Matters in NHI Security
Tasks extension matters because it expands the attack surface from one request to an entire lifecycle. Once a task can be checked, resumed, or cancelled, the server must defend against stale handles, unauthorized updates, confused ownership, and tasks that continue after the original principal should no longer have influence. That is particularly important in agentic environments, where an AI agent may create many durable execution objects while chaining tools and delegating actions across services.
From an NHI perspective, task governance is inseparable from identity governance. A task that outlives its creator can become a lingering control point for a service account, API client, or delegated agent. NHIMG reports that only 20% of organisations have formal processes for offboarding and revoking API keys, which highlights how often lifecycle control is weaker than execution control. The same pattern appears in Hard-Coded Secrets in VSCode Extensions, where hidden operational dependencies become security liabilities once they outlive their expected context. Organisations typically encounter the real risk only after a task is abandoned, replayed, or cancelled incorrectly, at which point the Tasks extension becomes operationally unavoidable to secure.
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, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Tasks extend NHI lifecycle and ownership requirements beyond a single request. |
| OWASP Agentic AI Top 10 | A-04 | Durable task handles are core to agent execution, delegation, and control flow. |
| CSA MAESTRO | MAESTRO addresses agent orchestration patterns that include durable task state. | |
| NIST CSF 2.0 | PR.AA-01 | Task handles require authenticated, attributable access to stateful operations. |
| NIST Zero Trust (SP 800-207) | Zero trust requires continuous authorization for each task state change. |
Instrument task state transitions and restrict agent actions to authorized workflow boundaries.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
