Enterprise AI has a new dependency problem, and it is arriving through MCP faster than most organizations can inventory it. The Model Context Protocol is becoming the connective tissue between agents, tools, data sources, developer environments, and business applications. That makes it useful. It also makes it dangerous, because the servers carrying that traffic are executable components in an expanding software supply chain, not passive plumbing.
As a scuba diver, I quickly learned that admiring the reef can never be my top priority. The unglamorous gear, the regulator and valves and gauges checked before the descent, is what decides whether a dive stays controlled. MCP is becoming that gear for enterprise AI: essential, increasingly invisible, and too often trusted before anyone has inspected it.
The MCP servers now spreading through enterprises are not just connectors. They are an unchecked dependency graph with access to tools, data, credentials, and business workflows. Many organizations adopting them cannot reliably say where a given server came from, who wrote it, what version is running, which permissions it holds, or what it does after the connection succeeds.
Recent MCP incidents have mostly been treated as normal software defects. A flaw appears, an advisory follows, the vendor ships a fix, and everyone applies it. Consider CVE-2026-32173 in which a missing authentication check let an unauthenticated caller access data it should never have seen. A patch fixed it, but it is the reflex behind it that is the real problem. Each patch fixes one defect and leaves untouched the thing that keeps producing them.
The larger pattern is that MCP is turning agentic AI into a supply chain and runtime governance challenge. In our research library, two recent KuppingerCole Analysts Leadership Briefs explain why MCP is the API security problem nobody is ready for, and without API security there is no AI security. Both hold because MCP routes requests, mediates access to enterprise systems, and inherits the API governance failures organizations already had. But API security is necessary here, not sufficient. The supply chain dimension is the part the industry keeps importing without inspecting.
The access-control layer is finally maturing. The MCP authorization specification defines authorization for HTTP-based transports, OWASP has published an MCP Top 10, and secure transport is getting real attention. These steps help answer who is allowed to connect and what scope they hold. They do not answer the harder question: what local commands, file paths, secrets, APIs, and downstream tools an MCP server can actually reach, and whether those capabilities are fixed, reviewed, and monitored.
The Recurrence Is the Signal
Consider the STDIO transport issue documented by OX Security in April 2026. It affects environments that automatically load or invoke MCP tools from configuration files, IDE extensions, marketplaces, or agent workflows. This is not a bug. It is a systemic weakness in implementations where untrusted MCP server configurations can lead to arbitrary command execution through official SDK behavior and common client integrations.
The problem is not only that one implementation got it wrong. It is that the same risky pattern keeps moving through the MCP ecosystem, while every downstream developer is left to catch and fix it locally. Many organizations were exposed to Log4Shell in 2021 through code they did not write and systems they had not fully inventoried. MCP can create the same blind spot, with tool behavior and server code inherited before anyone has reviewed them.
Then came the Claude Code source exposure through a packaging error. Within days, fake “unlocked” Claude Code repositories were distributing the Vidar infostealer. The lesson was painfully familiar: developer trust, package distribution, local configuration, and agentic tooling collapse into one attack surface very quickly. KuppingerCole Analysts has tracked this same run of malicious and compromised MCP servers across 2025 and into 2026.
The remediation advice from experts was obvious. It was also pure software supply chain language, and the industry reached for it by instinct even while continuing to file these incidents under API security. That instinct is correct. After all, there is no patch for a server doing exactly what its definition told it to do.
What Organizations Need to Do Now
The real question is no longer whether an MCP server is authenticated. Authentication still matters. The question that matters more is whether anyone has audited what each MCP server is, where it came from, and what it is allowed to do. Treat tool definitions as software supply chain assets.
- Start with inventory. You cannot govern a dependency graph you have never enumerated. Scan for MCP and SSE endpoints, identify the servers nobody registered, and bring the shadow AI surface under control.
- Treat MCP manifests, server packages, skills, and agent configuration as production software, not convenience. Approved registries, pinned versions, validated provenance, and human review are the minimum bar before any tool definition reaches enterprise use. In practice, that means handling them like raw npm dependencies.
- Stop treating a valid token as evidence of safety. A token tells you who connected but says nothing about the code behind the connection, which is exactly the gap non-human identity governance has to close as agents multiply.
- Put CLAUDE.md files, skills, prompts, and agent configurations under the same review as an external pull request. In many environments, that is precisely what they are: instructions arriving from outside the security boundary, consumed by software that can act on them.
- Monitor what servers do after they connect. Provenance and review govern the code you accept. Runtime monitoring governs the behavior you did not predict. Treating agents as trusted digital workers means watching their tool calls and revoking access when behavior drifts, not just vetting them at onboarding.
None of this is new security work. Inventory, provenance, least privilege, change control, and runtime monitoring have existed for decades. What changed is the speed and the scale. MCP infrastructure is being assembled at vibe-coding velocity, often from unchecked open-source tools and components.
Regulation will make this harder to ignore. EU AI Act obligations around logging, transparency, human oversight, and cybersecurity increasingly reach the layers where agents invoke tools and act on enterprise data. An auditor will not be impressed by “we trusted the registry.”
Organizations that keep treating every MCP vulnerability as a one-off patch will keep patching. Those that build provenance, review, and runtime control into MCP adoption will know what they are running. One group handles incidents. The other manages risk.
