MCP Servers Are Production Integrations. Govern Them Like It

Last November, Anthropic open-sourced the Model Context Protocol, an open standard for connecting AI assistants to the systems where your data lives. It shipped with SDKs and pre-built servers for Google Drive, Slack, GitHub, Git, Postgres and Puppeteer.

Six months on, connecting an assistant to your repos or a database usually takes one entry in a config file. That's the point of MCP, and it's a real improvement over everyone writing their own glue code.

It also means every developer machine running an AI assistant may now have its own set of integrations, each holding credentials, running code and touching data. Most organizations have no list of them. In any other context we'd call these production integrations and treat them that way.

Agents with tools are now the default

MCP isn't the only sign of this shift. In April, Google announced A2A, an open protocol for agents to communicate and coordinate across vendors, launched with more than 50 technology partners. Google describes it as complementing MCP: MCP gives an agent tools and context, and A2A lets agents work with each other.

A week later, OpenAI released Codex CLI, an open-source coding agent that runs locally in your terminal and can read, edit and run code on your machine.

The direction is clear. Agents are getting hands, and the hands are on developer laptops and CI runners, connected to real systems.

Tool descriptions are an attack surface

On April 1, Invariant Labs published research on tool poisoning attacks against MCP. The idea is simple. A server's tool description is shown to the model, not to the user, so a malicious server can hide instructions in it. Invariant calls this a specialized form of indirect prompt injection, the same class of risk we wrote about for LLM apps in 2023.

Their demonstrations are worth reading in full:

• Exfiltration. A harmless-looking add tool told the agent to read the user's MCP config file and SSH private key and pass them out through a hidden parameter, while the agent explained the arithmetic to the user.
• Rug pulls. A server can change a tool's description after the user has approved it, so trust granted on day one doesn't protect you on day thirty.
• Shadowing. A malicious server's description changed how the agent used a different, trusted tool, redirecting email to the attacker. The malicious tool never had to be called.

The lesson isn't that MCP is broken. When you install an MCP server, you run someone else's code with your credentials, and you also hand their text to a model that will act on it. That deserves at least the scrutiny you give a new npm dependency, and probably more.

Govern MCP servers like any other integration

You don't need a new framework for this. You need the integration hygiene you already apply elsewhere, extended to a new kind of connector:

• Inventory. Know which MCP servers are in use, on which machines and in which pipelines, and who installed them.
• Approved list. Keep a short list of reviewed servers. Prefer official servers from the vendor whose system they connect to.
• Pin and verify. Pin server versions as you would any dependency. Invariant also recommends verifying tool descriptions with a hash or checksum so silent changes get caught.
• Least-privilege credentials. Give each server its own scoped token: a read-only database user, a GitHub token limited to one repo, a Slack bot restricted to specific channels. Never reuse a personal admin token.
• Keep production out of reach. Point agents at development and staging data by default. Production access should be a deliberate exception with its own approval.
• Read what the model reads. Have reviewers check full tool descriptions, not just the README, and require clients that show the complete tool input before approval.
• Isolate and log. Run servers in containers where you can, restrict their network egress, and keep a log of tool calls you can search after an incident.
• Offboard. When a person leaves or a project ends, revoke the server's tokens just as you would for any other integration.

Don't wait for the protocols to settle

MCP, A2A and the agents built on them are all young, and they're changing quickly. It's tempting to wait for the ecosystem to mature before setting policy.

We'd argue the opposite. The best time to set conventions is before every team has invented its own. An inventory and an approved list are cheap now and painful to retrofit later, once dozens of servers are wired into workflows nobody wants to break.

What we recommend

For platform and security teams, a practical first month looks like this:

• Survey developers on which AI clients and MCP servers they use today. Make it non-punitive.
• Publish an approved server list and a short request process for adding to it.
• Issue scoped, per-server credentials and rotate any personal tokens already pasted into config files.
• Add MCP config files to the paths your secret scanning covers.
• Decide, in writing, which environments agents may touch and who approves exceptions.

MCP makes connecting agents to systems easy. Keeping track of what's connected, with which credentials, and turning it off when needed is still your job.

If you'd like help building that inventory and guardrail layer, HAZL's DevOps engineers do this kind of work alongside IT teams.