Your Agents Have More Permissions Than Your Employees: Governing MCP Tools at the Gateway

The MCP rollout at most companies follows a familiar arc. Week one: someone wires a coding agent to a filesystem server and it is magical. Week four: there are fifteen MCP servers — databases, internal APIs, ticketing, deploy tooling — scattered across every developer's config files. Week eight: platform engineering asks two questions nobody can answer.

Who can call which tool? And when something goes wrong, where is the audit trail?

Per-agent configuration scatters credentials across laptops and drifts policy with every git pull of someone's dotfiles. MCP's power is exactly its risk surface: a tool that can issue a refund is not a tool you want governed by convention.

The fix is to treat tool access the way you already treat model access — one permission plane, at the gateway. Four patterns get you there.

Pattern 1: One endpoint, many servers

Aggregate every external MCP server behind a single gateway endpoint. Each server is configured once — endpoint, auth header, labels, priority — and every MCP client connects to one place with one gateway key.

The immediate wins are operational. Onboarding a new server becomes a gateway configuration change rather than a pull request against every agent config in the organization. Removing a compromised or deprecated server becomes one change, not a hunt across laptops. And the inventory question — what MCP servers are actually reachable from this org? — finally has an authoritative answer, because the gateway is a chokepoint by construction.

Pattern 2: Tool-level ACLs, next to model permissions

Aggregation alone is not governance. The second pattern is where policy actually lives: per-tool access control, expressed in the same system that already decides who may call which model.

The reason to put them on the same plane is that they answer the same question — may this caller, in this context, perform this action? Splitting model policy and tool policy across two systems guarantees they drift, and the drift is invisible until an incident makes it visible.

Two properties matter in practice:

• Default deny for new tools. When a server adds a tool, it should not silently become available to everyone who can reach the server. New capability is a policy change, and policy changes should be reviewed.
• Labels, not just allow-lists. Grouping tools by sensitivity or environment lets a policy say "read-only tools in staging, no exceptions" without enumerating every tool name.

Pattern 3: Credentials stay at the gateway

The third pattern is the one security teams care about most: server credentials should be held by the gateway and never handed to the agent.

In the common per-agent setup, every developer's machine holds the database password, the ticketing API token, and the deploy key — because the agent needs them to call the tools. That is a large, constantly rotating secret surface, and it exists mostly so that a laptop can authenticate as itself to something it should not be talking to directly.

Holding credentials at the gateway inverts this. The agent authenticates to the gateway with its own identity; the gateway attaches the upstream credential. Revoking a person's access to a tool becomes an identity change rather than a coordinated secret rotation across every machine.

Pattern 4: Audit every tool call

Finally, log calls — not just model traffic, tool traffic. A tool invocation that creates, modifies, or deletes something is exactly the class of event an auditor will ask about, and reconstructing it after the fact from scattered client logs is unpleasant.

What to record is the boring part: who called, which tool, against which server, when, and with what outcome. The non-boring part is doing it in the same place as model calls, so one query answers "what did this agent do last Tuesday" instead of three.

What to do first

If you are early in the rollout, the ordering that causes the least rework is: aggregate first (it is the prerequisite for everything else), then move credentials to the gateway, then turn on tool-level policy, then wire up audit. Each step is independently useful, and none of them requires the agents to change.

The uncomfortable framing worth keeping: your agents' tool surface is an authorization boundary that arrived without an access review. Treating it like the model plane — one gateway, one policy system, one audit trail — is the only version of this that scales past the first few servers.