MCP gateways give compliance teams a record of what agents did

Model Context Protocol (MCP) gateways are becoming a useful piece of infrastructure for more than one job. Platform teams adopt them to get tools into agents' hands, and security teams adopt them to block bad calls inline. This post covers the third job, governance. A gateway sits on the path of every sanctioned tool call, so it is the one place that can show a compliance team how agents are handling data, enforce role-based permissions on each call, make the sanctioned path easier than the shadow one, and write an audit log of tool use. It also has hard limits, and we cover those too. For the definition and the full architecture, see what is an MCP gateway.

For agent governance, the MCP gateway is where the evidence comes from. Policies, frameworks, and access reviews describe what agents should do. The gateway is the component that records what they did, under whose name, against which system, and whether the call was allowed.

Don't we already have logs for this?

Most organizations rolling out agents already run several systems that produce logs, and the case against adding another is reasonable. The identity provider logs every sign-in. EDR watches the laptop. SaaS applications keep their own audit trails. The AI vendors ship compliance exports: the Claude Compliance API and the OpenAI Compliance Platform both expose activity feeds on their enterprise tiers. A compliance lead can fairly ask what a gateway records that this stack misses.

The answer is the tool call itself, tied to a person. The identity provider sees the login and never sees the tool call that follows. The downstream API logs the call under whatever credential the MCP server holds, which is often one shared service account for every user. The vendor compliance feeds cover conversations in that vendor's product, and coverage is uneven: Cursor's audit log carries administrative and usage metadata but not agent responses, and GitHub Copilot's excludes the prompts a user sends locally. We track the details in what is agent compliance.

Do the arithmetic on answering one audit question without a gateway. "Which agents read customer records last Tuesday, and on whose behalf?" With three coding agents in use and twenty MCP servers behind them, the evidence lives in up to sixty combinations of client and server, each with its own log format and its own idea of who the caller was. Most of those combinations won't name a directory user at all. A gateway reduces that to one query against one log, for the traffic that passes through it.

What a detailed view of agent data handling looks like

An MCP gateway terminates the connection from the agent and opens the connection to the MCP server, so it holds both halves of every call it proxies. That position lets it record, per call, the person the session resolves to, the client that made the call (Claude Code, Cursor, Codex), the server, the tool, the arguments, the response, and the outcome. For a compliance team, that combination is the difference between "our agents have access to the CRM" and "this person's Cursor session called search_contacts forty times on Tuesday and was denied once on export_contacts."

Agents handle data differently from the applications they replace. A person clicking through a CRM sees one record at a time. An agent can read hundreds of records in a loop, summarize them, and pass the summary to another tool, all inside one session the person approved with a single prompt. A data-handling review that stops at "who has access" misses that shape. The per-call record shows which data left which system, in which session, and where it went next.

Compliance teams also need the gateway's own configuration history. When an assessor asks why a role could call a write tool in March, the answer is in the administrative log: who changed the grant, when, and what it was before. A gateway that logs tool calls but not policy changes gives you half the evidence.

Role-based permissions belong on the tool call

Login-time access control was built for people clicking through applications, where the application limits what a user can do. An agent's session says nothing about what it will do next, and its instructions can come from content it reads mid-task. So the permission check has to happen on each tool call, against the roles of the person driving the agent. Agent access management covers the full model; the gateway's part of it is enforcement.

In practice, role-based permissions at the gateway work in three layers. The coarse layer is which servers a role can connect to, so the HR assistant and the production database can sit in the same registry without the same audience. The finer layer is which tools inside each server a role can call, which is where "read-only for everyone, write for the team that owns the system" becomes an enforceable default. The third layer is keeping those roles in the identity provider rather than in the gateway, synced over SCIM, so that offboarding a person in Okta or Entra revokes their next tool call without anyone touching the gateway.

That third layer is where many gateways fall short of what a compliance review expects. A gateway that authenticates callers with its own API keys or virtual keys enforces permissions, but the principal is a record inside the gateway, and the directory's access review never sees it. Every grant then lives in two systems that drift apart. Ask any vendor what the principal is on each tool call, and whether revoking the person in the directory revokes it.

A sanctioned path is how shadow AI shrinks

Shadow AI is the broad category: models used through personal accounts, coding agents installed with their own settings, skills loaded out of band, and MCP servers nobody reviewed. Shadow MCP is the tool-server slice of that problem, cataloged as MCP09 in the OWASP MCP Top 10. A gateway helps with shadow MCP directly and with the rest of shadow AI only indirectly.

The direct help is supply. Most shadow MCP is not malicious. Someone needed a capability the approved catalog didn't have, found a server on GitHub, and pasted it into a config file. A gateway with a curated catalog, one URL to connect to, and a request-access flow gives that person a faster route than the workaround. Buyers we talk to describe the goal as an enterprise-sanctioned catalog they can inventory, with shadow servers surfaced into an approval queue rather than banned on sight, because bans send usage further underground.

The limit is that a gateway only knows about the servers registered with it. A developer who points Claude Code at an unregistered server bypasses the gateway entirely, and no amount of gateway logging will show it. Finding that traffic takes a presence outside the gateway: hooks inside the coding agent, a device agent, or MDM-delivered configuration. So the gateway is half of a shadow AI program. It makes the sanctioned path worth using and records everything on it, and a separate discovery signal covers what never arrives. The MCP inventory is where findings from both halves land.

What a tool-use audit log should contain

Every gateway logs something. The questions a compliance team should ask are about what each entry names and where the log can go. A useful audit log of tool use records, for every call:

• The directory user. The person the session resolves to in the identity provider, or the named owner of an agent identity. A gateway-local key ID is not enough.
• The client. Which agent made the call, so a policy question about Cursor can be answered separately from one about Claude Code.
• The server and tool. Including whether the server was sanctioned, tunneled from a private network, or observed as shadow MCP.
• The outcome. Success, error, or blocked, and for blocked calls, the policy that decided it.
• The inputs and outputs, when policy allows. Arguments and responses are what make a data-handling review possible, and they are also the most sensitive thing in the log.
• A trace ID. So one tool call can be followed through the rest of the session and correlated with logs from the downstream system.

The log also has to reach the SIEM or data lake the security team already runs, over a standard like OpenTelemetry (OTLP), without a support ticket. A GRC platform can then ingest that record as evidence. GRC tools such as Vanta and Drata monitor configuration out of band; the gateway log shows what was enforced at runtime.

Logging tool inputs and outputs has a cost, and it is easy to skip in a vendor evaluation. A log that captures every argument and response holds copies of the customer records, source code, and tickets that agents touched. That log now has its own retention, access, and residency obligations, and in some programs it becomes the most sensitive data store in scope. Check whether the gateway can disable input and output capture per server, restrict who can read captured payloads, and set a retention period that matches your policy.

What a gateway won't do for a compliance program

A gateway doesn't make an organization compliant with anything. Frameworks such as ISO 42001 or the EU AI Act describe a management process; the gateway is one runtime control inside it, and an assessor will still want the policies, the risk assessment, and the ownership model that sit above it. Agent governance lists four controls: inventory, identity, per-call access, and audit. The gateway carries two of them well, contributes to the inventory, and depends on the identity provider for identity.

It also governs only what routes through it. Agents that call APIs directly with an embedded key, background agents running in a vendor's cloud, and model traffic that never touches a tool are outside its view. The practical test in an evaluation is to point an agent at something unregistered and see whether anything notices.

The same gateway usually does the other two jobs as well. The enablement job, getting tools and authentication in front of agents, is what gets it deployed in the first place, and the security job, inspecting calls for injection or exfiltration, is what the security team asks for next. Which MCP gateway architecture do I need covers how to pick a deployment shape, and the best MCP gateways for enterprise in 2026 scores eleven products on both enablement and governance.

MCP gateways with governance features

A short list of where to look, not a ranking. The enterprise roundup linked above has the detailed comparison.

Speakeasy. Speakeasy ships its MCP gateway as one part of the AI Control Plane. Roles scope access per server and per tool and sync from Okta or Entra over SCIM. The Tool Logs view records the user, agent, server, tool, and status of every call it observes, including calls to shadow MCP servers seen by agent hooks, and an administrative audit log records policy changes. Shadow MCP detection adds allow and deny rules and a request-access flow, and telemetry exports over OTLP.

Microsoft MCP Gateway and Azure API Center. Microsoft MCP Gateway is an open-source reverse proxy and management layer for MCP servers on Kubernetes, with session-aware routing and bearer-token authentication with RBAC on its data and control planes. It is routing infrastructure and leaves identity mapping and tool-level policy to the layers around it. Azure API Center is a separate product that maintains an inventory of remote and local MCP servers and exposes an MCP registry endpoint that VS Code and GitHub Copilot can use for discovery. One routes traffic; the other records what exists.

IBM ContextForge. ContextForge is IBM's open-source registry and proxy that federates MCP servers, A2A agents, and REST and gRPC APIs behind one endpoint. For governance, the relevant pieces are the unified tool registry, an admin UI with a filterable log viewer and export, and OpenTelemetry tracing to OTLP backends. As with any self-hosted open-source gateway, directory integration and retention policy are yours to build.

Other commercial options include MintMCP, Runlayer, Willow (formerly Webrix), Kong's AI MCP Proxy, TrueFoundry, Bifrost, Docker MCP Gateway, and AWS AgentCore Gateway.

Where to start

If you are standing up governance for agents now, start with the audit question you most expect to be asked, and check whether any system you run today can answer it with a directory user's name attached. If none can, that is the gap a gateway fills. We'd be interested to hear which question it was, and if you want to compare notes on the rollout, we'd like to talk.