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 layered over infrastructure that already knew how to solve most of these problems.

The 2026-07-28 specification removed the protocol-level session and initialization handshake. 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.

I consider that progress.

It doesn't mean MCP itself has disappeared. There is still JSON-RPC, tool discovery, MCP-specific metadata 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.

That is how it should have started.

The second part of the roadmap is much harder.

Agents need identities that are not just borrowed user credentials

MCP authorization has largely assumed there is a person sitting in front of a browser approving access.

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.

That sub-agent might create another one.

Eventually "Joshua authorized this application" is nowhere near specific enough to describe who is doing what.

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 parent agent or authorization system should be able to issue a cryptographically verifiable delegation that effectively says:

identity: sub-agent-7
acts-for: joshua
role: listener
resources: meeting-audio
permissions:
  - read
  - transcribe
expires: 12:45
delegation: prohibited

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

There are a couple of security threads in the roadmap that initially look like competing approaches, but I think they actually fit together.

Workload Identity Federation answers:

Who is this workload, and how does it obtain credentials?

The current MCP proposal builds on existing mechanisms such as RFC 7523 and OpenID Connect discovery.

That is basically:

Trust the identity infrastructure we already established.

A Kubernetes workload, SPIFFE identity or cloud workload identity shouldn't need another permanent MCP API key stuffed into an environment variable.

It should be able to exchange the credential it already has for an appropriate access token.

DPoP solves a different problem.

It answers:

How do we know the client presenting this access token is still the client the token was issued to?

The client generates a key pair and proves possession of the private key when obtaining and subsequently using the token.

The authorization server binds the resulting access token to the public key.

The resource server can then require a fresh signed proof alongside the token.

Stealing the access token alone is no longer sufficient.

That looks entirely compatible with workload identity.

One system establishes who the workload is and gets it an access token.

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.

Proof of possession is not authorization either.

Knowing:

this is Joshua's build agent

doesn't tell a service whether that agent can:

read repositories create branches merge pull requests deploy production register domains spend money create another agent

That is where I think agent infrastructure still has a lot of work ahead of it.

Traditional OAuth scopes help, but scopes are usually defined independently by each service.

repo:write means something to GitHub.

Some other service has a completely different authorization vocabulary.

Once agents dynamically compose dozens of services, defining every specialized sub-agent against every provider's permission model becomes cumbersome very quickly.

Pattern matching doesn't seem like the answer either.

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.

What I would really like to see emerge is a portable delegation model with a relatively small set of common capabilities:

read write execute create delete approve spend delegate

combined with service-defined resources.

The common part describes the kind of authority.

The service-specific part describes what that authority applies to.

Maybe the industry eventually arrives somewhere else, but authorization for specialized sub-agents feels like one of the foundational problems that has to be solved before highly autonomous agent systems are something I would trust.

Because I actually want more autonomy

The strange part is that I am arguing for stricter authorization because I want agents to be able to do more, not less.

Projects like Stripe Projects are the direction I want this to go.

An agent that can build an application, provision the services it needs, acquire credentials, configure infrastructure, deploy the application and continue operating it without stopping every five minutes to ask me to click through another dashboard is enormously compelling.

I would love to remove a lot of the current human-in-the-loop interruptions.

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.

A monitoring agent might read telemetry.

A DNS agent might alter records for one zone.

None of those agents need the full authority of the person they ultimately represent.

That is how autonomous systems become safer without becoming useless.

I am still not entirely convinced MCP needed to exist

There is another uncomfortable question underneath all of this.

The entire premise of MCP has always bothered me a little.

We already built a web for humans and APIs for software.

Instead of making those systems consistently structured, discoverable and accessible to both, the industry very quickly started building another interface specifically for AI agents.

There is something backwards about that.

We have spent decades treating human accessibility as optional while building astonishingly sophisticated machine-readable infrastructure for advertising, analytics and tracking.

Now that AI agents need access, apparently we can redesign everything.

The argument for MCP is that a common tool description, invocation model and discovery mechanism prevents every AI client from implementing thousands of proprietary integrations.

That is a legitimate benefit.

And I like the direction MCP is moving much more than where it began.

Making the remote transport ordinary HTTP is exactly the kind of simplification I wanted.

Building agent identity from OAuth, workload identity and established cryptographic standards rather than inventing MCP authentication is another good decision.

If MCP keeps moving in that direction, perhaps it becomes less of a parallel web and more of a thin interoperability layer over the web infrastructure we already have.

That version of MCP is considerably more interesting to me.

But agent delegation is going to determine whether any of this can safely become as autonomous as I want it to be.

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.