MCP Is Finally Becoming Boring HTTP. Now It Needs Real Agent Delegation

David Soria Parra and Den Delimarsky published a new roadmap for the Model Context Protocol, and there are two parts of it I find particularly interesting.

The first is something MCP probably should have done much earlier: with the July 28 specification, a remote MCP server can now be operated much more like an ordinary HTTP workload. Good. The original stateful transport, initialization handshake, and session behavior always felt like unnecessary protocol machinery. The 2026-07-28 specification removed the protocol-level session and initialization handshake, and requests are now self-contained and can land on any instance behind a normal load balancer without sticky sessions or shared session state.

That makes MCP considerably less special operationally, and I consider that progress. There is still JSON-RPC, tool discovery, and a standardized application contract for agents. But at least we no longer need to build unusual server infrastructure just because the caller happens to be an AI. A remote MCP server can increasingly behave like any other HTTP service, which is how it should have started.

The second part of the roadmap is much harder.

MCP authorization has largely assumed there is a person sitting in front of a browser approving access, and that model stops working once agents become actual workloads. An agent may run for hours without the user present. It may create another specialized agent, and that sub-agent might create another one. Eventually "Joshua authorized this application" is nowhere near specific enough.

The roadmap is now prioritizing workload identity, DPoP, Enterprise-Managed Authorization, token exchange, and delegation. That is the right problem.

I am particularly interested in how they handle sub-entities. I don't want every agent acting with one giant token representing me. If I create a specialized agent to listen to something, it should be able to listen. If another agent needs to enter information, it should be able to enter information.

Borrowing the construction from Fight Club:

I am Jack's right ear. Awesome. You get to hear stuff. I am Jack's right hand. Great. You get to input stuff.

But the agent should not be able to simply say that and gain those permissions. That would be ridiculous. The authority has to come from something outside the model—a cryptographically verifiable delegation issued by a parent agent or authorization system. The model doesn't decide that it is the right ear. The authorization system does. That distinction seems essential.

Workload identity and DPoP solve different problems, and I think they fit together. One establishes who the workload is and how it obtains credentials; the other makes the access token substantially harder to steal and replay. That feels like a sensible layering of existing standards rather than inventing another MCP-specific authentication system.

But neither one answers the hardest question. Identity is not authorization. Knowing "this is Joshua's build agent" doesn't tell a service whether that agent can read repositories, merge pull requests, deploy production, spend money, or create another agent. An AI should never be able to reason its way into additional authority by satisfying some natural-language description of a role. The permissions need to be explicit, externally issued, and mechanically enforceable.

The strange part is that I am arguing for stricter authorization because I want agents to be able to do more, not less. An agent that can build an application, provision services, deploy, and continue operating without stopping every five minutes to ask me to click through another dashboard is enormously compelling. But the only way I am comfortable doing that is if the authority gets narrower as the agents become more specialized. A deployment agent might deploy. A billing agent might spend up to a defined amount. None of those agents need the full authority of the person they ultimately represent.

Giving an agent an identity is relatively easy. Giving it exactly enough authority to do its job, no more, and the ability to prove that authority everywhere it goes is the much more interesting problem.

Read the full MCP roadmap.