The AI Agent's Plumbing Is Leaking, and Nobody Assigned a Plumber
November 12, 2026
Rodney Hall, COO— AI-assisted and reviewed prior to publication.
Model Context Protocol servers are the connective layer that lets AI agents call your tools, databases, and cloud accounts, and in 2025 and 2026 they became one of the fastest-growing sources of real vulnerabilities in enterprise environments. Securing that layer means reviewing authentication, logging, and permission scope on every MCP server before it goes near production, a job almost nobody has been formally assigned yet.
Most organizations adopted MCP the way they adopted every convenient integration standard before it: fast, with a developer plugging in a server from a public registry so an agent could read a ticketing system or push a database query. Few of those installs went through a security review, because there was no established process for reviewing them. That gap is now showing up in incident reports, CVE databases, and a federal advisory, not in theory.
What Is an MCP Server, and Why Does It Need Its Own Security Review?
An MCP server is a small piece of software that translates between an AI agent and a specific tool, exposing a defined set of actions the agent can call, such as reading a file, querying a database, or sending an email. It needs its own review because it typically runs with its own credentials and broad permissions, separate from whoever is prompting the agent that uses it.
That design choice is the root of most of the trouble. Researchers studying the protocol found that an MCP server commonly acts with its own credentials rather than the caller's, meaning a flaw in one server can expose OAuth tokens, database credentials, or cloud access that the server was trusted to hold. Treating every MCP server as a privileged service, not a lightweight plugin, is the mental shift most teams still haven't made.
The vulnerability record backs this up. A critical command injection flaw in the widely used mcp-remote package, tracked as CVE-2025-6514 with a CVSS score of 9.6, let an attacker achieve remote code execution simply by having a client connect to a malicious MCP server. Separately, security researchers disclosed exploit chains in Anthropic's own Git and filesystem MCP servers and a server-side request forgery flaw in Microsoft's MarkItDown MCP server, prompting a round of emergency patches from the protocol's own inventors. These were not obscure third-party tools. They were reference implementations published by the companies building the standard.
Who Owns MCP Server Security Right Now?
In most organizations, the honest answer is nobody, specifically. Developers install MCP servers to ship features faster, security teams often don't know the servers exist, and the shared responsibility for authentication, logging, and permission scoping falls into a gap between application security, cloud security, and whoever manages the AI tooling.
That gap is exactly what prompted the National Security Agency's Artificial Intelligence Security Center to step in. Its May 2026 advisory on MCP warned that the protocol's rapid adoption has outpaced the development of appropriate security controls, and it specifically called out weak access controls, sparse logging, and unsafe tool execution as the patterns showing up across deployments. When a national security agency writes a document with that level of specificity about a protocol that barely existed two years earlier, that is a strong signal the problem has moved past early-adopter risk and into mainstream operational risk.
The protocol's own maintainers have acknowledged the same thing from the inside. Official guidance on the specification site now walks through attack vectors specific to MCP implementations, including confused deputy problems, token passthrough, and session hijacking, that don't map cleanly onto the vulnerability categories most security teams already have playbooks for. A tool built for traditional web application security testing will miss half of what's actually exploitable in an MCP deployment.
The Credential Problem Is Bigger Than the Code Problem
Vulnerable code is only part of the exposure. The other part is what gets hardcoded into MCP configuration files and pushed to public repositories without anyone noticing until a scanner finds it.
GitGuardian's most recent secrets sprawl analysis found 24,008 unique secrets exposed in MCP-related configuration files on public GitHub in 2025, with 2,117 confirmed still valid. That is a narrow, specific category inside a much larger problem: the same research documented 28.65 million new hardcoded secrets detected on public GitHub in 2025 alone, a year-over-year jump described as the largest single-year increase GitGuardian has recorded. Every MCP server that connects an agent to a database or SaaS platform needs a credential to do its job, and right now a meaningful share of those credentials are ending up in places they were never supposed to be.
This matters operationally because an MCP server's credentials usually outlive the specific task that provisioned it. A server set up for a one-off integration test can sit in a repository with live database access for months, invisible to anyone outside the team that built it, until someone finds it the hard way.
| Risk category | What it looks like in practice | Who typically discovers it first |
|---|---|---|
| Command injection / RCE | Malicious MCP server triggers code execution on connection | Security researcher, not the deploying team |
| Credential exposure | API keys or OAuth tokens hardcoded in MCP config files | Secrets scanner, often months later |
| Unauthenticated tool calls | Server accepts requests from any caller, not just the intended agent | Incident responder, after the fact |
What the Job Actually Requires
Closing this gap is not a one-time audit. It is an ongoing operational practice that looks a lot like application security review, cloud permission management, and identity governance combined into one function that most security teams don't yet have a name for internally.
In practice, the work breaks down into a few concrete habits:
- Inventory every MCP server in use, including ones developers installed informally, and confirm the publisher and permission scope before anything connects to production data.
- Require signed or verified server artifacts, pin versions, and apply the same patch urgency to an MCP CVE that you would apply to an internet-facing service.
- Review authentication and session handling specifically, since the protocol's early design choices around sessions and tokens are a documented source of the flaws described above.
CompTIA built its SecAI+ certification around exactly this kind of work, covering securing AI systems, AI-assisted security operations, and AI governance and risk as named domains rather than an afterthought bolted onto a general security curriculum. If your team is deciding who should own this function, the CompTIA SecAI+ certification is built specifically for the person who ends up responsible for it. For a broader view of how that role fits alongside existing security functions, the curriculum overview and FAQ in Forge University's resources section walks through how AI security training maps onto a typical security team's structure. If you're the one being asked to figure this out at your organization, you can start training for it now rather than learning it in production.
Why This Won't Stay Someone Else's Problem
Agentic AI adoption is not slowing down, and every new agent deployment adds more MCP servers, each with its own credentials and permission scope. The vulnerability disclosures from mid-2025 through 2026 were not a brief early-adopter phase. They were a preview of what happens when a connective protocol spreads faster than the review process meant to govern it.
Boards and regulators are already asking pointed questions about AI governance generally. The specific, technical layer connecting agents to real systems is where those governance questions become concrete engineering decisions, decisions somebody on your team needs the standing and the skill set to make.