MCP Registries Are the New API Gateways. They're Also Not Enough.

MCP's enterprise story used to be about connectivity. That changed this week.

At RSA Conference 2026, Cisco announced a full stack of agentic security features: agent identity management mapped to accountable humans, MCP policy enforcement, all tool traffic routed through a gateway, and runtime intent monitoring. Google Cloud declared that enterprises would be able to build security agents with remote MCP server support under unified governance controls. InfoWorld ran a detailed breakdown of what separates a toy MCP registry from an enterprise-grade one.

The headline: the industry moved from "what is MCP?" to "how do you govern it?" in about 18 months. That's fast — faster than enterprises moved on API governance, and we all remember what happened when those got out of hand.

From directory to control plane

The critical framing comes from Derek Ashmore, agentic AI enablement principal at Asperitas Consulting, quoted in the InfoWorld piece: "A good MCP registry is more than a directory of tools. It's part of your control plane."

That's a systems architecture claim, not a marketing claim. And it's the right one.

A basic MCP registry is just a catalog — here are the servers your agents can find. An enterprise-grade registry is infrastructure: it enforces which tools are approved, carries policy-aware metadata, manages lifecycle from deployment to revocation, and generates the observability data you need when someone asks what that agent did and on whose authority (InfoWorld).

Cisco's announcements put specific shape around this. Their updated Secure Access product routes all MCP tool traffic through a gateway, enforces policies, and monitors agent intent at runtime. Agent identities get mapped to accountable humans — because when something goes wrong, someone has to own it. The survey data explains why enterprises are moving on this: 85% of major enterprise customers are experimenting with AI agents, but only 5% have moved agentic technology into production (Cisco). The gap is not capability. It's trust.

Google's RSAC framing made the same point from the security side: enterprise agent workflows need remote MCP server support with governance controls attached, not bolted on after the fact. You can't audit what you didn't instrument.

The same lesson, playing out again

There's something familiar about this moment. Integration catalogs were essential at the peak of SaaS. API gateways followed when direct integrations multiplied beyond anyone's ability to manage them. Now MCP registries are emerging to do for agents what those layers did for services.

The lesson from those previous cycles is not encouraging: discovery always outruns governance. By the time enterprises got serious about API security, shadow integrations had already spread across departments. By the time SSO became mandatory, dozens of SaaS tools were already running on personal credentials and shared passwords.

The question now is whether enterprises can get ahead of agent sprawl before it becomes unmanageable. The Cisco data says most haven't — 80 percentage points separate "experimenting" from "in production." That gap is mostly security and governance. The MCP registry and gateway work happening now is an attempt to close it. GovInfoSecurity noted the same pressure from another angle: agentic AI expands API exposure at a rate that hardens the case for stronger access controls across the board (GovInfoSecurity).

The registries are necessary. They're also only half the problem.

What registries don't govern

Here's what the MCP registry conversation is mostly skipping: the knowledge layer.

An MCP registry tells an agent which tools it's allowed to call. It enforces policy on the tool side. What it doesn't touch is what the agent retrieves when it calls those tools — the documents, policies, and structured knowledge that ground the agent's actions in reality.

Walk through the sequence: an agent calls an approved tool, that tool queries an internal knowledge base, the knowledge base returns a policy document from two quarters ago. The registry cleared the tool call. The gateway logged the request. The intent monitor saw nothing unusual. The agent acted on wrong information.

Tool governance: approved. Knowledge governance: failed.

This matters more than it might look. As enterprises wire more agents to more internal systems, the quality of what those agents read becomes the operational floor. Stale knowledge doesn't just produce bad answers — it produces bad actions. An agent approving a discount that violates current pricing policy. A compliance query answered with a superseded regulation. A clinical protocol recommended that the hospital updated eight months earlier.

The tool was approved. The query was authorized. The answer was wrong.

Knowledge governance addresses a distinct problem from tool governance: not which tools agents can call, but whether the knowledge those tools retrieve is current, source-attributed, and free of internal contradictions. The two layers are not the same problem. They don't have the same solution. Treating one as sufficient for both is how production deployments fail in ways that are genuinely hard to trace.

The infrastructure requirement that's still missing

Enterprises are learning — correctly — that agent credentials and identity management are necessary but not sufficient. The MCP registry and gateway work is the right next step: govern the tools, enforce the policies, build the audit trail. This is the control plane.

But the picture is incomplete until you also govern what agents know. That means a knowledge layer with source attribution on every answer, contradiction detection across documents, automated remediation when information drifts, and an audit trail that shows not just which tool was called but what content grounded the response.

Registries answer: "Did this agent have permission to call that tool?" Governed knowledge answers: "Was what this agent read actually true?" Both questions matter in production. One is getting asked loudly at RSA. The other is mostly still background noise.

That won't hold. The enterprises that get past 5% production adoption will be the ones who realize they need both layers — a control plane for tools and a shared reality layer for knowledge. Mojar AI is the latter: a RAG platform built around the governance properties that production agentic deployments actually require.

The control plane conversation is overdue and welcome. The knowledge governance conversation is next.