{"slug": "agent-identity-and-durable-workflows-the-two-problems-mcp-can-t-solve", "title": "Agent Identity and Durable Workflows: The Two Problems MCP Can't Solve", "summary": "The latest revision of the Model Context Protocol (MCP) dropped sessions and the initialize handshake, moving protocol metadata into a _meta field to enable stateless, horizontally scalable deployments. However, the protocol still does not address two critical enterprise challenges: agent identity and authorization, and durable long-running workflows. The author notes that AWS already provides building blocks like AgentCore policy evaluation and Temporal policies, but the composition of these pieces remains unresolved.", "body_md": "MCP 2026-07-28 dropped sessions. The `initialize`\n\nhandshake is gone. The `Mcp-Session-Id`\n\nheader is gone from Streamable HTTP. Protocol version, client info, and capabilities now travel in a `_meta`\n\nfield on every request, so any instance can serve any call.\n\nThe protocol is cleaner for it. This is the largest revision since launch, and it leaves both of the questions that block enterprise agent deployments exactly where they were. MCP standardizes how a model reaches a tool. Neither question lives inside that scope, and no future revision is likely to put them there:\n\nWho is the agent acting as, and what is it allowed to do?\n\nWhat happens when a process takes three days and the model context is gone?\n\nThe spoiler: on AWS the parts already exist. Policy in AgentCore evaluates every Gateway call in Cedar against a principal, an action, and a resource, and writes the allow or deny to an audit log. Temporal policies, added in August 2026, extend that across an agent's trajectory, including human approval ahead of a privileged action. AgentCore Identity distributes the credentials. Step Functions holds anything measured in days. The remaining work is composition: deciding which principal each agent acts as, and what it may commit to. No service ships that decision.\n\nThe stateless redesign removes real pain. Long-held SSE connections forced sticky routing, which pushed teams into shared session stores and gateway packet inspection just to scale horizontally. The new model provisions for request rate instead of concurrent users. A round-robin load balancer is now enough. Lambda, Cloud Run, and Workers become viable backends.\n\nMulti Round-Trip Requests (SEP-2322) handle elicitation without a held connection. The server returns an `InputRequiredResult`\n\ncarrying what it still needs plus an opaque `requestState`\n\nblob. The client collects the answers and re-issues the same call with `inputResponses`\n\nand the echoed state. Any instance picks up the retry, because the continuity rides in the payload. Mid-conversation failover stops being a data-loss event.\n\nThe release also hardened authorization: RFC 9207 issuer validation, RFC 8707 resource indicators against the confused-deputy problem, client metadata documents replacing dynamic client registration, and Enterprise Managed Authorization as a named extension. That work is real. It secures the channel between a client and a server, and it settles which server a token was minted for. The question enterprise platform teams keep raising sits one layer up: which principal the agent acts as inside that channel, and what that principal may commit to.\n\nA pilot agent usually runs on one set of developer credentials. It can reach whatever the developer can reach. That works while prototyping. In production it is a standing incident.\n\nAn enterprise platform has to separate four things:\n\n`alexey@example.com`\n\n`production-planning-agent`\n\nPermissions do not flow automatically from the first of these to the rest. A finance director can approve €50,000 payments. A meeting-summary agent running on that director's behalf has no business inheriting that authority.\n\nThe effective permission at any moment is the intersection:\n\n*human permission ∩ agent permission ∩ task scope ∩ current policy*\n\nCan-or-cannot access to a service is too coarse for an agent. Split it into levels:\n\n| Level | Example |\n|---|---|\n| Read | View production schedule |\n| Analyze | Run what-if scenarios |\n| Recommend | Propose schedule changes |\n| Simulate | Execute in sandbox |\n| Create draft | Write proposal for review |\n| Request approval | Trigger human decision |\n| Execute | Commit the change |\n| Approve | Authorize another's request |\n\nAn agent may simulate a production-plan change without publishing it. It may request approval for a change it has no authority to execute itself. Each level carries different risk, different audit requirements, and different authorization rules.\n\nWhat decides where the approval line sits is consequence rather than technical risk: money, employment, legal rights, or access to a service. Anything that touches one of those belongs above \"request approval.\"\n\nAWS Identity and Access Management (IAM) and Amazon Bedrock AgentCore Identity each cover part of this: delegated access, OAuth flows, machine-to-machine auth, credential distribution, audit trails. The architectural principle outlives any single service. Agent identity is a first-class security principal and needs the same rigor you already apply to workloads and users: lifecycle management, credential rotation, permission reviews, anomaly detection, revocation. The controls that govern service accounts and assumed roles, extended to software that makes decisions.\n\nConsider a schedule change that breaks a committed delivery date.\n\n| Step | Needs |\n|---|---|\n| 1. Investigate the line deviation | Model reasoning |\n| 2. Read order book and capacity | Model reasoning |\n| 3. Interpret delivery commitments | Model reasoning |\n| 4. Propose a revised sequence | Model reasoning |\n| 5. Request plant manager approval | Durable execution |\n| 6. Wait for approval (days) | Durable execution |\n| 7. Publish the plan to the MES | Transaction |\n| 8. Notify affected customers | Reliable delivery |\n| 9. Record evidence | Audit |\n\nSteps 1 to 4 benefit from model reasoning: ambiguous language, edge cases, policy interpretation. Steps 5 to 9 cannot live inside a model conversation. The context window will be gone. The session will have ended. The approval may take 72 hours.\n\nTwo mechanisms in 2026-07-28 look like answers here. Both deserve precision.\n\n`requestState`\n\nsolves the protocol-level multi-round problem. The server returns a pending result with the questions it still needs answered, the client re-issues with answers, and any backend instance handles the continuation. This is progress for short-lived elicitation: clarifying ambiguous tool parameters, collecting missing inputs inside a single task. Its guarantee is scoped to one logical call. It has no concept of waiting days for a human decision, compensating a prior step when a later one fails, or producing an auditable record of what was authorized and when.\n\nThe Tasks extension (`io.modelcontextprotocol/tasks`\n\n, SEP-2663) goes further. Promoted out of the experimental core after production feedback forced a redesign, it lets a server answer `tools/call`\n\nwith a task handle. The client then drives `tasks/get`\n\n, `tasks/update`\n\n, and `tasks/cancel`\n\n, and can disconnect and come back later. For a CI run, a video render, or a data import, that is the right mechanism.\n\nA durable task ID still does not make the underlying work durable. Tasks gives you a handle plus a small state machine pointing at a result. It does not give you compensation when step 7 fails after step 5 committed, an approval queue with delegation rules, per-step retry policy, or an evidence trail an auditor will accept. Two constraints matter for planning. Task creation is server-directed and requires the client to advertise the extension per request, so an unsupported client falls back to synchronous calls. And `tasks/list`\n\nwas removed outright, because listing tasks cannot be scoped safely once the protocol is stateless. Client and SDK support is still filling in.\n\nSo the division of labor holds. Interpretation belongs to the agent, reliability belongs to a workflow engine.\n\n*start_schedule_change_workflow(plan_id, affected_orders, reason, evidence)*\n\nBehind that call, AWS Step Functions, Temporal, or Conductor manages durable state, timeouts, retries, compensation, and auditability. The agent picks the workflow; the engine owns everything after that.\n\nThe principle is worth stating plainly: probabilistic systems decide, deterministic systems execute.\n\nHTTP 200 tells you the tool call succeeded. It says nothing about whether the agent acted correctly. Was this the right tool? In the right order? Was the source data current? Was the proposed change within policy? Should the agent have refused?\n\n| Layer | Question |\n|---|---|\n| Model | Did it understand the task? Did it flag its own uncertainty? |\n| Retrieval | Were authoritative sources used, deprecated ones excluded? |\n| Tool selection | Correct tool, valid parameters? |\n| Execution | Expected operation performed? |\n| Policy | Action permitted, approval requested where required? |\n| Outcome | Business result correct, and how much human correction was needed? |\n\nEvery change to model, prompt, tool description, retrieval index, or policy can shift behavior. The platform needs representative task suites that run on a schedule as well as at release.\n\nFor AWS-heavy organizations, use the existing deterministic services as the backbone:\n\nFour things decide whether this holds up.\n\n**Credentials come from AgentCore Identity.** Permission is a separate question, answered by the target service.\n\n**The policy engine sits at the Gateway, outside agent code.** Cedar rules read principal, action, and resource, and every decision lands in an audit log. Temporal policies add the sequence checks: where an argument came from, how old the data is, whether a human signed off.\n\n**Consequential work runs in Step Functions.** The agent picks a workflow. Proceed, wait, retry, compensate: all of that belongs to the engine.\n\n**The trace is the audit record.** It runs from user request through agent session, model decision, authorization check, tool call, workflow, human approval, system change, evidence. And it has a shelf life. Step Functions keeps the execution history of a standard workflow for 90 days after it completes, and the limit is hard. European deployers of high-risk systems are expected to hold logs for at least six months under Article 26 of the AI Act. Closing that gap means calling GetExecutionHistory when an execution finishes and shipping the result somewhere durable, in a form that later edits cannot touch.\n\nAgents on developer or admin tokens. Each one is a production incident waiting for a trigger.\n\nPermission sets that turn out identical. What the human can do, what the agent should do, what the task needs: when all three match, nothing has been scoped.\n\nWork that outlives a model context. Human approval, multi-day execution, transaction guarantees. `requestState`\n\ncovers one call, Tasks covers the handle, and the process itself needs an engine.\n\nClients that stay silent about `io.modelcontextprotocol/tasks`\n\n. A server can only create a task when the client asks for the extension on that request, so an unsupported client quietly gets synchronous calls.\n\nTest suites that run at release and nowhere else. Ten to twenty representative scenarios, replayed after every prompt, tool, or model change, catch what a release gate misses.\n\nThe identity question has four fields: which principal, which permissions, which task scope, expiring when. An agent that has never had those fields written down still has them. They were set by whoever issued the token.", "url": "https://wpnews.pro/news/agent-identity-and-durable-workflows-the-two-problems-mcp-can-t-solve", "canonical_source": "https://dev.to/aws-builders/agent-identity-and-durable-workflows-the-two-problems-mcp-cant-solve-4llb", "published_at": "2026-08-13 09:52:38+00:00", "updated_at": "2026-08-13 10:16:29.388235+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-agents", "ai-infrastructure", "ai-policy", "developer-tools"], "entities": ["MCP", "AWS", "AgentCore", "Temporal", "Step Functions", "Lambda", "Cloud Run", "Workers"], "alternates": {"html": "https://wpnews.pro/news/agent-identity-and-durable-workflows-the-two-problems-mcp-can-t-solve", "markdown": "https://wpnews.pro/news/agent-identity-and-durable-workflows-the-two-problems-mcp-can-t-solve.md", "text": "https://wpnews.pro/news/agent-identity-and-durable-workflows-the-two-problems-mcp-can-t-solve.txt", "jsonld": "https://wpnews.pro/news/agent-identity-and-durable-workflows-the-two-problems-mcp-can-t-solve.jsonld"}}