"Where do we enforce who can call which tool?" A customer's security team asked me that recently, before approving a wider rollout of their agents. Several of their teams were building agents, each with its own rules for its agents, and those agents called the same internal MCP servers.
MCP's own roadmap says the quiet part out loud: "MCP authorization assumes a person with a browser at consent time." Then, one sentence later, it admits that assumption is already wrong. "Increasingly the caller is an agent: a cloud workload with its own identity, acting for a user who isn't present, or spawning sub-agents that should get narrower authority than their parent." That's not a footnote. It's one of five priority areas the Core Maintainers named for the next spec release, published August 22, 2026, and it's the only one with a working group that doesn't exist yet.
MCP's HTTP transport has worked like a phone call since Streamable HTTP shipped in March 2025: a client dials in with initialize, the server answers and hands back an Mcp-Session-Id, and every request after that stays pinned to whoever picked up. Hang up on the wrong server instance and the whole conversation is gone with it. Sixteen months later, the 2026-07-28 spec revision rips the phone call out entirely. MCP is now stateless. Every request carries everything it needs, and any healthy server behind a load balancer can answer it cold.
In 2025, a single MCP package called mcp-remote racked up 437,000 downloads before anyone noticed it had a command-injection flaw rated 9.6 out of 10 for severity, CVE-2025-6514. It's patched now. It's also not unusual: it's the pattern OWASP's new security checklist for MCP was built to catch before the next one gets 437,000 downloads deep.