MCP security tracks API's playbook — we know how that ends

Application programming interfaces arrived with enormous promise — and minimal security standards. But APIs were widely adopted nonetheless, and it was only after a decade of painful breaches that API security became a real discipline. 

The AI analog of APIs is the Model Context Protocol (MCP) — and it’s following the same pattern. But a compromised MCP integration can wreak havoc faster and more broadly than any compromised API and be harder to trace.

Here’s what your security team needs to know about the risks of MCP — and how to ensure they do not expose your supply chain.

[ Download Report: AI Is the Supply Chain ]

Déjà vu all over again

An open standard that lets AI applications connect to external tools, data sources, and workflows, MCP has a compelling goal of eliminating the need for custom integrations for every AI app or model. But the security model around it leaves a lot to be desired.

The MCP specification explicitly leaves authentication, authorization, input validation, and sandboxing to whoever deploys the server. That is a defensible decision, but delegating security to implementers has been shown to be a “kick the can down the road” problem, said Dan Moore, director of customer identity and access management strategy at FusionAuth.

“MCP explicitly doesn’t enforce security at the protocol level. That’s not a criticism of the spec authors. It’s a difficult problem, and they made a deliberate choice to let implementers handle it. But in practice, ‘left to the implementer’ has historically meant ‘skipped until a breach scares everyone and forces re-evaluation.’”
—Dan Moore

In fact, the MCP ecosystem is looking like a replay of the early API era: rapid adoption, with no standard authentication or authorization patterns, with transport security treated as an afterthought, and with a collective assumption that security controls will materialize eventually.

This time the stakes are higher

But compared to APIs, the risks from MCP are hugely magnified. When a traditional API is called, the caller is deterministic: a specific application or piece of code, written by a developer, with predictable behavior that can be modeled, tested, and governed. MCP-connected agents operate differently.

With a large language model (LLM) in the loop, the caller is no longer predictable. The model autonomously selects tools and determines what actions to take. Its decisions can shift based on context, incoming prompts, or manipulated upstream data. Its behavior, therefore, is neither repeatable nor bounded in the way traditional API calls are.

Jim Wojno, Director of Product Management for Integrations at ReversingLabs (RL), said organizations are rushing to adopt Agentic AI in cybersecurity operations for all the obvious benefits. However, in that scenario AI becomes the most privileged and most manipulable component simultaneously.

“An attacker who compromises the AI layer — through MCP server tampering for example — doesn't need to touch a single endpoint. They can use the organization's own automation to suppress detections, whitelist malware, and execute commands across the environment. That's not a breach. That's a rootkit.”
—Jim Wojno

The consequences of compromise scale accordingly, said Gianpietro Cutolo, cloud threat researcher at Netskope Threat Labs.

“A compromised API leaks information. A compromised MCP integration can send emails, move money, or pivot across every other tool the agent is connected to — at machine speed, with a user’s credentials, and with a plausible audit trail.”
—Gianpietro Cutolo

Researchers at Carnegie Mellon University’s Software Engineering Institute note that MCP’s risks extend well beyond traditional confidentiality, integrity, and availability concerns. Because MCP is deeply integrated with LLMs and agentic workflows, vulnerabilities can also compromise privacy, safety, and system reliability — areas where AI-driven systems can autonomously execute high-stakes actions without human review at each step.

The attack surfaces AppSec isn’t testing for

MCP’s permissive security model creates threat categories that most application security (AppSec) programs are not designed to detect. Tool poisoning embeds malicious instructions inside tool descriptions that the model takes as authoritative input.

Rug-pull attacks allow a tool to change its definition after an initial security approval, subverting trust established at onboarding. And confused deputy attacks turn an agent’s own access privileges against the users it is supposed to serve, said Jason Soroko, senior fellow at Sectigo.

“Static [and dynamic] analysis find none of these because the exploit vector is the model’s reasoning rather than the input parser.”
—Jason Soroko

Those legacy tooling and testing methodologies can’t provide coverage because the threat surface is not in the code; it is in how the model reasons about and interacts with the tools it has been given access to. The real problem is that if AppSec teams assume that standard vulnerability testing provides the needed coverage, they will have a false sense of security.

Wojno said MCP servers are the silent trust boundary in agentic AI workflows — the LLM has no native way to distinguish a legitimate response from a poisoned one.

“Compromise the server, and you control what the AI believes is true about your environment.”
—Jim Wojno

How to start securing MCP servers

There is good news: guidance is already emerging. The Open Worldwide Application Security Project — which didn’t release an OWASP API Security Top 10 until 2019 — has published both an MCP Security Cheat Sheet and a Practical Guide for Secure MCP Server Development. And the U.S. Cybersecurity and Infrastructure Security Agency released agentic AI adoption guidance in May 2025. The question remains whether organizations will act on this guidance before a major incident gooses them.

Securing MCP starts with observability. Most organizations currently cannot reconstruct what an agent decided or why, making post-incident investigation nearly impossible. Logging every tool invocation and building a full audit trail of which agent called which tool, with what parameters and what response it received are seen as advanced practices, but they should be baseline operational requirements.

In addition, MCP servers should be treated like any third-party vendor integration: inventoried before deployment, scoped to minimum necessary permissions, and subject to a security review. Tool definitions should be pinned at approval time — hashing descriptions and schemas and alerting on drift. Execution environments should be sandboxed in containers, with restricted file system access and no outbound network unless explicitly required.

Denis Calderone, principal and CTO at Suzu Labs, likens MCP-connected agents to service accounts with judgment, and AppSec has spent 20 years building controls around service accounts, including least privilege, credential rotation, access logging, and scoped permissions. 

“Those controls exist because we learned the hard way what happens when an automated process has broad access and no oversight. Now we’ve given it an LLM and told it to make autonomous decisions about what tools to call and what data to access.”
—Denis Calderone

However, server-side hardening cannot address the client, said Ted Miracco, CEO of Approov Mobile Security, and that’s a dimension the industry has not yet fully engaged. “MCP servers are increasingly called from mobile apps and agents running on user-controlled, and possibly hostile, mobile devices,” he said.

That’s a problem that should be addressed soon to avoid going through the API learning process again, but at the speed and scale that agentic AI enables, he added.

“The industry has gotten a do-over, and we should not waste it repeating the same API follies of 2014.”
—Ted Miracco

RL's Wojno said MCP servers inherit every vulnerability in their supply chain — the SDK, the MCP framework, the build pipeline — and security mitigations like immutable containers for the MCP don't change that. They lock in whatever was built, including a compromise that happened upstream, he said. 

“The mitigations that matter are dependency pinning with hash verification, SBOM generation at build time so you can detect what changed between builds, and treating every MCP tool response as untrusted input.”
—Jim Wojno

Act now — before the breach

The window for establishing good MCP security practices is smaller than the API window was. AI compresses the timeline for damage in ways a 2014-era API ecosystem never could. The industry had years to absorb the cost of early API insecurity and build compensating controls. But an uncontrolled MCP integration can materialize in seconds, at scale, under a plausible audit trail — and with an unprecedented blast radius.

The controls, the frameworks, and the documented attack patterns are all available now. Every organization building with or deploying MCP-connected agents has the option to internalize them before the first major breach makes the lesson unavoidable, Calderone said.

He added that an MCP server requesting broad file system and database access is the AI equivalent of granting admin rights. Tool definitions should be pinned at approval time by hashing descriptions and schemas, with alerts triggered on any drift. Execution should be sandboxed, with MCP servers running in containers with restricted file system access and no outbound network unless explicitly required.

“Treat them like untrusted code execution environments because, functionally, that’s what they are.”
—Denis Calderone