The Model Context Protocol got its largest specification update on September 28, shipped under the Agentic AI Foundation, a Linux Foundation directed fund. The headline items: a finalized stateless architecture, hardened OAuth authorization, a formal 12-month deprecation policy, and the graduation of MCP Apps and MCP Tasks to official extensions. Each of those maps to a specific thing that has been breaking in production.
Stateless is the one that changes your deployment
The original MCP transport assumed a long-lived session between client and server. That assumption is fine on a laptop and terrible behind a load balancer. Sticky sessions, connection affinity, and resumption logic are the reason most teams running MCP servers for more than a few dozen users ended up with a bespoke gateway in front. A finalized stateless mode means a server can be an ordinary horizontally-scaled HTTP service — any replica answers any request, restarts are free, and autoscaling stops being a correctness problem. If you built session affinity into your infrastructure, that work is now mostly deletable, which is a rare and good outcome.
The OAuth hardening lands on a gap the maintainers had already named in the August 22 roadmap, where "agent identity and enterprise-ready security" was one of five priorities. WorkOS's read of the earlier roadmap was blunt about the status quo: static client secrets remain common in production MCP deployments, with the stated goal being SSO-integrated flows managed from the same IdP console as everything else. That matters if you're exposing a retrieval server over Confluence or a ticketing system, because the retrieval layer is where per-user permission scoping either happens or quietly doesn't.
The 12-month deprecation policy is the least exciting and probably most load-bearing change. It makes MCP something you can put in a procurement document.
The layer nobody standardized
Set against this, the contrast with agent memory is sharp. In a Help Net Security interview published the same week, Vectorize CEO Chris Latimer described finding coding agents storing API keys, credentials, and sensitive documents in plain text on developer machines. The follow-on point, picked up by security practitioners since, is structural rather than anecdotal: a memory write persists and gets replayed into future sessions, so a bad input can change agent behavior weeks later, long after anyone would think to correlate the two.
This is the asymmetry worth internalizing. The connector layer now has a spec, an identity story, a registry, and a deprecation clock. The memory layer has none of that — no schema, no provenance on writes, no retention policy, no audit trail. OWASP already classifies vector and embedding weaknesses as a top-ten LLM risk, covering both embedding inversion and retrieval-pipeline poisoning, and the academic work on runtime memory injection is active.
Practical read for this week: if you operate MCP servers, plan the stateless migration and kill your static secrets. If you ship agents with persistent memory, go look at where those writes actually land, who can author them, and whether anything expires. Most teams will not like the answer.