MCP tasks make async agent workflows a first-class protocol

At a glance

What this is: MCP Tasks turn synchronous tool calls into durable async executions with polling, cancellation, and later result retrieval.

Why it matters: That matters because identity teams now have to govern long-lived non-human workflows, not just one-shot API calls, and the same lifecycle discipline will increasingly apply to AI agents and other machine identities.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.

👉 Read WorkOS's guide to MCP async tasks and long-running agent workflows

Context

MCP Tasks address a basic governance gap in long-running machine-to-machine work: the protocol now treats a request as a durable execution, not just a blocked call waiting for a response. In identity terms, that shifts the problem from transport timeout management to lifecycle control over a non-human execution handle, where access, retention, and cancellation all become part of the security model.

For AI agent and workload teams, the key question is not whether async execution is useful. It is whether the organisation can still bind every delayed result, follow-on request, and background action to the same authorised identity context after the original call has moved on. That is the difference between an operational convenience and an identity governance boundary.

MCP is becoming more like an execution plane for agentic workflows, which means the surrounding controls have to mature with it. When a protocol standardises async state, it also standardises a new place to hide privilege, retain data, or lose auditability if task handles are not governed as sensitive capabilities.

Key questions

Q: How should security teams govern MCP async task handles in production?

A: Security teams should treat MCP task handles as sensitive, scoped capabilities tied to the original user, tenant, or API client. Every follow-up call should be checked against that same authorization context, with short TTLs, clear cancellation rules, and audit logs that preserve the full task lifecycle from creation to terminal state.

Q: Why do MCP Tasks change the risk profile of non-human identities?

A: MCP Tasks turn a one-shot call into a durable execution path, so the access decision no longer ends when the initial request returns. That creates a new governance boundary around polling, result retrieval, and related follow-on messages, which can outlive the original intent if task handles are not tightly controlled.

Q: What breaks when task IDs are not bound to the original identity context?

A: If task IDs are not bound to the original identity context, any later poll or result request can become a replayable access path into in-flight work. The main failures are data leakage, unauthorized cancellation, and audit trails that no longer prove who approved the workflow in the first place.

Q: How do MCP async workflows affect zero standing privilege goals?

A: MCP async workflows do not eliminate standing privilege by themselves, because the task handle can preserve access beyond the original call. Zero standing privilege only holds if the task can be created, queried, and closed within the same authorised context and with no persistent, reusable privilege left behind.

Technical breakdown

Durable task handles and task lifecycle state

MCP Tasks replace a blocking tool call with a durable execution record. A request can return a taskId immediately, while the receiver tracks state transitions such as working, input_required, completed, failed, and cancelled. That design matters because the task handle is now the linkage between the original authorisation event and every later read or follow-up interaction. The task object also carries TTL, timestamps, and polling guidance, which turns execution into a governed state machine rather than an opaque background job.

Practical implication: treat task IDs as sensitive non-human identity artefacts and bind them to the original authorization context, not just to a connection.

Capability negotiation and per-tool async permissions

Tasks are not globally assumed in MCP. Both peers must opt in, and the server can restrict which request types may be task-augmented. On top of that, tools can declare execution.taskSupport as forbidden, optional, or required, which creates a second layer of control at the individual tool level. This is a useful pattern because it prevents every slow or sensitive operation from being pushed into background mode by default. It also means task behaviour is not just a transport property, but an authorisation decision embedded in protocol metadata.

Practical implication: review tool-level task permissions as carefully as API scopes, because async execution itself is now a privilege boundary.

Related-task metadata, polling, and result retrieval

MCP keeps async workflows coherent by attaching related-task metadata to every follow-on elicitation, sampling, or status event. Polling via tasks/get remains the source of truth, while tasks/result returns the terminal payload and tasks/cancel closes the loop. This is a deliberate design choice: the protocol preserves the original result format, but delays delivery until the task is terminal. That also creates a governance requirement, because every later interaction can reveal the same data or trigger the same action long after the initial request was made.

Practical implication: instrument task correlation and retention controls so delayed outputs do not escape the identity and audit context that created them.

Threat narrative

Attacker objective: Exploit durable task handles to retrieve or influence long-running work outside the original authorization context.

1. Entry occurs when a requestor creates a long-running MCP task and receives a durable taskId that can be reused for later access, polling, or cancellation.
2. Credential access or abuse happens if task IDs are treated as ordinary references instead of sensitive capability handles and can be enumerated or replayed outside the original auth context.
3. Impact follows when delayed results, follow-on requests, or related-task messages expose data or actions beyond the intended session boundary, turning async convenience into governance drift.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Async execution exposes a task-handling governance gap, not just a performance feature. Once a background job persists beyond the original request, the identity problem changes from session authentication to follow-up authorization. That means task IDs, result endpoints, and cancellation rights all become part of the access model, and teams that still think in single-call terms will miss the real control surface. Practitioners should govern task handles as first-class non-human identity artefacts.

Task IDs are capability handles, which means enumeration risk becomes an identity risk. MCP explicitly allows later polling, result retrieval, and cancellation by taskId, so the handle itself carries authority. If that handle is guessable, weakly scoped, or retained too long, the protocol creates a replayable access path into in-flight work. The practical conclusion is that lifecycle binding and short retention are not implementation details, they are the boundary conditions of trust.

Long-running MCP workflows make least privilege harder to define at creation time. The receiver may not know all execution needs when the task begins, yet later steps can request additional input or emit related requests under the same task context. That is a familiar governance pattern for human tickets, but a much tighter problem for machine identities because the workflow can outlive the original authorisation intent. Teams should assume the privilege boundary must be reevaluated at each task transition.

Tool-level async control is becoming a new form of privilege scoping for non-human identities. The experimental taskSupport setting lets a server distinguish between synchronous, optional, and required background execution at the tool level. That means governance is shifting from whether an API exists to whether a specific operation may continue after the requestor has moved on. Practitioners should expect future NHI policy models to treat async eligibility as a distinct access attribute.

Task correlation makes auditability possible, but only if the organisation preserves the full chain. Related-task metadata solves the protocol problem of keeping elicitation, sampling, and status events attached to the right workflow. The deeper governance issue is whether the organisation can still prove who authorised each step once the task has crossed multiple messages and retention windows. That is where async MCP work will expose weak lifecycle discipline fastest.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That visibility gap is why teams should pair agent governance with the Ultimate Guide to NHIs before async task execution becomes the default operating model.

What this signals

Task-based MCP design will push identity teams to manage workflow boundaries, not just credentials. Once background execution becomes a protocol primitive, the relevant question is whether the organisation can still prove who owns the task at every transition point. That will force tighter coupling between NHI lifecycle controls, audit logging, and protocol-aware authorisation checks, especially where agent workflows can reconnect after interruption.

Durable async handles should be treated like hidden privileges. When a task can be fetched later, cancelled later, or resumed later, the security model shifts from authentication at request time to authorization across time. Teams that already struggle with secret sprawl and inconsistent scoping should expect the same pattern to appear in task IDs unless they deliberately limit retention, visibility, and replayability.

Async agent governance will increasingly intersect with agentic AI standards such as the OWASP Top 10 for Agentic Applications 2026. The useful concept here is execution-handle debt: the longer a task can be polled or resumed, the more hidden authority it accumulates if the organisation cannot bind it to a living identity context. That makes protocol design and lifecycle governance inseparable.

For practitioners

• Bind every taskId to the originating identity context Require tasks/get, tasks/result, and tasks/cancel to succeed only for the same tenant, user, or API client that created the task. Treat taskId as a capability handle, not a harmless reference, and log every follow-up access against the original authorization event.
• Set short, enforceable TTLs for background executions Use the receiver’s returned TTL as the operational limit, not the requestor’s preference. Keep retention tight for completed, failed, and cancelled tasks so delayed retrieval does not become an unintended access window.
• Scope async eligibility per tool, not just per server Review which operations are allowed to become tasks and mark sensitive or fast-path actions as forbidden where background execution adds no value. Use tool-level controls to prevent durable workflows from becoming a default privilege escalation path.
• Correlate every follow-on message to the task lifecycle Persist related-task metadata across elicitation, sampling, status updates, and final result handling so audit trails stay intact after reconnects or retries. Without that linkage, incident response will lose the sequence of events behind a long-running workflow.
• Redesign monitoring around transition points, not single calls Alert on state changes such as working to input_required, repeated polling without terminal progress, and cancellation patterns that suggest abandoned or stuck jobs. Those signals are more useful than raw request counts when async execution becomes normal.

Key takeaways

• MCP Tasks convert background work into a durable identity and authorization problem, not just an async engineering pattern.
• Task IDs, follow-on requests, and terminal results all expand the control surface unless they stay bound to the original context.
• Practitioners should scope async eligibility, shorten retention, and preserve full task correlation before long-running MCP workflows become routine.

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.
• Related-task metadata: Related-task metadata is the protocol tag that ties follow-on MCP messages back to the same background execution. It preserves workflow correlation across status updates, elicitation, and sampling requests. Without it, auditability and incident reconstruction degrade quickly in async agent workflows.
• Execution-handle debt: Execution-handle debt is the accumulation of hidden authority in a long-lived task reference when an organisation cannot prove who still controls it. The longer a task can be resumed or queried, the more important lifecycle binding, retention, and cancellation governance become.

Deepen your knowledge

MCP async task governance and durable handle binding are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building agent workflows that outlive a single request, it is worth exploring.

This post draws on content published by WorkOS: MCP Async Tasks: Building long-running workflows for AI Agents. Read the original.