MCP Gateway
An MCP gateway is a single managed entry point that routes AI agents to many MCP servers while adding authentication, policy enforcement, access control, and audit. SealGate is an enterprise MCP gateway.
An MCP gateway is a single managed entry point in front of many MCP servers: every AI agent connects to one URL, and the gateway authenticates the connection, checks each tool call against policy, and records it before forwarding to the upstream that owns the tool. SealGate is an enterprise MCP gateway: it wraps your enabled MCP servers into one per-user endpoint and enforces policy on every call.
How an MCP gateway blocks a call
Every tools/call an agent makes clears one checkpoint before it reaches an upstream:
Classify - SealGate reads the tool's Access Control Level (PUBLIC, PRIVATE, or SECRET) and the session's running state.
Evaluate - the call is tested against the organization's CEL policy rules, which can see the tool, its arguments, and what the session has already done.
Decide - allow it, pause it for human approval, or block it.
The agent reaches this checkpoint through a per-user composite endpoint, with its API key carried as a segment of the URL path - treat that URL as a credential, since the key is per-user and revocable.
Because a rule sees session state, not just the current call, SealGate can catch a multi-step attack. It tracks three facts per session - whether the agent has read private data, seen untrusted content, and can communicate externally (the Lethal Trifecta) - so a single expression stops exfiltration:
session.has_private_data_access &&
session.has_untrusted_content_exposure &&
session.has_external_communicationWhen all three are true, the outbound call is held for a human. Access Control Levels run on the same engine - session.highest_acl_level == "SECRET" && resource.server == "email" keeps secret data off the mail server.
Every call - arguments, decision, and result - is written to an audit log for review, and CEL rules fail closed if they can't be evaluated. Your tools remain the system of record for their data; the gateway governs access to it.
Why front your MCP servers with a gateway
Point-to-point wiring works until you have several agents, several servers, and someone accountable for what they can touch. A gateway gives you one URL to manage, keeps upstream credentials server-side so they never reach the agents, and bounds the blast radius: a new or compromised server is reachable only through policy.
MCP gateway vs MCP proxy vs MCP server
These are three layers, each built on the one before it - a proxy aggregates servers, a gateway governs the proxy:
| MCP server | MCP proxy | MCP gateway | |
|---|---|---|---|
| What it is | Exposes tools over MCP | Relays and aggregates many servers into one surface | Governs access to many servers |
| Job | Do the work | Forward and aggregate | Authenticate, enforce policy, control access, audit |
| Owner | Tool author | Integrator | Platform / security team |
| Concern | Capability | Connectivity | Governance |
See the MCP proxy guide for the forwarding mechanics underneath.
FAQ
Put SealGate between your agents and your tools
One gateway that blocks the Lethal Trifecta, enforces access levels, and audits every tool call - no code changes to your agents.
Connect an Agent
Point any MCP-capable framework at your gateway URL - one URL, no header wiring.
MCP Proxy
The forwarding mechanism underneath - tool aggregation, STDIO-to-HTTP bridging, per-user composite instances.
Lethal Trifecta
The threat model behind SealGate's real-time data-exfiltration blocking.
Security
Zero-knowledge encryption, transport security, and MCP supply-chain protection.