Rolling out AI agents to thousands of non-technical employees requires centrally managed access, tenant isolation, and controls on every tool call. MCP JSON-RPC session architecture provides interoperability, but enterprises must build the state, identity, and governance layers that make it production-worthy. A governed gateway puts that work in shared infrastructure so each employee or server team does not have to handle it.
What MCP's JSON-RPC session model was built for, and what enterprise scale actually demands
MCP’s “USB-C of the AI world” framing describes interoperability. The original design was built for a single trusted user working locally. Its client-server architecture uses JSON-RPC 2.0, with a host creating isolated client sessions that each maintain a stateful channel to an MCP server. At initialization, the host negotiates capabilities covering Tools, which are callable functions, Resources, which are readable data, and Prompts, which are reusable instruction templates.
The protocol does not natively isolate tenants, enforce enterprise authentication, or attribute token usage and API costs to agents. STDIO relies on operating-system process isolation, while Streamable HTTP supports remote deployments. Both transports leave the application controls for teams to build.
The interface handles transport, the application handles routing, validation, and authorization checks, the domain contains business logic, and infrastructure connects enterprise systems through drivers and adapters. A dedicated control plane, such as Runlayer’s AI governance platform, can sit between agents and servers to enforce identity and policy at tool-call depth. That placement addresses shared governance without confusing it with the protocol itself.
How the July 2026 spec shift from stateful to stateless changes the scaling calculus
The 2026-07-28 specification removes the stateful initialization handshake and protocol-level sessions, including the Mcp-Session-Id header. Every request becomes self-contained. Clients put the protocol version, client identity, and capability flags in the JSON-RPC envelope’s _meta object, and list endpoints stay the same across connections. Every Streamable HTTP POST must also include Mcp-Method and Mcp-Name headers, allowing gateways to route without parsing the body.
This removes the sticky-session scaling trap, but not application state. A server retaining context returns an explicit handle, such as a basket ID, browser ID, or ticket ID, for later calls to pass as an ordinary argument. The model can reason about that identifier. The same revision introduces the opt-in Tasks extension for asynchronous work.
The hard problem moves into application architecture. Session identity, tenant ID, authenticated user, allowed tools, budget limits, and audit trace ID belong in a shared external store. MCP gateways can expose those constraints through headers and metadata. Engineers still own the store design, identity binding, multitenancy, authorization, and observability that give those values meaning.
Why the STDIO transport is an unacceptable default for any enterprise-facing server
OX Security’s April 2026 research, “The Mother of All AI Supply Chains,” identified command execution vulnerabilities in Anthropic’s official MCP SDKs for Python, TypeScript, Java, and Rust. The vulnerable configuration path passed parameters to the host shell without first running sanitization on them. A command could execute regardless of whether it initialized a valid MCP server. Local process isolation does not make that input trustworthy.
For enterprise deployments, the transport decision follows that boundary. Servers that are shared, remote, or production-facing should use Streamable HTTP, which supports OAuth 2.1 and horizontal scaling. The earlier HTTP+SSE transport from the 2024-11-05 revision is deprecated and should not be chosen for new servers. Streamable HTTP also needs protection against DNS-rebinding, with Origin validation, HTTP 403 responses when origins are invalid, and local binding set to 127.0.0.1 in place of 0.0.0.0.
Remote access needs more than a different connection method. Trend Micro found hundreds of internet-exposed MCP servers with no authentication. Teams must pair their choice of transport with authentication checks before requests reach the server.
What the MCP authorization specification actually requires, and where it still leaves gaps
The MCP authorization specification sets OAuth 2.1 as the baseline for remote servers. It requires PKCE for all clients, removes the implicit grant, and tightens redirect URI handling. Discovery uses RFC 9728 Protected Resource Metadata, while RFC 7591 covers Dynamic Client Registration. RFC 8707 Resource Indicators bind tokens to a target server in both authorization and token requests, and RFC 9207 requires clients to validate the authorization response’s iss parameter.
These requirements address specific failure paths. The specification documents a confused-deputy risk when a proxy combines a reused static upstream client ID with cached consent cookies. Its mitigation requires per-client consent storage and state validation before redirect. Successful login is not sufficient protection against that attack.
Enterprise-Managed Authorization, stable as of June 2026, lets an identity provider provision server access centrally. Anthropic, Microsoft, and Okta have adopted it. Employees can receive connected servers on first login without separate per-app OAuth setup, but EMA does not inspect traffic after token issuance. The specification also defines no role-based access control model, leaving per-tool permissions to the deploying organization.
How to re-engineer session state for multitenancy without breaking the protocol
To close that application-layer gap, teams should make tenant isolation an invariant from state creation. Every tool input, output, cache entry, and piece of retained context needs a tenant scope. Filtering only when data is accessed is insufficient. Bind the tenant ID at authentication, pass it explicitly into tool calls, and key stored application sessions with{tenantId}:{sessionId}:{key}.
Tool discovery needs its own tenant boundary. A tenant-aware registry should expose only the tools available to that tenant, rather than relying solely on call-time authorization. Under the stateless revision, this belongs in application-level discovery and policy.
Agent handoffs need the same explicit treatment. Propagate tenant identity whenever an orchestrator spawns a sub-agent, because inherited session context can also transfer the parent’s permissions. Bloomberg’s ASKB agent, introduced in January 2026, treated prompts and toolchains as configuration and used identity-aware, multi-tenant MCP servers from the outset. Bloomberg cut experimentation cycles from weeks to minutes, illustrating why governance belongs in the initial design.
The agent identity and credential management layer the spec does not define
Human-delegated OAuth does not establish an autonomous agent’s identity. When an agent represents a user, that user’s identity and delegation scope must cross every service boundary with the request. Without them, downstream services lack the context to authorize the action. The MCP OAuth Client Credentials extension addresses unattended authentication, while standardized agent identity and delegation remain under development.
Credential aggregation makes this gap especially consequential. MCP servers can hold access to several enterprise systems behind one interface, so compromise can spread across those integrations. Cyata researcher Yarden Porat’s January 2026 Anthropic Git MCP Server exploit chain produced CVE-2025-68143, CVE-2025-68144, and CVE-2025-68145, covering path traversal, argument injection, and repository-scoping failures. Azure MCP Server’s missing-authentication vulnerability, CVE-2026-32211 from April 2026, received a CVSS score of 9.1.
The operational response is short-lived, scoped, per-agent credentials through client credentials flow. Automatic expiry limits exposure, centralized identity-provider management enables revocation, and authentication events remain auditable. Runlayer handles OAuth and credential management as platform infrastructure, using JIT credentials, SSO, and SCIM with tool-call-depth controls. That is an alternative to rebuilding credential plumbing for each deployment.
The threat surface that lives inside an authenticated, authorized MCP session
An authenticated agent can still execute a poisoned instruction. OWASP’s MCP Top 10 distinguishes tool poisoning in metadata, intent flow subversion through contextual prompt injection, command injection through unsanitized input, shadow servers outside governance, and context over-sharing. These attack different boundaries. They cannot be reduced to stolen credentials or failed login checks.
Tool metadata can directly shape how an agent behaves. Invariant Labs demonstrated tool poisoning against Claude Desktop that extracted private repository source code through a poisoned GitHub MCP server. Microsoft’s Defender Security Research Team also showed prompt injection escalating into remote code execution in popular agent frameworks. Legitimate access did not make the content safe.
The June 2026 Sentry MCP agentjacking incident affected thousands of organizations with injectable DSNs. Sentry declined root-cause remediation and deployed a filter for the identified payload string, a narrower response than controlling the underlying behavior. Intent drift presents a related runtime problem without requiring a new login. An agent can accumulate context and permissions until its effective capabilities exceed the task originally authorized, making session-start checks inadequate.
What gateway-layer controls must enforce before a tool call reaches business logic
All MCP traffic should pass through controls for TLS and mTLS, per-tenant rate limits, and JSON-schema validation. Transport translation can place legacy STDIO servers behind HTTP without code changes. That preserves compatibility while local execution risks still require checks.
Identity then determines which validated calls may proceed. Tools declare scopes such asinventory:read,invoices:write, andpayments:initiate, and the gateway issues short-lived agent JWTs with only the allowed scopes. A policy engine such as OPA/Rego enforces tenant boundaries even when an agent guesses another tenant’s resource identifier. Routing uses the method and name headers, while authorization still evaluates the requested action.
Catalog controls protect what the gateway exposes. In a foundry deployment, unpinned latest references allowed a breaking schema change to silently reject hundreds of production queries. Production catalogs should require explicit versions such as [email protected] and promotion through Dev, Staging with hostile prompt evaluation, Signed, and Prod. An atomic catalog-pointer change provides rollback. For organizations that choose platform infrastructure over a custom build, Runlayer’s control layer lets them see servers, skills, and agents and enforces policy tied to identity at tool-call depth.
Why observability must reach tool-call depth, not just the session boundary
Session logs record that an agent connected, authenticated, and finished. They do not explain each intervening action. Incident response needs every tool call’s inputs, outputs, and policy decisions in tamper-proof audit logs, especially when behavior changes during execution. The audit boundary must match the enforcement boundary.
OpenTelemetry tracing connects those records across the agent call chain. Traces should span initiation, gateway processing, tool execution, and infrastructure access, with user identity and delegation scope traceable at every service boundary. Otherwise, a multi-hop action cannot be reconstructed with its authorization context intact.
Detection must also operate while the session runs. Tool poisoning, prompt injection, intent drift, and exfiltration require behavioral detection rather than only later log review or payload-string filters. Runlayer’s security layer combines those runtime detections with tamper-proof logs and full OTEL tracing. Whether built internally or supplied through a platform, this depth exposes identity, audit, and access-control gaps before they stall an enterprise pilot’s move into production.
A practical architecture checklist for enterprise MCP deployments
For deployment planning, the decisions fall into five connected groups. Transport readiness means Streamable HTTP for shared or remote servers, migration away from HTTP+SSE, and the required method and name headers. MCP-Protocol-Version should support backward compatibility only while the migration is under way. The deployment target is the 2026-07-28 specification.
Authentication readiness means OAuth 2.1 with PKCE S256, no implicit grant, resource indicators in authorization and token requests, and iss validation. Upstream APIs need separate tokens, never forwarded inbound client tokens. Employees should get access through EMA and the enterprise identity provider. Autonomous agents need client-credentials JWTs that are short-lived and scoped in place of static API keys.
State readiness means a shared external store for identity, tenant context, tool permissions, budgets, and trace identifiers. Tenant-keyed entries, tenant-aware tool discovery, and explicit agent-handoff context form the isolation boundary. Gateway readiness adds TLS/mTLS, rate limits, schema validation, and policy-engine enforcement of tool scopes. A signed, version-pinned catalog should turn away unsigned servers and require hostile prompt evaluation before a server is approved for production.
Operational readiness requires tamper-proof tool-call records, end-to-end OTEL traces, and live detection of MCP-specific threats. Delegation must remain traceable across every service boundary. Cost attribution must show which agent or tenant is responsible for the cost. Runlayer provides enablement, control, and security across these layers as one platform option.