Once more than one team is building agents, a question arrives that nobody owns: which MCP servers exist, who is allowed to call which tool, and where is the record of what happened? Individual MCP servers can be built well and the estate can still be ungoverned.
Status: product concept, in active development. This is something we are building, not something you can buy today. We publish our roadmap because the engineering thinking behind it is the useful part — and because we would rather show you the design than imply a finished product.
The Enterprise MCP Gateway and Registry is designed as the control plane for that estate — every AI client reaching business systems through one enforced, observable path.
Designed Capabilities
- Server onboarding and discovery catalog — a single answer to what MCP servers exist and what they expose.
- User, agent and workload identity — agents get identities, not shared credentials.
- Tool-level authorization policies — permission granted per tool, not per server.
- Schema and argument validation — arguments are validated at the boundary, because a model can be manipulated into sending hostile values.
- Secret isolation and connection brokering — the agent never holds the credential.
- Rate limits and session controls — a runaway agent cannot exhaust a downstream system.
- Human approval for sensitive tools — the consequential path is gated by design.
- Health, usage and immutable audit reporting — reconstruct what any agent did, and prove it.
The Argument For a Gateway
An MCP server is a security boundary. A fleet of them, each configured by whoever built it, is a boundary with unknown gaps. Centralising identity, policy and audit is the difference between “we think our agents are constrained” and being able to demonstrate it.
This extends our MCP development practice from building good individual servers to governing many. Where an independent assessment of that boundary is wanted, our sister practice covers AI and MCP security.
Tell us if this matches a problem you have — early input shapes what we build first, and we will give you an honest view of where it stands.
When A Gateway Is Not The Right Answer
The design assumes a problem of plurality: several teams, several MCP servers, several clients calling them. If one team owns every server and every agent that reaches those servers, a gateway adds a network hop and a policy language to maintain without resolving an ownership question that does not yet exist. That team can get most of the same result by keeping authorization inside each server, writing audit records to one place, and reviewing the tool list when it changes.
A gateway also does not repair a badly designed MCP server. If a tool exposes a query interface wide enough to read anything its service account can read, centralized authorization can only decide whether an agent reaches that tool at all, not what the tool is capable of doing once reached. Narrowing the tool itself stays work in the server, and a control plane in front of a permissive estate produces a precise record of permissive behavior.
- Signs the simpler arrangement is still holding: you can name every MCP server and its owner without looking; the list of tools that write data, move money or touch customer records is short enough to review in one sitting; when someone asks what an agent did last Tuesday, you know which log to open.
- Signs it is not: nobody can state with confidence which servers exist; credentials are shared between agents because rotating them separately is work nobody scheduled; the answer to who approved a tool is the person who wrote it; two teams have built the same connector because neither knew the other had one.
Registry And Gateway Are Two Different Jobs
The registry is the system of record: which servers exist, which tools each exposes, the schema each tool accepts, who owns the server, and what state its registration is in. It is read by people deciding what an agent should be allowed to use, and by the gateway deciding whether a call matches something registered. A registry that nothing enforces degrades into a wiki, and a wiki drifts from reality the first week nobody updates it.
The gateway is the enforced path: identity is resolved, policy is evaluated for the specific tool being called, arguments are checked against the registered schema, the downstream credential is attached at the boundary, and the call and its outcome are recorded. Because it sits in the request path, its availability and latency are properties of every agent that depends on it. The two are treated as separate concerns for that reason. The registry can be consistent and slow; the gateway has to be fast and available; and a registry being down should not mean no agent can call anything.
Discovery is the seam between them. An agent asking which tools it may use is answered from registry content filtered by that agent's identity and policy, so an agent is not told about tools it cannot call. That makes registration part of deploying a server rather than paperwork that follows it: an unregistered server has no schema to validate against and no owner to route an approval to. It also means a server that ships a changed tool without re-registering fails validation at the boundary rather than quietly passing new arguments through.
What Has To Exist On Your Side
An identity system that can issue and verify identities for workloads, not only for people. The design maps onto what you already run for single sign on and service authentication rather than standing up a parallel directory. If agents currently authenticate to downstream systems with a shared API key sitting in an environment variable, that is the piece that has to change first, and it is a change in the downstream systems as much as in the agents.
A network position where the gateway can actually sit in front of the servers. If a client can still reach an MCP server directly, the enforced path is optional, and an optional control plane records only the traffic that chose to be recorded. That means network policy or service mesh rules that close the direct route, plus rotation of the downstream credentials so the old route stops working even where it is still reachable.
The rest is decisions rather than technology. Someone has to own each registered server. Someone has to say which job functions map to which tools, which tools are held for a human and who that human is, whether argument values are redacted in audit records, and how long those records are kept. The design can express all of these; it cannot choose them, and this deciding is expected to take longer than any installation step.
Failure Modes The Design Has To Account For
Sitting in the request path makes availability a design question rather than an operations afterthought. If the gateway is unreachable, every agent that depends on it stops. The posture therefore has to be set per class of tool: a read-only reporting tool might be allowed through a degraded path on cached policy, while a tool that writes to a financial system should fail closed and stay closed. Caching narrows the window in which the question is asked; it does not remove the question.
Argument validation produces false rejections before it produces clean protection. A schema written from a tool's happy path will reject legitimate calls the first time real agents exercise it, and an agent that gets a rejection it does not understand will often retry with something worse. Validation is designed to run in report mode first, recording how each call would have been decided, so schemas and policies are corrected against real traffic before anything is blocked.
Audit that nobody reads is storage. Immutable records answer the after-the-fact question, which matters, but the more frequent need is noticing that an agent's call pattern changed, that a tool nobody approved started receiving traffic, or that a workload identity is being presented from somewhere it has never been presented from before. Deciding what deserves an alert, and who receives it, is part of the work rather than a setting that ships with a sensible default.
Frequently Asked Questions
What is the Enterprise MCP Gateway and Registry, concretely?
It is two components that work together: a registry that records which MCP servers exist, what tools they expose, the schemas those tools accept and who owns them, and a gateway that agent traffic passes through so identity, per tool authorization, argument validation, credential brokering and audit happen in one place. It is not itself an MCP server, and it does not replace the servers you have. It is also not an agent framework, a model host, or a prompt-level guardrail; it governs the connection between an AI client and a business system and has no opinion about which model is on the other end of it.
Can we install it now, and is there a release date?
No. It is in active development, there is no version to buy, download or deploy, and we are not naming a date we cannot hold. If you need governance over MCP traffic in the near term, the work that exists today is building or hardening individual MCP servers and defining the boundaries around them, which is separate from this product.
What is it designed to run on, and what has to already be in place?
It is designed to run where your MCP servers and agent clients already run: a container platform or virtual machine estate you control, on premises or in your own cloud account, with the gateway inside your network boundary rather than in front of it. It depends on three things existing: an identity provider that can issue tokens for workloads as well as users, a secret store the gateway can read downstream credentials from, and somewhere to send logs and audit records. It is not designed to require a particular model vendor, agent framework or MCP client library, because the point of putting it at the protocol boundary is that those can differ per team.
How is rollout designed to proceed, step by step?
In this order: register the servers and tools that already exist, with owners and schemas, so the catalog reflects reality rather than intention; issue identities to the agents and workloads that call them; put the gateway in the path in report mode, where calls are evaluated and recorded but nothing is blocked; correct the schemas and policies against what the recording shows; then enforce, starting with read-only tools and moving toward the ones that write or spend. Direct network paths to the servers are closed and downstream credentials rotated only after enforcement holds, because until that point the old route is your rollback. The order matters more than the pace, and the report-mode stage is designed to be where surprises surface before anything is enforced.
How is it meant to integrate with the systems we already run?
Through the interfaces those systems already expose rather than through replacements for them: identity from your existing provider using standard tokens, downstream secrets read from the vault you already operate, audit and usage records shipped to the log pipeline or SIEM your security team already watches, and human approvals routed into the chat or ticketing tool people are already in rather than a separate console nobody opens. Registration is designed to be an API call, so a server's registry entry can be produced by the same pipeline that deploys the server and updated when its tools change. The design assumes it has to fit into an existing estate, because a control plane that requires replacing your identity or logging stack will not be adopted.
Does our data or traffic leave our environment, and who holds the credentials?
It is designed so that it does not. The gateway runs inside your boundary, tool arguments and results pass through it, and the audit records are written to storage you own and control retention on. Credential brokering means downstream secrets stay in your secret store and are attached to the call at the boundary, so the agent never holds them and a compromised agent cannot exfiltrate a credential it never had. This is a description of the intended design, not a description of a running service.
How is this different from putting our existing API gateway in front of the MCP servers?
An API gateway can terminate TLS, rate limit and authenticate at the HTTP layer, and if that is all you need, use the one you already operate. The difference is resolution: an MCP call carries a tool name and a structured argument object, and the authorization and validation that matter here are per tool and per argument, which a general purpose gateway cannot see without being taught the protocol. The registry has no API gateway equivalent at all, since schema of record, ownership and identity-filtered discovery are not things an HTTP proxy tracks. If your estate is one server behind one gateway, the general purpose product is the smaller thing to maintain.
What do we have to decide ourselves?
The decision nobody can make for you is failure posture: what should happen, per class of tool, when the gateway is unreachable or a policy cannot be evaluated. Failing closed stops work and is the right answer for anything consequential; failing open keeps work moving and records it but does not constrain it, which may be acceptable for read-only tools and is not acceptable everywhere. The other decisions the design can express but cannot choose, covering ownership, permissions, approvals and audit retention, are set out in the section above.