The Three Blockers Stopping Enterprise MCP Adoption
Enterprises running MCPs today hit three walls. Observability is opaque: no native way to see which tools are called, by whom, or why parts of the protocol are failing. Access control is incomplete: scoping a server so all employees can view a dashboard but only certain groups can modify it isn’t possible today. Security compounds both, covering server verification, data exfiltration prevention, and safe access for untrusted remote clients.
The bottleneck lands at deployment. Teams build MCP servers, then find security teams can’t clear them fast enough. A handful of approved servers delays every agent that depends on them.
The Gateway Argument: One Blessed Platform
Security teams can’t evaluate MCPs one by one. Sampath’s answer: bless a single platform once and treat it as the root of trust for everything else. Every new MCP server connects through the gateway. Security reviews the gateway, not each server.
The practical effect: the legal team builds its own contract-review MCP without writing auth or access-control code. They define what a redline looks like and how to escalate. The gateway handles who can reach it, how often, and whether it’s scaling. That separation is what lets non-technical teams ship without a dedicated security review for each iteration.
What a Gateway Contains and What It Unlocks
A gateway has five core components: an auth layer, role-based access control, a proxy that makes the gateway the only endpoint MCP clients see, a secured tunnel for encrypted connections, an internal sub-registry, and a CLI so any coding agent can scaffold a new server.
The knock-on effects compound. Connect forty MCP servers to a gateway once and they’re all available to Claude.ai, Claude Code, or any new client without reconfiguration. The legal team iterates on its MCP without repeated security reviews.
helps all of the agents in your company.
Standard gateway primitives encode an enterprise’s expected agent behavior.
Decoupling Agent Harnesses from the Data Layer
As agent surfaces multiply, enterprises shouldn’t need to redesign their MCP infrastructure for each one. Sampath’s argument: separate the agent harness from the data layer. The gateway is the stable layer. Agents, whether in-house via the Claude Agent SDK or managed externally, connect to the same gateway.
Claude Managed Agents, released recently, is the first example. An enterprise can plug that into an existing MCP gateway, then swap in its own SDK-based agents later. The decision of which agents to run where becomes reversible. The gateway remains regardless.
Notable Quotes
helps all of the agents in your company. Karan Sampath · ▶ 6:43
are quite hard to do with MCP servers. Karan Sampath · ▶ 2:29
takeaway is to invest in common infra, Karan Sampath · ▶ 17:01
Key Takeaways
- Enterprise MCP adoption stalls on three unsolved problems: observability, access control, and security.
- A gateway centralizes auth, RBAC, and routing so individual teams can ship MCPs without repeating security reviews.
- Separating the agent harness from the MCP data layer keeps infrastructure stable as agent surfaces multiply.