MCP tasks make async agent workflows a first-class protocol

At a glance

What this is: This article explains how MCP Tasks change long-running AI agent work from synchronous calls into durable async jobs with polling, cancellation, and result retrieval.

Why it matters: It matters because MCP Tasks turn request handles into security-sensitive capability objects, which changes how teams should think about authorization, tenant binding, and lifecycle control for agent workflows.

Context

MCP Tasks address a basic governance and runtime gap in agent workflows: not every tool call finishes inside a single request-response window. Once execution outlives the transport session, the identity model must track a durable handle, not just a transient call.

For identity and access teams, the important shift is that the task itself becomes part of the access surface. That affects non-human identity controls, async orchestration, and how follow-up requests are authenticated and authorised across the full task lifecycle.

The article frames this as an interoperability change, but the security consequence is broader. Durable async work only remains safe when the task handle is bound to the same principal, tenant, and permission scope that created it.

Key questions

Q: What breaks when MCP tasks are not bound to the caller that created them?

A: Task IDs become reusable handles for status, result retrieval, and cancellation, so an unbound task can leak data or control across users and tenants. The fix is not just stronger logging. The task must be authorised against the same identity context that initiated it, or it behaves like an unprotected capability token.

Q: Why do async MCP tasks require tighter authorisation than ordinary tool calls?

A: Because the access decision survives the initial request and extends into later polling, cancellation, and result retrieval. That means the security boundary is no longer the call itself. It is the full task lifecycle, which can span reconnects, retries, and delayed follow-up messages.

Q: How can teams tell whether MCP task retention is too long?

A: If task state or results remain retrievable after the operational need has passed, the retention window is too broad for the access model. Long TTLs enlarge the time in which an exposed or guessed task ID can be abused. A safe design keeps TTLs short enough to match workflow value, not convenience.

Q: What is the difference between polling and notifications in MCP task handling?

A: Polling is authoritative and should be treated as the source of truth, while notifications are best-effort speed-ups for user experience. If a notification is missed, the client can still recover the correct state by calling tasks/get. That distinction keeps background execution observable without making delivery reliability a security dependency.

Technical breakdown

How MCP Tasks create a durable async state machine

MCP Tasks change a request from a single blocking call into a small state machine with lifecycle states such as working, input_required, completed, failed, and cancelled. The requestor can ask for async execution with a TTL, while the receiver decides whether the request type is task-augmentable and how long task state persists. That separation matters because task creation, status polling, cancellation, and result retrieval are distinct protocol operations, not one combined action. The protocol also allows both sides to advertise support per request type, which keeps async behaviour explicit rather than implicit. In practice, this is what makes background work interoperable across clients, servers, and SDKs.

Practical implication: Treat async capability as a negotiated control surface, not a default behaviour.

Why task IDs become security-sensitive capability handles

A taskId is not just a reference number. It is the handle that grants access to status, result, and cancellation for a specific execution, so it behaves like a capability object and must be protected as such. The article makes the binding requirement explicit: follow-up calls should only succeed when the caller’s authorisation context matches the one that created the task. Without that binding, a leaked or guessed task ID can become a backdoor into task state and outputs. Short TTLs, cryptographically unguessable IDs, and context filtering are therefore part of the access model, not optional implementation details.

Practical implication: Bind every task to the original principal, tenant, and client context before exposing status or results.

How polling, notifications, and cancellation interact in MCP

MCP separates authoritative state from convenience updates. tasks/get is the source of truth, notifications can improve responsiveness, and tasks/result returns the final underlying response once the task reaches a terminal state. That design lets clients reconnect, resume polling, or coordinate multiple long-running jobs without inventing a side channel. Cancellation is also explicit: once a task is cancelled, its state should remain cancelled even if background work eventually completes. This avoids race conditions where a stale execution returns after the requestor has already withdrawn trust in the workflow. The architecture is therefore built around durable correlation plus terminal-state integrity.

Practical implication: Design your client and server around authoritative polling, then use notifications only as a latency hint.

NHI Mgmt Group analysis

Task handles are now part of the access surface, not just workflow plumbing: MCP Tasks turn long-running execution into a durable object that must be authorised like any other sensitive identity artefact. The article’s design makes task IDs fetch, cancel, and result-bearing handles, which means lifecycle control now matters after the initial call has left the request path. Practitioners should treat the task itself as governed access, not as an implementation detail.

Least privilege at request time is incomplete when execution continues later: Access decisions for a task cannot end at creation because the task may poll, elicit input, or return results long after the first request. That extends the security boundary across background execution and reconnect scenarios, where stale assumptions about who may resume a workflow become dangerous. The implication is that task-bound authorisation must survive transport loss, retries, and delayed follow-up calls.

Durable async workflows expose a lifecycle gap in NHI governance: Long-running MCP tasks are a non-human identity pattern where the governing object outlives the original interaction. Existing controls often assume a request either completes immediately or can be reviewed after the fact, but task-based execution creates an in-between state with active access, delayed results, and possible input requests. Practitioners should recognise that the governance unit is no longer the call, it is the task lifecycle.

Task correlation creates the named concept of task-handle governance: Once a taskId can retrieve state, trigger cancellation, and anchor follow-on messages, it becomes a governance object with its own trust boundary. That changes how teams think about tenant isolation, auditability, and revocation across AI agent workflows. The practical conclusion is that async protocol design and identity governance now meet at the same control point.

Asynchronous agent work validates the need for protocol-level authorization, not ad hoc wrappers: The article shows why per-tool logic and side channels break down once workflows become durable and multi-step. A requestor-driven async model only stays governable when the protocol itself carries the binding, retention, and retrieval rules. Teams should therefore evaluate MCP implementations as identity surfaces, not just developer convenience layers.

From our research library:

• Gartner predicts that by the end of 2026, 40% of enterprise apps will feature task-specific AI agents.
• Read next: AI Agent Authorisation Guide

What this signals

Task-handle governance: MCP turns long-running agent work into a durable object that can be polled, cancelled, and resumed later, so identity teams need to govern the handle itself rather than only the original request. That shifts control emphasis from session completion to follow-up authorisation and retention.

Access reviews do not map cleanly onto workflows that can pause, resume, or elicit input midstream. When a task can survive transport loss and still expose results later, the control point moves to issuance, context binding, and revocation of the task handle.

The same pattern applies across AI agent governance and workload identity: once the protocol permits deferred execution, the trust boundary must follow the task lifecycle. That is the practical difference between a synchronous tool call and a governable async workflow.

For practitioners

• Bind task IDs to the originating principal Require every tasks/get, tasks/result, and tasks/cancel call to verify the same user, tenant, or API client that created the task before revealing state or outputs.
• Set short TTLs for long-running tasks Limit how long task state and results remain retrievable, and treat the returned TTL as the authoritative retention window rather than the caller’s preference.
• Filter task listings by authorisation context Ensure tasks/list only returns in-flight jobs that belong to the caller’s context so background work cannot be enumerated across tenants or teams.
• Use polling as the source of truth Treat notifications as latency hints and rely on tasks/get for authoritative state, especially when reconnecting after client or agent restarts.
• Design for idempotent task creation Deduplicate retries so a timeout does not spawn duplicate background jobs, especially when clients repeat task-augmented requests across unstable connections.

Key takeaways

• MCP Tasks convert long-running agent activity into a durable access object that must be governed across its full lifecycle, not only at request time.
• The main security risk is not background execution by itself, but the fact that task IDs can expose status, results, and cancellation if they are not tightly bound to the original caller.
• Teams should focus on context binding, short retention, and authoritative polling because those controls determine whether async MCP remains auditable and contained.

Key terms

• Task handle: A task handle is the durable reference returned for a long-running MCP execution. It lets a client poll status, request results, or cancel the work later. In identity terms, the handle is a capability, so it must be scoped to the same actor and context that created it.
• Requestor-Driven Async Execution: Requestor-driven async execution means the caller decides when to create, poll, or resume a task instead of waiting synchronously for one response. For identity governance, that design shifts control from the request window to the full lifecycle of the work item.
• Task Lifecycle: Task lifecycle is the sequence of create, poll, update, complete, and cancel events for long-running work. In MCP, the lifecycle shifts governance away from a single request and into continuing identity, authorization, and revocation checks across the lifetime of the task.
• Capability Negotiation: Capability negotiation is the handshake process where the client and server exchange supported protocol versions and available functions before work begins. It helps both sides agree on what can be used, reducing compatibility issues and making tool access more predictable during the session.

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.