Enterprise MCP deployments get stuck on observability, access control, security, and credential management.
2
A gateway can provide a trusted platform for authentication, routing, secure connections, access policies, and MCP deployment.
3
A common gateway lets teams build MCP servers around business logic while keeping agent architecture separate from the data layer.
Summary
Karan Sampath argues that enterprises need shared infrastructure before they can scale MCP usage. Teams can build MCP servers quickly, but security teams struggle to review them, control access, understand usage, and protect private data. Sampath calls these problems a three-headed hydra of observability, access control, and security. His proposed answer is a gateway between MCP clients and servers. The gateway provides a root of trust, authentication, authorization, routing, secure tunnels, an internal registry, and developer tooling. New server teams can then focus on business logic instead of rebuilding those controls. Sampath also describes practical benefits such as support for multiple client surfaces, common enterprise procedures, pluggable credentials, faster iteration, and scaling across many agents. His broader design goal is to separate the agent harness from the systems and data it accesses, so enterprises can change where agents run without rebuilding their MCP connections.
Enterprise MCP usage is blocked by basic operational controls
Sampath says enterprises struggle with capabilities they consider table stakes. They need to know who is using an MCP, which tools are failing, and how teams are developing against the protocol. They also need scoped access, such as letting the whole company view observability data while limiting dashboard changes to certain people. Security adds questions about whether a server is safe, whether its tools can cause harm, and whether an untrusted remote client can reach private enterprise data. APIs have established patterns for many of these problems, but MCP deployments do not yet have comparable controls.
Registries help discovery but do not complete an enterprise deployment
MCP registries are useful for finding servers, and Sampath says Anthropic is proud to have helped develop one. A registry alone does not provide authentication, access control, observability, or credential management. That gap creates a deployment bottleneck. Teams can build servers, but security groups may be overloaded and unable to decide which ones to approve. The result is that companies remain with only a handful of MCP tools, which Sampath says will restrict the protocol and reduce what agents can do.
A trusted platform lets decentralized teams build MCP servers safely
Sampath's central recommendation is for security teams to bless one platform as a root of trust. With that platform in place, teams can develop MCP servers independently while the enterprise keeps a common control point. He says this approach has worked in Anthropic's internal and external work. Each useful MCP can benefit many agents across a company, so the value extends beyond the team that built the server. The platform gives organizations room to explore MCP usage without asking security teams to review every server through unrelated processes.
A gateway puts shared controls between every client and server
Sampath defines a gateway as a middle layer between MCP servers, potentially numbering in the hundreds, and MCP clients. It can handle authorization, authentication, observability, secure connectivity, and hosting and deployment for new servers. The gateway becomes the trusted endpoint, while individual servers route through it. A legal team could build a contract-review MCP around its own rules for redlines and escalation without also deciding who can access it, how access is measured, or how it scales. That separation lets the team focus on its business logic.
Gateway components turn enterprise policy into reusable infrastructure
The gateway design Sampath describes includes authentication, role-based access control, proxy routing, a secured tunnel, an internal MCP sub-registry, and a developer CLI. The proxy means clients see the gateway rather than every individual server, and servers can treat the gateway as their trusted endpoint. The CLI makes it easier for a team, or the coding agent helping that team, to create a server that already fits the enterprise platform. Sampath presents these as common components rather than a rigid or exhaustive specification.
One gateway supports different clients and faster team iteration
Once servers connect through one gateway, they can be used across multiple client surfaces without separate integrations for each server. Sampath also says the gateway can provide encrypted connections, common enterprise procedures, and pluggable credentials for users, teams, or service accounts. A legal team could change its MCP and iterate on its workflow without repeating security reviews for every business-logic change. The gateway also gives the enterprise a place to scale requests from dozens of servers toward much larger agent populations.
The gateway should stay stable while agent runtimes change
Sampath's broader vision separates the agent harness from the place where enterprise data lives. Agents should not be tightly coupled to a particular MCP structure or data arrangement. He describes a gateway as an investment that remains useful whether an enterprise keeps an agent in-house or uses one outside the organization. That lets the enterprise change its agent choices while preserving its connection and policy layer. The gateway also gives the company a place to define the MCP primitives and operating procedures it wants agents to follow.
"A gateway, as a black box definition of it, is simply a middleman or sort of middle layer in between your MCP servers, and they can be numerous into the hundreds, and any MCP client."06:58
Who should watch
Your teams are building MCP servers, but security reviews and approvals are stopping them from reaching users.
You need one place to manage authentication, access policies, credentials, routing, and usage across many MCP servers.
You want to change agent runtimes or deployment locations without rebuilding every connection to enterprise data.
