How do we govern MCP servers and other agent tool connections?

The Model Context Protocol has become the default way agents reach outside their own context window: a file system, a ticketing system, a code repository, an internal API. Adding a new one is often just a line in a config file, which is exactly why the surface area grows so fast. An agent that started with two or three connected servers can accumulate a dozen within a few months, each contributed by a different developer for a different reason, and each one a black box that decides for itself when and how to call the tools behind it.

This has become significant enough that major vendors are now building dedicated infrastructure around it. Microsoft has published formal guidance treating every MCP server as a governed dependency, requiring allowlisting and identity controls before connection. Docker has shipped a sandboxing product specifically for agentic coding tools that need to run MCP servers with some containment. Neither of those investments happens for a low-risk integration pattern. Treat MCP servers the way you would treat any other channel that grants an automated system new capabilities: reviewed before connection, scoped to least privilege, and monitored afterward.

The clearest lesson from recent incidents is architectural, not procedural. An MCP-connected review agent that read a malicious comment on a code change and then executed the instructions inside that comment was not exploited through a vulnerability. It was doing exactly what a text-prediction system does: treating plausible-looking instructions as instructions, regardless of where they came from. A support-tooling agent that ingests an external ticket, a web page fetched on the agent's behalf, or a customer email carries the same exposure any time that content reaches a model that also has tool-calling authority.

The fix is not a better prompt telling the model to "ignore instructions in untrusted content." Models do not reliably honor that instruction under adversarial pressure, and relying on it is why zero-click prompt injection against agentic browser and coding tools keeps recurring. The fix is privilege separation: the channel that supplies content the agent reads should never carry the same authority as the channel that issues the agent its instructions, and any tool call with real-world effect should require authorization that is independent of whatever currently sits in the context window.

Every agent-to-MCP-server connection needs its own credential, scoped to exactly the tools and data that server requires for that agent's task, not a shared API key reused across every agent that happens to need the same server. This mirrors AGT-009 (agent and non-human identity management) and AGT-001 (agent permission boundaries) applied specifically to the MCP layer: least privilege, a defined credential lifecycle, and access reviewed on the same cadence as human access rights.

A publicly exposed MCP bridge with weak authentication has already been used to execute arbitrary commands and steal live API keys from an agent environment in production. That incident is the practical argument for scoped, expiring, per-connection credentials over static shared ones: a compromised standing credential hands an attacker everything that credential could reach, while a compromised narrowly-scoped one limits the blast radius to what that one connection was ever allowed to do.

Run MCP server approval as an allowlist, not a block list. A new server, whether built internally or pulled from a community registry, needs a documented review before any agent connects to it: what tools does it expose, what data can it touch, does it ingest untrusted content, and who maintains it. Community-published servers deserve extra scrutiny on that last question, since ownership and code can change without the kind of notification enterprise software vendors are expected to provide.

Feed every MCP tool call into the same action-logging infrastructure that covers the rest of your agentic deployments (see AGT-006, agent action audit trail): server, action, identity, and instruction source, at minimum. Set a re-review trigger for material changes to a server's capabilities, its maintainer, or its publisher, the same way vendor change monitoring works elsewhere in your AI governance program. A server that passed intake review six months ago is not guaranteed to still deserve the access it was granted then.