{"id":26208,"date":"2026-09-21T15:15:52","date_gmt":"2026-09-21T23:15:52","guid":{"rendered":"https:\/\/www.palada.net\/index.php\/2026\/09\/21\/mcp-security-tracks-apis-playbook-we-know-how-that-ends\/"},"modified":"2026-09-21T15:15:52","modified_gmt":"2026-09-21T23:15:52","slug":"mcp-security-tracks-apis-playbook-we-know-how-that-ends","status":"publish","type":"post","link":"http:\/\/www.palada.net\/index.php\/2026\/09\/21\/mcp-security-tracks-apis-playbook-we-know-how-that-ends\/","title":{"rendered":"MCP security tracks API’s playbook \u2014 we know how that ends"},"content":{"rendered":"
\n
\n

Application programming interfaces arrived with enormous promise \u2014 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.\u00a0<\/p>\n

The AI analog of APIs is the Model Context Protocol (MCP) \u2014 and it\u2019s 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.<\/p>\n

Here\u2019s what your security team needs to know about the risks of MCP<\/a> \u2014 and how to ensure they do not expose your supply chain.<\/p>\n

[ Download Report: AI Is the Supply Chain ]<\/strong><\/p>\n

D\u00e9j\u00e0 vu all over again<\/h2>\n

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.<\/p>\n

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 \u201ckick the can down the road\u201d problem, said Dan Moore, director of customer identity and access management strategy at FusionAuth.<\/p>\n

\u201cMCP explicitly doesn\u2019t enforce security at the protocol level. That\u2019s not a criticism of the spec authors. It\u2019s a difficult problem, and they made a deliberate choice to let implementers handle it. But in practice, \u2018left to the implementer\u2019 has historically meant \u2018skipped until a breach scares everyone and forces re-evaluation.\u2019\u201d<\/em>
\u2014Dan Moore<\/a><\/p>\n

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.<\/p>\n

This time the stakes are higher<\/h2>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

\u201cAn attacker who compromises the AI layer \u2014 through MCP server tampering for example \u2014 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.\u201d<\/em>
\u2014<\/em>Jim Wojno<\/a><\/p>\n

The consequences of compromise scale accordingly, said Gianpietro Cutolo, cloud threat researcher at Netskope Threat Labs.<\/p>\n

\u201cA compromised API leaks information. A compromised MCP integration can send emails, move money, or pivot across every other tool the agent is connected to \u2014 at machine speed, with a user\u2019s credentials, and with a plausible audit trail.\u201d<\/em>
\u2014Gianpietro Cutolo<\/a><\/p>\n

Researchers at Carnegie Mellon University\u2019s Software Engineering Institute note that MCP\u2019s 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 \u2014 areas where AI-driven systems can autonomously execute high-stakes actions without human review at each step.<\/p>\n

The attack surfaces AppSec isn\u2019t testing for<\/h2>\n

MCP\u2019s 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. <\/p>\n

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

\u201cStatic [and dynamic] analysis find none of these because the exploit vector is the model\u2019s reasoning rather than the input parser.\u201d<\/em>
\u2014Jason Soroko<\/a><\/p>\n

Those legacy tooling and testing methodologies can\u2019t 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.<\/p>\n

Wojno said MCP servers are the silent trust boundary in agentic AI workflows \u2014 the LLM has no native way to distinguish a legitimate response from a poisoned one. <\/p>\n

\u201cCompromise the server, and you control what the AI believes is true about your environment.\u201d<\/em>
\u2014Jim Wojno<\/p>\n

How to start securing MCP servers<\/h2>\n

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

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.<\/p>\n

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 \u2014 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.<\/p>\n

Denis Calderone, principal and CTO at Suzu Labs, likens <\/em>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.\u00a0<\/p>\n

\u201cThose controls exist because we learned the hard way what happens when an automated process has broad access and no oversight. Now we\u2019ve given it an LLM and told it to make autonomous decisions about what tools to call and what data to access.\u201d<\/em>
\u2014Denis Calderone<\/a><\/p>\n

However, server-side hardening cannot address the client, said Ted Miracco, CEO of Approov Mobile Security, and that\u2019s a dimension the industry has not yet fully engaged. \u201cMCP servers are increasingly called from mobile apps and agents running on user-controlled, and possibly hostile, mobile devices,\u201d he said.<\/p>\n

That\u2019s 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.<\/p>\n

\u201cThe industry has gotten a do-over, and we should not waste it repeating the same API follies of 2014.\u201d<\/em>
\u2014Ted Miracco<\/p>\n

RL’s Wojno said MCP servers inherit every vulnerability in their supply chain \u2014 the SDK, the MCP framework, the build pipeline \u2014 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.\u00a0<\/p>\n

\u201cThe 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.\u201d<\/em>
\u2014Jim Wojno<\/p>\n

Act now \u2014 before the breach<\/h2>\n

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 \u2014 and with an unprecedented blast radius.<\/p>\n

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.<\/p>\n

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.<\/p>\n

\u201cTreat them like untrusted code execution environments because, functionally, that\u2019s what they are.\u201d<\/em>
\u2014Denis Calderone<\/p>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

Application programming interfaces arrived with enormous promise \u2014 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) \u2014 and it\u2019s 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\u2019s what your security team needs to know a<\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"colormag_page_container_layout":"default_layout","colormag_page_sidebar_layout":"default_layout","footnotes":""},"categories":[32775],"tags":[],"class_list":["post-26208","post","type-post","status-publish","format-standard","hentry","category-reversinglabs"],"_links":{"self":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts\/26208","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/comments?post=26208"}],"version-history":[{"count":0,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts\/26208\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/media?parent=26208"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/categories?post=26208"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/tags?post=26208"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}