Governing MCP servers: scope, guard, log

The Model Context Protocol (MCP) solved a real problem: a standard way for agents to discover and call tools, whether those tools wrap your CRM, your database, or a deploy pipeline. Point an agent at an MCP server and it can list the available tools and start calling them in minutes.

That speed is also the risk. MCP makes granting capability a one-line config change. An engineer adds a server, the agent inherits every tool it exposes, and suddenly your support bot can run db_execute because the database MCP server happened to expose it. No review, no scope, no record. Governing MCP isn’t about slowing this down — it’s about making the fast path the safe path.

The MCP threat model in one paragraph

An MCP server is, from the agent’s side, a bag of callable tools. Three things go wrong by default. Over-grant: the agent gets every tool the server exposes, not the two it needs. Confused deputy: a prompt injection in the data the agent reads convinces it to call a destructive tool it technically has access to. No attribution: the upstream system sees calls from a service account, not from “the support agent owned by Maya.” Governance has to close all three.

Put the server behind the plane, not in front of the agent

The architectural move is simple: the agent does not connect to the MCP server. It connects to your control plane, and the plane connects to the server. The plane re-exposes the server’s tools as a single governed surface, namespaced so nothing collides, with scope, guard, and log applied to every call.

agent → control plane → MCP server (CRM, DB, deploy, …)
          ├─ SCOPE  is `crm_read` in this agent's role?
          ├─ GUARD  args allowed? (no PII export, staging only…)
          ├─ proxy the call to the upstream MCP server
          └─ LOG    immutable record + attribution

The upstream server’s credentials live with the plane, encrypted at rest. The agent never holds them. Egress from the server is locked down. The connection is sandboxed and hostile-by-default.

Scope: tools are opt-in, per role

When you connect an MCP server, do not grant the whole catalog. Treat each tool as a capability you enable deliberately, per role:

• crm_read → on for Support, Billing, Read-only
• crm_update → on for Billing only
• crm_delete → on for nobody (Admin via approval)

Tools that aren’t granted should be invisible — filtered out of the manifest the agent receives. An agent that never sees crm_delete in its tool list can’t be talked into calling it. This is the single highest-leverage MCP control: it turns “deny” into “doesn’t exist,” which closes the prompt-injection door before it opens.

Guard: gate the arguments, not just the tool name

Scope decides whether deploy is callable. Guard decides whether this deploy is allowed. Argument-level policy is where MCP governance earns its keep:

• deploy(env="staging") → allow
• deploy(env="production") → require human approval
• db_query(sql) → allow only SELECT; block DROP, DELETE, UPDATE
• crm_export(fields=[...]) → block if fields includes PII columns

A useful default for any server is read-only until proven otherwise: every tool whose name or schema implies a write starts gated, and you open writes one at a time, on purpose.

Log: every call, attributed, streamable

Because the plane proxies the call, it logs it — tool name, arguments (with secrets redacted), verdict, and the agent-and-owner identity. Allowed and denied alike. Stream that to your SIEM and an MCP server stops being a blind spot and becomes one of the best-audited surfaces you have.

The goal isn’t to make MCP slower to adopt. It’s to make “add a server” produce a governed server by default — scoped to roles, gated on arguments, and fully logged — so the easy path and the safe path are the same path.

A practical rollout

1. Inventory. List every MCP server your agents touch and every tool each exposes. Most teams are surprised by the catalog.
2. Route through the plane. Move agents from direct connections to the plane’s governed endpoint. The agent config points at one URL.
3. Default-deny the catalog. Start every server at zero granted tools. Add back exactly what each role needs.
4. Gate the writes. For each write-capable tool, add an argument-level guard before you enable it.
5. Wire the logs. Ship the action log to your SIEM and set alerts on denials and approval requests.

Done once per server, this becomes the template every future MCP integration inherits — and “we added a tool” stops being a sentence that should worry your security team.