What MCP's Stateless Core and Managed Auth Mean for Integration Teams

Model Context Protocol standardizes how AI agents reach the systems around them, in much the way APIs once standardized how applications reach each other. For integration and IT operations people, it has been something to watch from a distance for two years: promising, picking up steam and still more like developer tooling than something an architecture review board would approve. That distance has shrunk. In eight months MCP has crossed three thresholds that together look like the early years of API management around 2010, repeating itself for AI agents.

Three changes in eight months

Neutral governance. Anthropic handed MCP to the Agentic AI Foundation in December 2025. It's a directed fund within the Linux Foundation, started by Anthropic, Block and OpenAI, and supported by Google, Microsoft, AWS, Cloudflare and Bloomberg. With that, MCP no longer followed a single vendor's plans and came under the sort of impartial stewardship that Kubernetes and Node.js grew up with.

Centralized authorization. On June 18, 2026, the Enterprise-Managed Authorization (EMA) extension reached stable. It replaces per-server consent screens with a model driven by the identity provider, and Anthropic, Microsoft and Okta were among the first adopters.

A stateless core. The July 28, 2026 release was the biggest spec revision since the protocol appeared, and it swaps a stateful, session-bound design for a stateless one built on plain HTTP.

These aren't cosmetic. Each takes away one particular reason MCP stayed out of serious production use, and they matter most to people who connect systems for a living and don't build AI demos.

A quick definition

MCP is an open standard for how an AI application, for example an LLM-based agent, finds and invokes external tools, reads outside resources and exchanges context with systems beyond the model. One uniform interface takes the place of a custom integration for each data source.

A rough comparison: MCP does for AI-to-system connections what REST and OpenAPI did between applications. The integrated systems stay as they are. What gets standardized is the contract between the AI client and whatever the MCP server fronts, which could be a ticketing tool, a CMDB, a monitoring platform or an internal database.

Change 1: no more sessions

During its first two years, MCP over HTTP acted like many real-time protocols. A client connected, completed an initialize handshake and got back a session ID that every later request had to include. The session bound the client to the one server instance that created it. Anyone who has put a WebSocket service behind a load balancer knows the cost. Scaling out required sticky routing, a shared session store, or a gateway that peeked at traffic to find the single instance holding the connection.

The 2026-07-28 specification removes all of that. There's no initialize and initialized handshake and no Mcp-Session-Id header. Instead each request brings its own protocol version, client identity and capabilities. As a result any server instance can answer any request, so sticky sessions and shared session stores are no longer something the protocol demands. Serverless, multi-instance clusters and edge routing then work as they do with ordinary HTTP APIs, because structurally that's what MCP has become.

Without protocol sessions, applications don't become stateless. When a server truly has to remember something between calls, like an export in progress or a long remediation task, it follows the old REST habit: it creates an explicit handle and the client passes it back as a normal argument next time. Engineers familiar with pagination and job-status endpoints will recognize it, and it's a considered choice that suits load balancers and not a patch.

The same release tightened security around the new shape. Clients must validate the issuer on authorization responses, which prevents redirect-based session hijacking across multi-server setups. They must also state which server a token is meant for, closing a delegation loophole security teams had flagged as a genuine risk in multi-tenant deployments. And MCP now has a formal deprecation policy for the first time, so breaking changes follow a real lifecycle and not ad hoc removal.

Change 2: access managed by the identity provider

The second change is less about transport and more about the daily friction of deploying agents across a company. Under the first-generation authorization approach, every employee had to complete an OAuth consent step on their own for each MCP server their AI client used. At a hundred people and six or seven internal tools, onboarding stops scaling. Security teams also lose their central view of who's connected to what, and there's no tidy way to cut access when someone moves or leaves.

EMA hands the authorization decision to the company's identity provider. An admin decides once, in the IdP, which MCP servers a group of staff may use. Later, access appears on its own the first time a person signs in through a supported client, with no consent prompts and no setup for them.

Okta was first among identity providers to support it, using its Cross App Access product as a base. The extension is built on the Identity Assertion JWT Authorization Grant, which is an open IETF specification and not something proprietary to Anthropic. Anthropic wired it into Claude, Claude Code and Cowork through a shared MCP layer, while Microsoft built support directly into Visual Studio Code. Servers that already support it include Asana, Atlassian, Canva, Figma, Granola, Linear and Supabase, and the list is growing.

The identity provider is done once it has issued the authorization grant. It sits nowhere in the tool call itself, a fact that counts in a security review: the IdP doesn't proxy every AI-to-system data flow and only decides who gets a credential. Since access is centralized, so is revocation. Disabling a departing person's account cuts all of their EMA-connected servers at once, so no one has to recall and revoke seven separate integrations by hand.

Single sign-on for a company's SaaS stack works the same way, which makes this feel familiar, and that's deliberate. Security teams needn't devise a new governance model for agents. They extend the one already running.

What it means for teams with custom glue

Many integration and platform teams didn't wait for MCP to grow up. Asked to let an internal AI assistant read Jira, post to Slack or query a monitoring tool, they wrote their own glue code: a bespoke wrapper per API, a homemade auth flow and manual session handling added because nothing standard existed. It shipped. But every new tool turned into a separate one-off, auth got reinvented for each system, and the approach broke down once a second team wanted the same ability.

The newly gained maturity targets that pain in three ways:

• Less hand-built plumbing per integration. A stable, stateless transport on plain HTTP means teams can stop writing their own connection management and handle an MCP server like any REST API sitting behind an API gateway.
• A single auth approach across tools. With EMA, security and platform staff can grant and withdraw AI tool access through the identity provider, so each hand-built connector no longer needs its own consent flow.
• A protocol fit for review boards. Neutral Linux Foundation governance, a formal deprecation policy and tougher authorization rules were the very things a build-it-yourself answer to AI connectivity couldn't offer.

The integration work itself doesn't vanish. Translating data between a ticketing schema and a monitoring schema, along with field-level transformation, deduplication and business logic that spans systems, still demands real engineering whichever protocol moves the request. What shrinks is the plumbing around it: transport, session handling and the auth flow. That cuts a good deal of undifferentiated effort, though not all of the job.

An old story with a new label

Set the AI framing aside and this is familiar. For about two decades, enterprises have built and bought integration platforms to solve plumbing for API-to-API connections: standardized authentication, centrally handled data mapping and transformation, transaction volume that grows without custom code for each new pair of systems and one place where security teams see and control what's connected.

MCP appears to be going through the same discipline for AI-agent connections, only faster. A stateless core on plain HTTP lets an MCP server look and scale like any backend service. Authorization driven by the IdP makes granting and auditing AI tool access an everyday enterprise access-control matter. And neutral governance under the Linux Foundation makes adopting the protocol resemble choosing Kubernetes, not one company's roadmap.

For integration teams the lesson isn't that agents require a brand-new playbook. The methods already used to connect systems reliably, securely and at scale now apply directly to agents too. The protocol layer is settling into infrastructure people already understand, and what sets teams apart moves higher up, into data mapping, governance enforcement and change management across the systems at each end, which was always the harder part.