Notifications
Clear all
Topic starter
07/06/2026 8:40 pm
TL;DR: MCP Tasks add durable, requestor-driven async execution to the Model Context Protocol, letting long-running tool calls return a task handle for later polling, cancellation, or result retrieval, according to WorkOS. The governance issue is that task IDs become capability-bearing handles, so authorization, TTL, and follow-up access binding now matter as much as the work itself.
NHIMG editorial — based on content published by WorkOS: MCP Async Tasks: Building long-running workflows for AI Agents
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Set short, enforceable TTLs for background executions Use the receiver’s returned TTL as the operational limit, not the requestor’s preference.
- 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.
What's in the full article
WorkOS's full article covers the implementation detail this post intentionally leaves for the source:
- The full task lifecycle examples for tools/call, tasks/get, tasks/result, and tasks/cancel in MCP.
- The exact JSON structures for task metadata, including taskId, ttl, status, and related-task correlation.
- The protocol edge cases around input_required, pollInterval, and status notifications that affect client UX.
- The security implementation notes for durable task storage, idempotency, and auth-context binding.
👉 Read WorkOS's guide to MCP async tasks and long-running agent workflows →
MCP async tasks: what changes for AI agent governance?
Explore further
08/06/2026 8:19 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP tasks make async agent workflows a first-class protocol
