TL;DR: Sixteen security teams asked about the Model Context Protocol between February and August 2026. The first few wanted a definition. The most recent ones already had servers running in production and wanted a control plan before the next wave. MCP governance stopped being a research question and turned into a purchase.
Sixteen. That's how many security teams raised the Model Context Protocol on my calls between February 16 and August 28, 2026.
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 a threat worth tracking. By early summer the question had moved. 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 the Model Context Protocol, 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, meaning a connection point between two systems, 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. 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 back 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. Teams wanted to know whether MCP was running anywhere in their environment at all. The recent ones are about implementation. Teams have already picked MCP, sized the rollout, and want to know which controls go in before the servers multiply.
In between there was a long stretch where MCP kept arriving by accident. A developer installed a coding assistant. The assistant shipped with MCP support turned on. Now that laptop had a path into internal systems, and nobody had filed a ticket for it.
A risk advisory firm described the volume in June 2026 as a small tsunami of MCP and agentic AI requests. Not one big program. Dozens of small ones landing 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 rather than a person, and the model decides at runtime. A gateway can authenticate a known client and limit 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. He didn't want an alert after the fact. He wanted a stop.
What belongs in an MCP control plan?
Five things, and none of them are exotic. A registry of every server. Separate credentials per server instead of one shared token. A tool allowlist for each agent. An approval gate on write actions. Logs the agent has no permission to edit.
A registry of servers. You can't govern a server nobody wrote down. Start with a list: one row per server, with an owner's name and what that server can reach.
Separate credentials per server. One shared token across every server means one compromise reaches all of them. Split the credentials and the damage stops at whichever server was hit.
A tool allowlist per agent. Give each agent the actions its actual job needs. Not the whole catalog, just because the catalog was sitting there.
An approval gate on write actions. Let reads run free. Anything that changes a record or touches production waits for a person to say yes.
Logs the agent can't edit. Write the action log somewhere the agent has no permission to reach. Otherwise your evidence lives inside the thing you're investigating.
Which team should own MCP governance?
It varies more than you'd expect, and the team that shows up first usually keeps it. That's worth planning around, because whoever claims it early sets the control model everybody else inherits.
The budget keeps moving. In some shops enterprise architecture owns it, and in others it's the GRC team that owns process. Twice it landed 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 who moves first wins by default rather than on merit.
What can you do this week?
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.
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.
Read one server's action list. Pick a server and go through what it exposes. Then ask which of those actions you'd approve if a contractor asked for them by name.
Find the shared token. If several servers authenticate with one credential, splitting that is the highest-value hour you'll spend this month.
Name the owner on purpose. Decide who owns MCP governance before the question gets settled by whoever files the first ticket.
Key takeaways:
Sixteen security teams raised MCP between February 16 and August 28, 2026, and the shape of the question changed partway through.
Early calls were about finding MCP. Recent calls are about controlling a rollout that's already been 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.
A workable control plan needs a server registry, per-server credentials, per-agent tool allowlists, an approval gate on writes, and logs the agent can't edit.
Ownership landed in several different budgets, and the first team to claim it set the control model for everyone else.
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 support by default. Endpoint inventory and outbound connection logs will surface more. The fastest path is usually just asking the people who set them up.
Does an API gateway cover MCP?
Partly. A gateway can authenticate the caller and cap 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 an approval gate on writes sitting on top of the gateway.
Who should own MCP governance?
Whoever can enforce it. Across these calls, ownership landed in several different budgets, and the deciding factor was never the org chart. It was which team could actually change the configuration without asking permission.
How does MCP relate to Zero Trust?
Zero Trust is the foundation. It verifies every request against identity and context instead of trusting anything by location. Agents add one more check on top: a single request can pass every verification while the sequence of requests around it does something nobody signed off on.
What's the smallest useful first step?
Write down every MCP server you can find, with an owner and what it reaches. A list isn't governance. Nothing else you do will work without one.
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.