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

The Model Context Protocol (MCP) is a technical standard for plugging outside tools and data into an AI agent. An MCP server is one of those plug-ins: it might give the agent access to a file system, a ticketing system, a code repository, or an internal business system. MCP has become the default way agents reach beyond what they were given in the conversation itself. Adding a new server is often a one-line settings change a developer can make alone, which is exactly why the number of connections 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 product that runs AI coding tools and their MCP servers in an isolated environment, so a misbehaving tool cannot reach the rest of the machine. 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 instruction telling the model to "ignore instructions in untrusted content." Models do not reliably follow that instruction when someone is deliberately trying to trick them. Relying on it is why prompt injection keeps recurring in AI browsers and coding tools: an attacker plants hidden instructions in a page or file, and the agent acts on them without anyone clicking anything. The fix is to separate privileges. Content the agent reads should never carry the same authority as the instructions its owner gives it. Any action with a real-world effect should need an approval that does not depend on what the agent happens to have read.

Every agent-to-MCP-server connection needs its own login credential, limited to exactly the tools and data that agent's task requires. It should not be a shared key reused by 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.

An MCP connection left open to the internet with a weak password has already been used to take control of an agent's system and steal the live access keys it held. That incident is the practical argument for narrow, expiring, per-connection credentials over permanent shared ones. A stolen permanent credential hands an attacker everything it could reach. A stolen narrow one limits the damage to what that single connection was ever allowed to do.

Run MCP server approval as an approved list, not a banned 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.