The Governance Decision Hiding Inside an Integration Decision
The Model Context Protocol (MCP), introduced by Anthropic in late 2024, has become the "de facto standard" for connecting AI agents to enterprise tools and data in just two years. That is a remarkable adoption curve. It is also a warning sign, not a green light.
Here is the fact that should anchor every decision your organization makes about MCP: standardization arrived before security scrutiny did. MCP's security weaknesses are architectural, not implementation bugs. Your organization is very likely adopting, or has already adopted, this protocol in the same sequence: deploy first, govern later.
The integration problem MCP solves is real, and the efficiency gain is genuine. But the same design choice that makes MCP powerful (letting an AI agent read natural-language descriptions of tools and decide for itself what to do) is the exact mechanism that removes predictability from your systems and opens your primary attack surface. You cannot adopt the benefit without inheriting the risk. They are the same mechanism, not two separate trade-offs to weigh independently.
Executives who treat MCP as "just another integration standard" will find, in twelve to eighteen months, that they have quietly outsourced runtime decision-making to a system that their change-management, security-review, and audit processes were never built to see.
Why MCP?
Before MCP, connecting N different AI models to M different tools and data sources required M×N custom, hand-built connectors. The more tools you add, the more convoluted it gets. MCP replaces this with a common protocol: build one connector per model, one server per system, and the two sides speak a shared language. M×N becomes M+N. That is a legitimate and valuable piece of engineering.
But the mechanism that achieves this simplification is unusual, and it's the detail every executive needs to understand: MCP tools are described to the AI in plain natural language, not in rigid, machine-checked code. Each tool is defined by a name, a written description, and an input format. The AI agent reads that description the way a person would, interprets it, and decides on its own, in real time, whether and how to use the tool.
✒ In a conventional integration, an engineer decides in advance, at design time, exactly which system calls happen and in what order. That decision is documented, testable, and reviewable. In an MCP deployment, the agent makes that decision, at runtime, based on its own interpretation of a written description. Your organization has moved a design-time decision into a runtime one without anybody signing off on that shift explicitly.
This is the trade you are actually making: integration complexity goes down, but a new and unfamiliar kind of operational unpredictability goes up. Will dive into what that unpredictability costs, and what to do about it next.
Why This Is an Architectural Shift, Not a Feature Release
Traditional enterprise software is deterministic. Ask "what will this system do when a customer submits this request?" and, with testing and code review, you can answer with confidence. That determinism is the quiet assumption underneath nearly every governance process your company runs: change management, security review, compliance audit, incident response, capacity planning. All of them assume that behavior can be predicted, and therefore controlled, in advance.
MCP breaks that assumption. Because the agent chooses its own call sequence based on how it interprets natural-language tool descriptions, the answer to "what will the system do?" becomes probabilistic, dependent on the model's current state, what's in its context window, which tools happen to be available, and how it reads descriptions that may be ambiguous or, as some security researchers have demonstrated, could be deliberately manipulated.
A second, related shift compounds this: MCP's capability surface can expand on its own. When a new server connects to your environment, the agent discovers whatever tools that server offers and can start using them without a code deployment, without a pull request, without triggering any of the change-management gates your organization relies on. The protocol's core value (dynamic, runtime discovery of new tools) is the same mechanism that lets your system's effective capabilities grow invisibly to the processes meant to govern change.
✒ This is not a defect in MCP architecture, it does exactly what it was designed to do. The problem is organizational: the governance frameworks most companies have built assume deterministic systems. Deploying MCP without redesigning those frameworks isn't a technical configuration choice. It's an unintentional architectural decision with consequences for the entire business.
There's also a subtle coupling worth flagging for anyone planning a multi-year AI strategy: because tool descriptions are natural language, the same tool can behave differently depending on which LLM is reading it. Switch model providers, upgrade a model version, or change context-window settings, and previously reliable workflows may behave unexpectedly not because you changed anything in the tool, but because the model's interpretation of the same words changed. That is a regression-testing burden with no real precedent in traditional API governance, and it means your MCP deployment is more tightly coupled to your model choice than most architecture diagrams will show.
The Hidden Operational Costs
Vendor narratives about MCP focus almost entirely on integration speed. What they leave out is that the operational burden this protocol creates doesn't scale the same friendly way the integration problem does. Complexity at the connector layer drops from M×N to M+N. But the governance complexity scales with something closer to the product of every server you connect, every tool each server exposes, how often those tool definitions change, and how many agent sessions are running concurrently. That is a much steeper curve, and it lands on security, platform engineering, and compliance teams, not on the development teams who capture the integration-speed benefit.
Four costs deserve specific budget and staffing attention:
Tool definitions require permanent, human review. Every tool description is natural-language prose that has to be checked for accuracy and hidden intent, and the protocol offers no automated way to verify that a description matches what a tool actually does. Add servers, and this review workload grows linearly, with no ceiling in sight.
Credential scope has to be re-tuned continuously, not set once. Because agent behavior is non-deterministic and evolves as models and tools change, the "right" amount of system access for any given MCP server keeps shifting. Teams tend to over-provision credentials to avoid agent failures — and that over-provisioning is already a documented real-world source of incidents, including agents running database queries nobody anticipated. Getting this right is an ongoing cycle of observe, tighten, and re-observe, not a one-time setup task.
Compliance-grade audit trails must be custom-built. MCP has no standard audit-log format. Proving, for SOC 2, HIPAA, or similar frameworks, exactly which tool was invoked, under what tool definition, on what data, requires instrumentation your team builds and maintains itself, across the host, the client, the server, and every connected system.
The specification is still moving under your feet. A forthcoming architectural shift toward a "stateless core" is a breaking change relative to how the protocol works today. The authorization model for HTTP-based connections is still in draft. Anthropic's exact long-term governance authority over the specification is not yet clearly established in public sources. Each of these is a plausible source of costly rework for anything you build today.
The Security Reality
Let's discuss concerns that should change how your board thinks about MCP risk, because it isn't about hardening a system against sloppy implementation. Five attack patterns account for most of the documented risk. None require deep technical fluency to understand at the executive level:
1. Tool poisoning is the primary vector. An attacker hides malicious instructions inside a tool's written description invisible to a human glancing at the interface but read and obeyed by the AI. Researchers call it the most prevalent and damaging attack class in MCP deployments today. Damage is bounded only by whatever access the compromised tool's credentials happen to have which, per the credential over-provisioning problem mentioned earlier, is often broader than it should be.
2. Indirect prompt injection is the pattern with the widest everyday exposure. Any workflow where an agent reads external content such as, documents, web pages, database results, emails etc., can be hijacked by instructions hidden inside that content. OWASP ranks this as the number one risk in its entire generative-AI risk taxonomy. The agent can be redirected to exfiltrate data or take unauthorized actions while every log entry looks like normal, legitimate behavior.
3. Rug pulls exploit trust itself. A server passes initial security review with clean, benign tool definitions then quietly changes them weeks or months later, once nobody is looking closely anymore. A one-time onboarding review does nothing against this; only continuous, automated monitoring of tool definitions catches it.
4. Sampling exploitation flips the usual direction of trust. MCP's "sampling" feature lets a server request completions from your AI model, not just respond to it. Researchers at Palo Alto Networks demonstrated this could be used against a widely deployed coding assistant to steal data, trigger hidden operations, and exfiltrate information; attacks that bypass controls built only for the normal agent-to-tool direction.
5. Supply chain compromise is the ecosystem-scale version of a familiar problem: a third-party MCP server, open-source or commercial, turns out to be malicious or compromised at the source, and it now sits inside your agent's context with real credentials.
Underneath all five sits a structural gap: MCP's authorization model for network-based connections is still a draft built loosely on OAuth, using "should" instead of "must" language, and locally run MCP servers have no authorization framework at all. The protocol's own maintainers acknowledge, in their official security guidance, that poorly restricted local servers can allow arbitrary code execution.
✒ None of these attacks require the attacker to break into your network in the conventional sense. They exploit the fact that your AI agent trusts written descriptions the way a person trusts a colleague's instructions. And the protocol, as designed today, gives you no cryptographic or structural way to verify that trust is warranted.What Technology Leaders Should Do
None of this argues for avoiding MCP. It argues for governing it as what it actually is: a runtime decision-making layer with an unusually porous trust boundary, not a conventional integration standard. Five actions matter most, roughly in priority order.
1. Assume MCP is already in your environment, and find out where. Given how quickly the protocol has spread through developer tools and coding assistants, the realistic starting posture is "we already have exposure we haven't inventoried," not "we're deciding whether to adopt." Run that inventory first.
2. Build continuous tool-definition monitoring — not a one-time review gate. Rug-pull attacks specifically exploit the assumption that a server vetted once stays trustworthy. Every session should diff current tool definitions against an approved baseline, flag any change, and require human re-approval before an agent trusts the new version.
3. Scope credentials as tightly as the use case allows, and revisit that scoping on a recurring cycle. Treat broad, "just in case" credential grants as a standing liability, not a convenience. Build the observe-tighten-observe cycle into a named, staffed operational function rather than leaving it to whoever set up the integration originally.
4. Put human checkpoints in front of any high-consequence action. Deletions, financial transactions, and outbound communications should never be something an agent completes autonomously end-to-end, however efficient that looks in a demo. Segment agent capabilities so a workflow that processes untrusted external content never has a path to tools that can modify internal systems.
5. Get an explicit answer on specification governance before making long-term commitments. If a single vendor can drive breaking changes to a protocol you've built core infrastructure on, that is a strategic dependency worth naming in your architecture reviews; not in a footnote.
✒ Strategic Question: Who in your organization currently owns the decision to trust a new MCP server, and does that person have visibility into changes made to that server's tools six months from now? If the honest answer is "no one," that is the gap to close first.Closing Perspective
MCP is a genuine engineering advance, and enterprises are right to be interested in it. But its central innovation letting an AI agent read a plain-language description and decide for itself what to do is not a minor implementation detail sitting beside the integration benefit. It is the integration benefit, and it is simultaneously the source of the protocol's biggest governance and security problems. There is no version of MCP that gives you the efficiency without also handing you the unpredictability and the attack surface. They arrive together.
The organizations that will get this right are the ones that treat MCP adoption as a governance decision first and an integration decision second building continuous monitoring, tight credential discipline, and human checkpoints into the deployment from day one, rather than discovering the gaps after an incident force the issue. The technology arrived quickly. The scrutiny came after. Your organization still has the chance to close that gap deliberately, on its own timeline, instead of reactively, on someone else's.
Comments
Post a Comment