Wrap Controls Around MCP Before the Servers Multiply

TL;DR: Sixteen security teams asked me about the Model Context Protocol between February and August 2026. The first few wanted a definition. The most recent ones already had servers in production and wanted a control plan before the next wave. Here's the plan: a registry, split credentials, per-agent allowlists, a gate on writes, and logs the agent can't edit.

Last updated October 6, 2026. I rebuilt this piece from the ground up around the control plan, because that's what the calls are asking for now.

Sixteen. That's how many security teams raised the Model Context Protocol on my calls between February 16 and August 28, 2026, and what I keep chewing on is the order those calls arrived in. The early ones sounded like homework: somebody had read about MCP and wanted to know whether it was worth tracking. By early summer, people were describing servers they already ran. By the tenth call the shape had flipped completely: that team came in with a rollout decision already made and wanted the control design first, before anything shipped.

What is MCP, and why does it change the security question?

MCP is a standard way for an AI model to reach tools and data. One server publishes a set of actions, and any MCP-aware agent can call them. It changes the security question because the agent picks which action to call while it's running, so the list of things it can do stops being the same as the list of things it will do.

An API gets called when a person or a program decides to call it. With MCP, the deciding moves into the model. You publish forty actions and the agent chooses. That's the point of the protocol, and it's also why reviewing the action list isn't the same as reviewing the behavior. A security architect at a global manufacturer said it plainly in February 2026: his API gateway strategy wasn't a strategy, as far as he could tell. MCP didn't create that problem. It made the missing piece impossible to ignore.

What changed between the early calls and the recent ones?

The early calls were about visibility: is MCP running anywhere in our environment at all? The recent ones are about implementation: we've picked MCP and sized the rollout, so which controls go in before the servers multiply?

In between, MCP kept arriving by accident. A developer installed a coding assistant, the assistant shipped with MCP support turned on, and suddenly that laptop had a path into internal systems with no ticket filed. A risk advisory firm described the June 2026 volume as a small tsunami of MCP and agentic AI requests. Not one big program. Dozens of small ones arriving at once, from teams that didn't know about each other.

Why is MCP harder to govern than an API?

Because the caller is a model, and the model decides at runtime. A gateway can authenticate a known client and cap how fast it calls. It can't judge whether the fifty calls an agent just made add up to something a human would have refused.

A security leader at a healthcare payments network walked me through the version that keeps him up. His shop could reach hundreds of tools through one cloud provider's MCP integration. In his words: great, perfect, but you accidentally do something with agentic AI, the prompts run, it gets stuck in a loop, it deletes everything, and it's gone. He wasn't describing an attacker. He was describing an accident with production access. What he asked for was "a roadblock in the way, to prevent accidental misuse." That's his phrase, and it's the clearest control requirement I've heard for MCP. Not an alert after the fact. A stop. That stop is the same mechanism as the AI agent action gate.

What belongs in an MCP control plan?

Five things, and none of them are exotic.

Which team should own MCP governance?

It varies more than you'd expect, and the team that shows up first usually keeps it. Across these calls the budget kept moving: enterprise architecture in some shops, the GRC team in others, and twice it settled with the group that manages endpoint configuration, which I didn't see coming. None of those owners are wrong. But an endpoint team and an architecture team will design very different controls, and the one that moves first wins by default rather than on merit. Decide the owner on purpose, the same way every agent needs one accountable human.

What can you do this week?

1. Count your MCP servers twice.

   Ask the platform team, then ask the developers separately. The two numbers won't match, and the difference is most of your answer.

2. Check what came bundled.

   Coding assistants ship with MCP support. Anyone who installed one may have opened a path into internal systems without meaning to.

3. Read one server's action list.

   Go through what it exposes, then ask which of those actions you'd approve if a contractor requested them by name.

4. Find the shared token.

   If several servers authenticate with one credential, splitting that is the highest-value hour you'll spend this month.

5. Name the owner on purpose.

   Decide who owns MCP governance before the question gets settled by whoever files the first ticket.

Frequently asked questions

Is MCP a security risk by itself?

No. It's a standard for connecting models to tools, and the standard isn't the problem. Risk comes from what you connect and how tightly you scope it. An MCP server with read-only access to a wiki is low risk. One with write access to production is a different conversation.

How do I find MCP servers already running in my environment?

Ask the developers directly, then check what your coding assistants shipped with, since many enable MCP by default. Endpoint inventory and outbound connection logs surface more. The fastest path is usually just asking the people who set them up.

Does an API gateway cover MCP?

Partly. A gateway authenticates the caller and caps the rate. It can't judge whether a run of individually allowed calls adds up to an action nobody approved. You need per-agent tool scoping and a gate on writes sitting on top of it.

How does MCP relate to Zero Trust?

Zero Trust is the foundation: verify every request against identity and context instead of trusting anything by location. Agents add one more check on top, because a single request can pass every verification while the sequence around it does something nobody signed off on.

Key takeaways

• Sixteen security teams raised MCP between February and August 2026, and the question moved from "what is it" to "control the rollout we already approved."

• MCP is harder to govern than an API because the model picks the action at runtime, so an allowed sequence can still be an unapproved outcome.

• The control plan: a server registry, per-server credentials, per-agent tool allowlists, an approval gate on writes, and logs the agent can't edit.

• Ownership keeps settling with whichever team claims it first, so name the owner on purpose.

• Count your servers twice, from two different sources, and treat the difference between the counts as your real finding.

Before the next wave of servers arrives, see where your agent controls stand. The free self assessment takes about ten minutes and scores you across all five framework elements.

In February the question was what MCP even is. By August it was how to wrap controls around servers that were already live. Working backward costs more than getting there first, and working backward is now the normal case.