Architecture · August 15, 2026 · 7 min read
Stateless MCP did not require a control-plane rewrite
The protocol changed substantially. Our governance semantics did not—and that was the point of the architecture.
MCP 2026-07-28 removes the protocol handshake and session model from the HTTP path. A request now carries its own protocol metadata, client information, and capabilities. That is a major transport change for a server that previously depended on initialize, Mcp-Session-Id, and sticky routing.
For AI Governance Platform, it was a meaningful upgrade—but not a rewrite. Our control plane was already designed around request-scoped identity, explicit tenant context, and durable resources. The new protocol aligns the outer transport with the way the system already works inside.
Keycloak gave us the right starting point
Every protected request is authenticated at the HTTP boundary with a Keycloak-issued bearer token. The server validates that token, constructs an authenticated principal, and resolves organization and project context for that request. Role and membership checks then decide whether that actor may perform the requested operation.
That matters because identity, tenancy, and authorization do not depend on a conversation held in an MCP transport session. A later request can be handled by another server instance and still reconstruct the same security context from its token and approved scope.
MCP request → Keycloak bearer token → authenticated principal → tenant context + RBAC → audit + application service → durable governance resource
Keycloak alone does not make an MCP server stateless. A server can use token-based authentication and still keep protocol sessions. What it gave us was the important separation: authentication and authorization are resolved per request, rather than being hidden in a transport-specific session.
State is explicit and durable
The word stateless describes the MCP protocol boundary, not the application's memory. Governance decisions, evidence, audit records, replay executions, jobs, assets, and runtime connections are durable resources with their own identifiers and persistence contracts.
When a workflow needs continuity, it passes an explicit ID. A job tool returns a job ID; a replay tool returns a replay execution ID; a later tool call names that resource again. This is the same model used by well-designed HTTP APIs: make the resource visible rather than relying on a hidden server session.
What still needed to change
The old MCP HTTP lifecycle was still session-oriented, even though our governance application was not. Supporting the new specification required a real transport modernization: version negotiation, request metadata reconstruction, header-based routing, and a stateless request path.
We implemented that at the protocol boundary. The native endpoint now prefers 2026-07-28, where each request carries its protocol version and the Mcp-Method and Mcp-Name routing headers. Existing session-based clients remain supported during migration, but new clients can use ordinary load balancing without a shared MCP session store.
Importantly, we did not create a second governance implementation. Both protocol eras normalize into the same authorization, audit, idempotency, tenant-context, and application-service path. A tool does not make a different governance decision because it arrived through a legacy client or a stateless one.
Why this is operationally simpler
Stateless HTTP lets gateways authorize and route requests without preserving affinity to a particular worker. That reduces the infrastructure concerns around horizontally scaled MCP: no sticky load balancer rule, no protocol-session replication, and no session recovery logic when an instance is replaced.
The result is intentionally unremarkable infrastructure. MCP behaves more like the rest of a secure HTTP estate, while governance remains a durable, auditable control plane behind it. This is also why the specification's move to header-based routing and per-request metadata is valuable for gateway operators.
The architectural lesson
The question was never whether AI Governance Platform could become stateless. Its security and governance semantics were already request-bound and resource-oriented. The work was to make the protocol adapter reflect those existing boundaries, without leaking MCP lifecycle concerns into policy, audit, jobs, replay, or persistence.
That is a healthier migration than replacing an application because a transport evolved. Protocol compatibility stays outside; governance semantics stay inside.