AI GOVERNANCE · MCP GATEWAY
One policy point for every MCP call.
Intercepts every Model Context Protocol request from your apps and agents. Same auth, allow-list and logging discipline as the rest of the Gateway.
Your apps and agents don’t talk to MCP servers directly. They call through Kosmoy. The MCP Gateway decides which servers and tools each caller is allowed to reach, logs every call, and feeds the same dossier as LLM and A2A traffic.
Combined with the MCP Server Registry, you get one inventory and one enforcement path for every MCP server in scope.
What it does.
Per-server allow-list
Apps and agents reach the MCP servers they're approved for. Nothing else.
Per-tool scope
Restrict which tools each caller can invoke on each server.
Auth + RBAC
Identity inherited from the Gateway. No tool reaches an MCP server unauthenticated.
Logging + audit
Every tool invocation captured as an event with actor, server, tool, outcome.
Internal MCP routing
Internal servers running in Capsules route through the same Gateway.
Public + private parity
Same policy model whether the MCP server is hosted by a vendor or in-house.
Module questions, answered straight.
How does the MCP Gateway differ from a model gateway?
Same policy point, different protocol. The MCP Gateway intercepts MCP server calls — tool invocations, resource reads, prompt requests — and applies the same auth, RBAC, allow-list and logging policies as the LLM Gateway.
Can it govern public MCP servers and private ones together?
Yes. Both register in the MCP Server Registry and call through the same Gateway path. Policy rules can be set per server, per tool, per app.
What happens to internal MCP servers running in a Capsule?
They're paired with a Gateway as their only egress, just like model runtimes. The MCP Gateway is what mediates traffic on the way in and out.
See the MCP Gateway in action.
Walk through allow-list enforcement, audit and internal-server routing.