Dora NodaThe Model Context Protocol won the agent-connectivity war in sixteen months: from launch in November 2024 to roughly 97 million monthly SDK downloads by March 2026, a ramp that took React about three years. Some 10,000 public servers are now listed across the major registries, and as of April 2026, 78% of enterprise AI teams run at least one MCP-backed agent in production.
And then, in May 2026, the NSA and CISA published a joint security sheet on MCP whose message boils down to this: the protocol cannot enforce consent, privacy, or tool-safety principles at the protocol level. Authorization and credential isolation are not yet standardized. Log everything, sandbox tool execution, and scan your network for MCP servers you did not approve — because the standard that just conquered your stack shipped without a governance story.
That gap is what the 2026 enterprise-readiness push is about. This post lays out exactly what a production MCP gateway has to expose, maps each capability to what the July 2026 spec actually standardized versus what you still build yourself, and compares that self-built surface against what enterprise vendors now sell as a paid layer.
The gateway checklist, up front
If you run tool servers that agents can reach — and especially if those tools can deploy, roll back, or touch production — this is the surface your gateway needs. Each row shows whether the open spec covers it or you own it:
| Capability | What it does | Spec status (2026-07-28) |
|---|---|---|
| OAuth/SSO termination | One place where agent identity is authenticated, bound to a human principal | Base standardized (OAuth 2.1, RFC 9728 + 8707); enterprise SSO patterns are extensions |
| Tool-level RBAC | Which identities may call which tools, per server | You build it — no standard RBAC model in core spec |
| Approval / human-in-the-loop queue | Mutating calls (deploy, rollback, delete) wait for a human approve/reject | You build it — no standard approval primitive |
| Audit-record schema | Every invocation logged: who, what, which identity, on whose behalf, when | Roadmap extension, not core spec; NSA/CISA says log all tool and model invocations |
| Credential isolation | Server-side secrets never reach the agent or the client | Flagged as not-yet-standardized; gateway vault is the pattern |
| Registry / allowlist | Unregistered servers and tools are uncallable | No standard discovery yet (server/discover is roadmap); you build the registry |
| SIEM export | Audit trail streams to existing compliance tooling | You build it |
The single most important row is the audit record. Here is what a compliant entry for an agent-triggered deploy needs to contain — this is the artifact your auditors, your incident reviews, and your compliance team will actually read:
{
"event": "tool.invoke",
"tool": "paas.deploy",
"server": "registry/deploy-prod",
"agent_identity": "agent:deploy-bot-04",
"on_behalf_of": "user:ada@example.com",
"approval": {
"decision": "approved",
"approver": "user:grace@example.com",
"at": "2026-09-23T08:10:02Z"
},
"arguments_hash": "sha256:9f2c…",
"result": "success",
"trace_id": "4bf9…"
}Three questions, answered in one record: who approved which deploy, which agent identity executed it, and how you prove it after the fact. Everything below unpacks how each row got to its current state — and what it costs to own the rows the spec left blank.
SSO: what the July 2026 spec hardened, and the identity gap it left
The 2026-07-28 specification revision is the largest MCP update since launch, and authorization carries most of the weight. Where a server implements auth, the requirements are now concrete: OAuth 2.1 with the MCP server acting as a resource server, mandatory OAuth 2.0 Protected Resource Metadata (RFC 9728) for authorization-server discovery, and RFC 8707 resource indicators that bind a token to the exact server it was issued for.
That last item closes a real replay gap — a token minted for one server can no longer be presented to another. Dynamic Client Registration is deprecated in favor of Client ID Metadata Documents, and the core protocol went stateless, dropping the initialize handshake and Mcp-Session-Id sessions. It is a breaking change from the 2025-11-25 revision, and server operators had to migrate.
That is real hardening, and it standardizes the bottom half of enterprise identity: agents authenticate with tokens that are scoped, discoverable, and non-replayable across servers. But the top half — the SSO story an enterprise actually buys — is still a pattern, not a protocol. Binding an agent identity to a human principal (on_behalf_of), mapping IdP groups to tool-level permissions, session lifetimes for delegated agent authority, and single-sign-on flows across a fleet of tool servers are all things the 2026 roadmap (published via the AAIF after the April MCP Dev Summit) lists as enterprise SSO work to be delivered as extensions rather than core spec. The NSA/CISA guidance singles out authorization as not yet standardized for exactly this reason.
In practice, this means your gateway terminates OAuth, validates the token, and then performs the identity join the spec does not define: token → agent identity → human principal → permitted tool set. Every vendor gateway below sells you its version of that join. If you self-host, it is the first component you write.
Audit trails: the extension the roadmap deferred
Structured audit logging sits in the same bucket: officially on the 2026 roadmap (alongside observability hooks, gateway/proxy mode, and config portability), explicitly slated for extensions rather than the core specification. The protocol tells clients and servers how to talk; it does not yet tell anyone how to record what was said.
Meanwhile the pressure to record it keeps rising from outside the spec process. The NSA/CISA sheet recommends logging all tool and model invocations. The Five Eyes agencies' May 1 "Careful Adoption of Agentic AI Services" guidance enumerates 23 risks and over 100 practices for agentic systems. CISA added a LiteLLM MCP command-injection CVE (CVE-2026-42271) to its Known Exploited Vulnerabilities catalog in June 2026, weeks after an April disclosure of an MCP design vulnerability. And the background statistics are grim: a scan of popular MCP servers in early 2025 found 43% with command-injection flaws and 30% reachable via server-side request forgery, many with no authentication by default.
So the audit row is non-negotiable and non-standard at the same time. What "compliant" means today is defined by security guidance, not by the protocol: immutable, timestamped records of every tool invocation with identity, arguments (or a hash of them), approval state, and result — exportable to whatever SIEM already holds your other compliance evidence. Build that schema once at the gateway, in front of every server, rather than bolting logging onto each tool server differently.
Pinterest's registry-first pattern in production
The clearest proof that the gateway shape works at scale comes from Pinterest, which spent the past year building its internal MCP ecosystem around multiple domain-specific, cloud-hosted servers connected through a central registry. The rule is simple and absolute: if a server is not in the registry, no agent surface can call it. The registry is the policy enforcement point — discovery, allowlisting, and access control in one lookup layer the team built ahead of the spec, since the protocol still offers no standard way for a registry to learn what a server does without connecting to it first.
The reported numbers justify the investment: around 66,000 monthly MCP invocations and roughly 7,000 engineering hours saved. Pinterest's architecture is also a preview of where the roadmap wants the whole ecosystem to go — a standard server/discover mechanism would make their custom lookup layer a commodity — but until that extension lands, the registry is a component every serious deployment builds for itself.
The paid layer vs. the self-hosted stack
With the spec covering the wire protocol and authentication base but leaving RBAC, approvals, audit, registry, and credential isolation to implementations, vendors have moved into the gap. The category went mainstream when AWS Bedrock AgentCore Gateway went GA in October 2025; since then the paid layer has taken a consistent shape:
- AWS Bedrock AgentCore Gateway — managed gateway in front of tool servers with AWS IAM semantics.
- Google Cloud's managed MCP servers — IAM controls, fine-grained authorization, audit logging, and Model Armor screening for prompt injection and data disclosure.
- Docker MCP Gateway — tool allowlists per profile plus a catalog of 300+ verified, signed server images that doubles as an approved-server allowlist, with each server container-isolated.
Against that, the open-source counterpoint is best represented by projects like mcp-airlock: an audit-first, zero-dependency gateway promising tool-level RBAC, an encrypted credential vault, and SIEM-ready logs in a single process you drop between any MCP client and your servers. The pitch is the whole checklist table above without a vendor contract.
The build-vs-buy math therefore depends on which rows you already own. If your platform terminates OAuth, runs an approval queue, and ships logs to a SIEM today, the gateway is mostly a new proxy with an MCP-aware policy engine — very buildable. If you own none of those, the managed gateways are buying you an identity join, an audit schema, and a registry you would otherwise design under audit pressure. Either way, budget for the registry-plus-approval shape: Pinterest's production evidence says that is the architecture, whether you rent it or run it.
What this means for a deploy-from-chat PaaS
For a platform where agents deploy and roll back real services, the enterprise-readiness push collapses to the worked record near the top of this post. The 2026-07-28 spec gives you scoped, non-replayable agent credentials. Everything that turns those credentials into governed operations — the human who approved the deploy, the identity that ran it, the immutable proof afterward — is gateway surface you either build or buy before your first production incident, not after.
The roadmap will eventually standardize more of it: structured audit events, SSO extension profiles, standard server discovery. Until then, treat the seven checklist rows as your definition of done, and treat any tool server reachable without passing through them the way the NSA/CISA guidance does — as an unauthorized server, waiting to be found.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Agent-driven deploys need governed infrastructure underneath them; star the repo on GitHub or deploy your first app today.
