Tasks extension

What the tasks extension does

The tasks extension turns an MCP request into a durable task handle when work cannot finish in one response. That shifts the interaction from a one-shot call to a managed execution object, so the server can expose progress, later status checks, cancellation, and eventual completion in a controlled way.

Conceptually, this is less about a new kind of tool call and more about persistence of work. The extension is useful when an operation is long-running, asynchronous, or dependent on external systems, because the handle becomes the stable reference point for the rest of the workflow.

Why durable task handles matter

Durable execution changes how a client and server coordinate over time. Instead of assuming the original request is the whole interaction, the server is now responsible for preserving enough state to answer later questions about progress, outcome, and ownership. That makes the task itself part of the system's lifecycle, not just the function call that created it.

In practice, this also means the handle becomes security-relevant metadata. If it is guessable, copied, or left valid for too long, it can expose operational state or let another party interfere with the work. The durability that improves usability can also expand the window in which control and accountability matter.

Lifecycle, expiry, and ownership controls

Because a task can outlive the original request, it needs explicit lifecycle rules. A server should know who created it, who may observe it, who may update it, and when it should expire or be garbage-collected. Without those rules, the handle becomes an orphaned object that is still live but no longer clearly governed.

Ownership is especially important when the underlying work can be retried, resumed, or cancelled by more than one actor. The design should make it clear whether the task belongs to a user session, a service process, or an operational controller, and whether reassignment is allowed. Those decisions determine whether the extension is merely convenient or actually safe to use in multi-step automation.

Operational patterns and design trade-offs

Tasks extension fits workflows where the server must keep working after the initial request returns, such as staged data processing, queued orchestration, or external approval flows. The handle lets clients poll or react later without tying up the original connection, which improves resilience and reduces coupling.

That convenience comes with trade-offs. More durable state means more state to protect, observe, and reconcile. Implementations should be clear about what the handle reveals, how state transitions are represented, and whether cancellation is authoritative or only advisory. The better the task model is defined, the less likely it is to drift into an ambiguous background job with weak governance.

Risk and Threat Considerations

The main risk is that a durable task handle can outlive the context that created it, which turns a temporary interaction into a reusable access path. If lifecycle rules are weak, an attacker or unauthorized user may be able to inspect progress, influence completion, or cancel work that should no longer be accessible.

Failure mechanism: A long-lived or poorly scoped handle remains valid after the original requester, session, or operational context has changed, so the server cannot reliably distinguish legitimate follow-up action from stale or unauthorized use.

Impact: This can lead to information leakage about in-flight work, unauthorized task manipulation, resource waste, or persistence of stale operations that should have been closed, revoked, or re-owned.

Practitioner Guidance

Governance implication: Treat the task handle as governed lifecycle state, not just a convenience token. Define who can create it, who can query it, who can cancel it, and what expiry or retention rules apply before the extension is enabled in production.

What to watch for: Review whether the handle is opaque, time-bounded, and bound to the correct operational scope. If a task can be resumed or modified later, the server should make those transitions explicit enough that clients and operators can reason about ownership without ambiguity.

Related resources from NHI Mgmt Group

• How should organizations manage browser extension risks?
• When should enterprises review their extension policies?
• When is it appropriate to remove a browser extension?
• What is the difference between a browser extension risk and a normal SaaS integration risk?