Every MCP tool call, checked before it runs.
The Model Context Protocol makes it easy to hand an agent a hundred tools. The MCP gateway sits between agents and MCP servers, exposes only the tools an identity is allowed to use, validates arguments against policy, attaches credentials itself, and records each call.
MCP standardizes the connection, not the permission.
MCP defines how a client discovers and calls tools on a server. It does not define who may call which tool, with which arguments, against which data. In most setups each MCP server holds a broadly scoped credential and trusts whatever the client sends, so the effective permission of every agent is the permission of the server's service account.
The MCP gateway adds the missing layer. Agents connect to the gateway instead of directly to servers. The gateway knows the calling identity and applies the same policy engine used for data access, so a tool call is just another request: subject, resource, action, context, decision.
What the gateway does on each request.
- 1
Discover
On tools/list, the agent sees only tools its identity is scoped to. Tools it cannot use are not advertised, which also keeps them out of the model's context.
- 2
Validate
On tools/call, arguments are checked against the tool's registered schema and any policy constraints, such as allowed tables or maximum row counts.
- 3
Decide
The policy engine returns allow, deny, or require approval, considering classification of the data the tool touches.
- 4
Execute + record
The gateway calls the server with credentials it holds, returns the result, and writes the call and outcome to the audit log.
Constrain the arguments, not just the tool name.
Allowing a SQL tool is rarely the real decision. The decision is which statements, against which schemas, returning how much. Constraints are evaluated by the gateway before the server sees the call.
server: warehouse
transport: http
endpoint: http://mcp-warehouse.internal:8080
pin: sha256:9f2c…e41a # registered build only
credentials: secret://mcp/warehouse-readonly
tools:
- name: run_query
classification_source: catalog # labels from the data catalogIllustrative example · final API surface documented in /docs
What changes when MCP traffic goes through Control.
| Concern | Agent connects directly to MCP servers | Agent connects through the MCP gateway |
|---|---|---|
| Tool visibility | Every tool on every connected server | Only tools the calling identity is scoped to |
| Credentials | Held by each server, often broad, sometimes in client config | Held by the gateway, scoped per server, never sent to the model |
| Arguments | Trusted as sent | Validated against schema and policy constraints |
| High-risk calls | Executed immediately | Can require a named approver with timeout |
| Server provenance | Whatever is installed | Registered servers only; each tool enabled after review |
| Audit | Scattered across server logs, if any | One append-only record per call, with identity and decision |
What the gateway knows about every tool.
Registration is where a tool stops being an anonymous function name and becomes something policy can reason about.
Disabled until enabled
Newly registered tools start disabled. Someone has to turn each one on, which keeps a server update from silently adding capabilities.
Server status
Only tools on active servers are listed or callable. A server can be quarantined while it is investigated, which hides and refuses its tools at once.
Risk and side effects
Each tool carries a risk level and side-effect metadata, so policies can treat read-only lookups differently from tools that change state.
Required scopes
A tool can require tags, groups, or roles on the calling identity before it is even advertised to that identity.
Input schema
The registered schema describes valid arguments, giving reviewers and policy authors a stable contract to write constraints against.
Stable policy names
Clients see tools as server__tool; policy addresses them as mcp:server/tool, so rules do not change when a client renames things.
Statement classification happens in the gateway, not the model.
Database tools are the clearest example of why argument checks matter. When a tool call carries SQL in a sql, query, or statement argument, the gateway classifies it deterministically, with classes such as SELECT, DROP, DELETE_UNBOUNDED, UPDATE_UNBOUNDED, and MULTI_STATEMENT, and adds the result to the request before policy runs. A rule can then allow bounded reads while sending any DROP or unbounded DELETE to an on-call approver, regardless of how the model phrased the request.
If the arguments name a connector, the connector is evaluated as a resource too. That is how one generic execute-SQL tool can be safe against a staging database and gated against a production one: the tool is the same, but the policy outcome depends on what it would touch. Classifying multi-statement input separately closes the common trick of hiding a destructive statement behind a harmless one.
What an MCP client receives.
Outcomes are standard JSON-RPC responses, so clients and agent frameworks can handle them without special libraries.
| Outcome | Response | What the client should do |
|---|---|---|
| Allowed | The upstream server's result, returned through the gateway | Continue normally |
| Denied | JSON-RPC error -32001 with the policy IDs and reason | Stop, and surface the reason to the user or log it |
| Approval required | JSON-RPC error -32002 with the approval ID and approver groups | Report the pending approval; the identical call succeeds once after approval |
| Upstream failure | JSON-RPC error -32003 when an allowed call cannot be served | Retry or report; this is an availability problem, not a policy one |
Questions buyers ask
Do our MCP servers need to change?
Generally no. The gateway speaks MCP to both sides. Servers are registered with the gateway, and their credentials move from client configuration into the gateway's secret store.
Can we use third-party MCP servers?
Yes, if you register them. Registration pins the server build, and policies decide which identities may call which of its tools. Servers that are not registered cannot be reached through the gateway.
Does hiding tools from tools/list actually improve security?
It is defense in depth. Calls to unlisted tools are still denied at tools/call. Hiding them also keeps tool descriptions, which can themselves carry injected instructions, out of the model's context.
How does the gateway know what data a tool touches?
For tools backed by Data.co connectors, classification comes from the catalog. For other servers, you declare which resources a tool reaches, and argument constraints narrow it further.
What is the latency cost?
The policy decision is a local, deterministic evaluation inside your network with no model call involved. Actual overhead depends on your deployment, and we measure it against your environment during evaluation rather than quoting a generic figure.
Are tool arguments stored in the logs?
Decision records capture the tool, identity, decision, reason, and policy IDs, plus argument names rather than argument values. That keeps record contents and query text out of a second store while still showing what was attempted.
How should we roll the gateway out to existing agents?
Register the servers your agents already use, enable only the tools they call today, and point agents at the gateway. Review decisions for a period, then add argument constraints and approval rules where the log shows risk.
See it against your own use case.
A 30-minute technical walkthrough, policy simulation on your scenarios, and a deployment recommendation for on-prem, private cloud, or hybrid.