MCP Just Got Stateless. Your Agent Identity Problem Did Not Move

The MCP 2026-07-28 revision dropped sessions: the initialize handshake is gone, the `Mcp-Session-Id` header is gone from Streamable HTTP, and protocol version, client info, and capabilities now ride in a `_meta` field on every request, so any instance can serve any call ^[1][2]. It is described as the largest revision since launch ^[3], and it does nothing about the two questions that stall enterprise agent rollouts: which principal the agent is acting as and what it may do ^[4], and what happens when a process runs for three days and the model context is gone ^[5].

Take the scaling win first, because it is real. Long-held SSE connections forced sticky routing, which pushed teams into shared session stores and gateway packet inspection just to scale horizontally ^[6]. The new model provisions for request rate rather than concurrent users, a round-robin load balancer is now sufficient, and Lambda, Cloud Run, and Workers become viable backends ^[7]. Multi Round-Trip Requests (SEP-2322) handle elicitation without a held connection: the server returns an `InputRequiredResult` carrying what it still needs plus an opaque `requestState` blob, and the client re-issues the same call with `inputResponses` and the echoed state, so any instance can pick up the retry ^[8]. Mid-conversation failover stops being a data-loss event ^[9].

The release also hardened authorization: RFC 9207 issuer validation, RFC 8707 resource indicators against the confused-deputy problem, client metadata documents in place of dynamic client registration, and Enterprise Managed Authorization as a named extension ^[10]. That work secures the channel between a client and a server and settles which server a token was minted for ^[11]. It says nothing about which principal the agent acts as inside that channel, or what that principal may commit to ^[12]. The dev.to piece argues no future revision is likely to move those questions inside MCP's scope, because MCP standardizes how a model reaches a tool and nothing more ^[13].

Which leaves it as your problem. A pilot agent typically runs on one set of developer credentials and can reach whatever the developer can reach, which is fine in prototyping and a standing incident in production ^[14]. The author's decomposition is four separate things: the human who initiated the work, the agent as a software principal, the runtime session, and the delegated task ^[15]. Permissions do not flow automatically from the human down ^[16]. A finance director may approve 50,000 euro payments; a meeting-summary agent running on that director's behalf has no business inheriting that authority ^[17]. Effective permission is the intersection of human permission, agent permission, task scope, and current policy ^[18]. Binary access is too coarse: an agent may simulate a production-plan change without publishing it, or request approval for a change it cannot execute itself, and each level carries different audit and authorization requirements ^[19]. What sets the approval line is consequence, not technical risk, meaning money, employment, legal rights, or access to a service ^[20].

On AWS, the author says the parts exist: AgentCore Policy evaluates every Gateway call in Cedar against a principal, action, and resource and writes the allow or deny to an audit log ^[21]; temporal policies added in August 2026 extend that across an agent's trajectory, including human approval ahead of a privileged action ^[22]; AgentCore Identity distributes credentials ^[23]; Step Functions holds anything measured in days ^[24]. The remaining work is composition, and no service ships that decision ^[25]. Note the sequencing: the temporal policy work landed after the protocol revision that removed sessions ^[26].

Watch whether the durability layer stays outside the protocol as agents get longer-lived, and whether client metadata documents replacing dynamic client registration ^[10] breaks existing registrations in your fleet. Then audit what your pilot agents are actually running as ^[14]. Treat agent identity as a first-class principal with lifecycle management, credential rotation, permission reviews, anomaly detection, and revocation, the same controls you already apply to service accounts ^[27].