How to Govern MCP Server Traffic With an MCP Gateway

Last updated: September 2026

An MCP gateway controls Model Context Protocol traffic in four ways. The gateway checks an admin-approved catalog of servers on every request. The gateway exposes only approved tools to each agent through profiles. The gateway stores server credentials, so the credentials never appear in client configuration. The gateway attaches a real user identity and an audit record to every tool call.

What goes wrong without an MCP gateway

Without a gateway, every developer configures every MCP server by hand, and no one can list which tools an agent used last week. Tetrate’s post on MCP without the sprawl lists the problems that appear once a company has more than a few MCP servers:

Failure	What happens
No registry	Nobody can list which servers are in use, or who added them
All-or-nothing tool access	An agent that needs two tools from a server gets every tool on the server
Login method mismatch	MCP’s OAuth 2.1 and Dynamic Client Registration do not fit how regulated identity providers work
Tool poisoning	A server’s tool metadata carries instructions the model obeys
Audit records spread across systems	N agents times M servers times K tools, with logs in none of them

The post’s test for a real registry is whether the gateway checks the registry on every request.

An MCP gateway checks an admin-approved catalog on every request

In Tetrate Agent Router Enterprise, the MCP Servers catalog in the Admin Console is where servers are approved. An operator registers each server with an endpoint URL, an auth type, and a developer-facing name and description. The gateway reads the server’s tool inventory so the operator can review every tool before developers see the server. Three auth types are supported:

Server auth type	Meaning
Open Access	No credential required by the server
Bearer Token	One shared token stored in the gateway
OAuth	Per-user delegated consent through an OAuth client the operator registers

A newly approved server appears the next time developers open the catalog. A removed server disappears at once. The catalog requires the super_admin or mcp_admin role.

MCP gateway profiles limit each agent to a chosen set of tools through one URL

An MCP profile is a named collection of MCP servers, and a chosen set of their tools, exposed through a single gateway URL. An agent connects to one URL and sees only the tools the profile allows. The MCP Gateway product page gives the example: a payments server exposes 14 tools, and the profile takes 2.

Profiles give each agent only the tools the agent needs, and profiles reduce token cost. Every tool definition an agent loads costs context tokens on every request, so fewer tools per profile means a smaller prompt. A profile can hold up to 32 tools across all of its servers. Profile security is separate from server security. A profile can require an API key, built-in OAuth, or custom OAuth. A call succeeds only when both the profile and the server settings are correct.

Agents connect the same way they connect to any MCP server. Claude Code uses the streamable HTTP transport. Cursor and VS Code use a .mcp.json entry. Microsoft Copilot Studio adds the profile URL as an MCP server with generative orchestration on. Copilot Studio supports only the Streamable transport, which Agent Router profiles use. Copilot Studio calls the MCP URL from Microsoft’s cloud, so the gateway endpoint must be reachable from there. Copilot Studio can log in with an API key in a header or with OAuth 2.0. Test the login setup in a short pilot before a rollout.

For Claude Code, tools and MCP servers in a profile work on every model family the gateway serves. The gateway converts the tool definitions for each backend. Since data plane release 0.5.1, MCP servers that need a credential keep their tools available between configuration syncs.

An MCP gateway keeps secrets out of client config and puts a real user on each tool call

Server credentials in client configuration files are the most common way MCP credentials leak. The secrets and identity guide moves credentials into a secret store. The gateway points to a HashiCorp Vault path or a cloud KMS key and looks up the secret when the tool is called. Rotating the secret in the store takes effect on the next tool call with no configuration change.

A shared bearer token means every tool call looks like the same user. With OAuth pass-through, the user consents once and the gateway exchanges the code for a per-user token. Each tool call to the target server then carries a credential scoped to that person. The gateway can also forward the user’s email, subject ID, or group in a request header. The target tool can then apply the tool’s own access rules. Because the forwarded identity depends on SSO, the gateway signs in through OIDC only.

Projects keep one team’s MCP servers away from another’s

MCP servers and profiles are scoped to a project, the same unit that keeps models and API keys separate. A project sees only the servers granted to that project. Profiles publish under the project’s own gateway hostname and are checked against the project’s keys. A call to the wrong gateway returns 404. A call with another project’s key returns 403.

The audit log records every approval and every call

Administrative changes to servers, OAuth clients, and profiles are written to the audit log, which cannot be changed. The tool-call log carries the end-user identity when pass-through is configured. Both export to a SIEM. Tetrate’s post on agent security and tool calling maps both logs to NIST guidance. Check tool calls, prevent agents from gaining more access than allowed, watch for unusual activity, and require a person to approve high-risk actions.

An MCP gateway does not inspect tool call content

Access control and content inspection are different features. The docs state where each applies:

MCP requests through a profile are not inspected by content guardrails. Governance for those requests is approval, tool selection, identity, and audit.
Guardrails run on LLM requests only. When an agent places a tool result inside an LLM request, the prompt injection guide checks that result as tool content. A model reads the result as trusted text. That check runs on the LLM request and never on the MCP call.
No MCP-specific rate limits or budgets are documented today.
The header names used to forward identity are configurable and not published in the docs.

How to evaluate an MCP gateway in a PoC

The MCP gateway evaluation scenarios in the docs give a scored test for each of the four controls above. The four tests cover profiles, catalog approval and removal, secrets and identity, and project scoping.

Now Available

MCP Catalog with verified first-party servers, profile-based configuration, and OpenInference observability are now generally available in Tetrate Agent Router Service. Start building production AI agents today with $5 free credit.

Frequently asked questions

What is an MCP gateway? An MCP gateway is a proxy between AI agents and Model Context Protocol servers. Agents connect to the gateway. The gateway decides which servers and tools each agent can reach, stores the server credentials, attaches the user’s identity, and records every call.

What is an MCP profile? A profile is a named set of MCP servers and a chosen subset of their tools, exposed through one gateway URL. An agent that connects to the profile sees only those tools.

Why not let each developer configure MCP servers directly? Direct configuration puts server credentials in local files and gives every agent every tool on a server. Direct configuration also leaves no central record of which tools were called.

Does an MCP gateway scan tool calls for sensitive data? No. MCP traffic is not inspected by content guardrails. Guardrails run on LLM requests only. A tool result is checked only when an agent places the result inside an LLM request.

How does a target tool know which user made the call? With OAuth pass-through, the gateway exchanges a per-user consent for a per-user token. With identity propagation, the gateway forwards the user’s email or subject ID in a request header.

Can Copilot Studio agents use tools through an MCP gateway? Yes. Add the gateway’s MCP profile URL as an MCP server in Copilot Studio with generative orchestration on. The profile decides which tools the agent sees. One profile can hold up to 32 tools, so split a large tool set across profiles.

Can one team’s agents reach another team’s MCP servers? No. Servers and profiles are scoped to a project. A request to another project’s gateway returns 404, and a request with the wrong project’s key returns 403.

Which login types does an MCP gateway support for servers? Agent Router supports three server auth types: Open Access, Bearer Token, and OAuth with per-user consent. Profile security is set separately and can be an API key, built-in OAuth, or custom OAuth.

How are MCP server credentials rotated? Rotate the secret in HashiCorp Vault or the cloud KMS. The gateway looks up the secret at call time, so the new value takes effect on the next tool call with no configuration change.