As organizations deploy MCP servers and face internal demand for their expansion, an important question has emerged: what specific governance and security considerations must be handled before further utilization of these agentic systems?
It’s the right question.
In under 18 months, MCP’s went from an Anthropic experiment to the enterprise default: 97 million monthly SDK downloads, 17,000 public servers indexed, and full use across every major AI platform. The speed is real. What hasn’t kept pace is governance: McKinsey’s 2026 AI Trust Maturity Survey found that only about one-third of organizations have reached even a basic level of maturity in agentic AI governance, and nearly two-thirds cite security and risk concerns as the top barrier to further scaling.
We have been here before
This pattern is not new. Every time a new category of privileged actor entered enterprise environments, it arrived faster than the frameworks built to control it.
Physical access controls came first. Buildings needed badge readers, key logs, and visitor registers because people walking through doors were a vector. The lesson: any actor that can reach your systems needs a defined scope, a record of what it touched, and a mechanism to revoke access.
Network perimeters came next. Firewalls and VLANs existed because uncontrolled network access was exposure the same way an unlocked door was. The same logic applied: define what can reach what, restrict by default, and log what crosses the boundary.
Then identity management and role-specific access controls for human users. RBAC was built specifically because “give users what they need and nothing more” is not a default that systems enforce on their own. Someone has to decide.
Then API keys and service accounts. When software started calling software, organizations learned that an unscoped API credential left in a configuration file is a live credential anyone who found it could use. Software needed the same least-privilege treatment people did.
The pattern across each transition is the same. Teams moved fast to prove value. Teams deferred governance because the new category came across as a software integration, not a privileged actor. The incident that forced the governance conversation came later, at a cost no one had budgeted.
MCP servers are the next transition. The organizations working through this now have a choice the earlier transitions didn’t offer: they can build the controls before the incident forces the conversation.
An MCP server isn’t a software integration. It’s an agent with keys.
An MCP server is how an agent gets its hands on your systems. When an AI agent decides to act, the MCP server carries that action out against whatever it has been given access to, whether that’s a CRM read or a customer-facing email send.
For that to work, the server needs access. That’s the design. Useful access, at enterprise scale, means broad permissions across every system your business runs on.
Meredith Whittaker, the president of Signal, put it plainly at SXSW in March 2025: agentic AI needs “something that looks like root permission, accessing every single one of those databases, probably in the clear, because there’s no model to do that encrypted.” She was warning the room.
A team spots a workflow they want to hand off to an agent. The engineers are enthusiastic. The business unit is impatient. The instinct is to connect what’s needed, prove the value, and figure out governance later.
That instinct is how organizations build governance debt they won’t see until a board meeting or audit forces the question.
Governance debt accumulates every time a team connects an MCP server without first defining what it can reach and logging what it touches. It accrues silently. It surfaces in a board conversation or an audit finding, at the moment you can least afford to find it.
You would never let a summer intern show up at a major company and have access to all data, unrestricted. You would scope their access deliberately: which systems, which data, under what conditions. An MCP server needs the same deliberate controls you’d apply to anyone new walking in the door. It is an agent in your environment, calling tools on behalf of other agents. The governance question is who’s controlling the door.
The debt compounds in three places
In every organization we walk into where MCP is deployed without governance, we find the same three failure points.
The first is access without scope. Agentic AI, by design, requires broad permissions to operate across systems. Without deliberate limits, those permissions are unbounded: the MCP server can call any tool it can reach, on behalf of any agent that asks. The LLM handling those requests sees the data too. There’s nothing controlling what it holds onto. When agents operate across applications, the encryption and access boundaries that protect each system individually become meaningless. The agent moves between them in the clear.
The second is decision quality without accountability. Even when an MCP server executes correctly, the AI reasoning behind its actions can be wrong in ways no one can trace back. An agent that confidently takes the wrong action and leaves no traceable reasoning is not a productivity tool. It is a liability. A decision that can’t be explained can’t survive a board conversation or an audit.
The third is speed without oversight. Agents operate at machine speed. The faster they move, the more quietly the human review loop disappears. No one removed it. No one required it to stay. Autonomous agents making material calls without human sign-off aren’t more efficient. They’re ungoverned.
The failure mode is specific, and it has already been documented. In 2025, Anthropic let Claude run a small automated shop in its San Francisco office for about a month, an experiment it called Project Vend.
The agent set prices, managed inventory, and handled customers over Slack, with no human signing off on its decisions. It sold items below cost. It got talked into discount codes again and again, then gave some products away for free. At one point it hallucinated a payment account and told customers to send money there. Operating at machine speed with no review step, it steadily lost money.
The incident is not a hack. It is exactly what the system was designed to do, operating without governance.
Most organizations connecting MCP servers right now haven’t addressed any of these. Gartner projects that 40% of enterprise applications will embed task-specific AI agents by the end of 2026, up from under 5% in 2025. Every month, more agents go live. The governance debt keeps accumulating.
Three decisions. Not a compliance program.
“We have identity management, role-specific access controls, and network security in place. We’re covered.” This the response we commonly hear when the question of risk is raised.
Those controls are designed for humans. However, an MCP agent represents a fundamentally different type of actor, operating across system boundaries at machine speed. It processes decisions through an LLM, which lacks awareness of business rules and access policies. Consequently, controls intended for people cannot be applied to agents without intentional redesign.
We had this exact conversation recently with a large private equity client. The different teams involved wanted to connect everything to everything, maximum agent capability, maximum speed. The governance question landed when we asked them to walk through the toolbox.
- What tools does your MCP server expose?
- All of them, or a deliberate subset?
- Who can invoke which tools, against which data, under what conditions?
- What happens when the agent makes a decision that someone needs to explain to a regulator?
The room got quiet.
Governance doesn’t require a compliance program before you ship. It requires three decisions before you connect the next MCP server.
Start with the toolbox. Not everything belongs in it. Make a deliberate list of which capabilities the MCP server can access and build a review process for adding to it. An ungoverned toolbox is an ungoverned agent.
Then scope access deliberately. Treat MCP tool access the way you’d treat any privileged role in your systems: least-privilege by default. Define who can invoke which tools, against which data. Log every call. If you can’t answer those questions for your current deployment, you don’t have a governance posture. You have a gap.
And build governance into the server at design time. The organizations that get this right require it before the first connection goes live, not after they’ve accumulated exposure they can’t explain.
None of this is new. These are the same principles you apply to any privileged access in your environment. The difference is that most teams skip them for MCP, because MCP feels more like a software integration than a privileged agent.
P.S. We create the Trusted AI Assessment, which covers the full governance scope of AI deployments, eight domains, twenty minutes.
It’s where to start if you want to know exactly where you stand before your board asks.
Sources:
- Meredith Whittaker / TechCrunch (Sarah Perez), March 7, 2025: https://techcrunch.com/2025/03/07/signal-president-meredith-whittaker-calls-out-agentic-ai-as-having-profound-security-and-privacy-issues/
- State of AI Trust in 2026: https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/tech-forward/state-of-ai-trust-in-2026-shifting-to-the-agentic-era
- MCP joins the Agentic AI Foundation: https://blog.modelcontextprotocol.io/posts/2025-12-09-mcp-joins-agentic-ai-foundation/
- Gartner enterprise agent adoption projection (via StarCIO): https://drive.starcio.com/2025/12/predictions-agentic-ai-data-governance-security-2026/
