COMMENTARY: AI agents are moving from novelty to infrastructure at record speed. In the race to make them more capable, developers are bolting on Model Context Protocols (MCPs) — plugins that act as connectors between agents and the APIs, tools, or execution environments they control. They’re the part of the AI stack that turns a prompt into action. That’s also where the danger lives.Pynt recent research analyzed 281 real-world MCP configurations from open agent frameworks and plugin stacks. On the surface, many looked safe. But when studied how they interacted, the risk picture changed dramatically: seemingly harmless plugins, when combined, created invisible attack surfaces capable of high-impact exploits with no human in the loop. And these aren’t theoretical “lab condition” vulnerabilities. We found agents in the wild that could be exploited by a single crafted email, Slack message, or piece of HTML scraped from the web, leading directly to silent code execution.[SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Read more Perspectives here.]
The numbers should make you uncomfortable
The research revealed that 72% of MCPs exposed powerful actions attackers could abuse, from writing to disk to executing code or calling high-permission APIs — often with no approval checkpoints. Just two MCPs, one taking untrusted input and another with privileged execution rights, raise exploit likelihood to 36%. With three MCPs, the risk jumps to 52%. Install 10 MCPs in a system and your theoretical exploitation risk hits 92%. Thirteen percent of MCPs accept attacker-controlled inputs directly from sources like Slack, email, or web scraping, and 9% combine untrusted inputs with privileged execution, meaning they can be fully exploited without zero-days, malware, or lateral movement.From APIs to execution layers
The shift from APIs to MCPs is subtle but transformative. APIs expose data and functionality. MCPs execute. They can run inside local environments with deep system access, often bypassing the layered security models that were built for web services. We’ve been here before.API sprawl led to data leakage and privilege escalation issues. Security teams learned to manage permissions, enforce authentication, and limit scopes. But MCP risk isn’t about a single endpoint’s permissions. It’s about the way multiple capabilities combine into an execution path. That’s the core of MCP compositional risk: a plugin that scrapes content, another that parses it, and a third that executes commands can form an exploit chain, even if each one on its own seems safe.Why existing defenses aren’t enough
Traditional security controls, like static analysis, permission audits, or sandboxing were never designed for the dynamic, chained nature of MCP-powered agents. Static checks can’t model runtime chain-of-events where input from one MCP becomes executable code in another.Permission reviews might approve each plugin’s scope individually but fail to detect when combinations create new privilege escalation routes. Sandboxing helps in isolation but breaks down when MCPs interact across boundaries in ways that aren’t properly segmented. An MCP ecosystem behaves more like a live, composable program than a static set of APIs. That demands a security model that can see and evaluate chains of actions in context.The reality of agent sprawl
It’s tempting to think compositional exploits are edge cases. They’re not. In real deployments, MCPs proliferate fast. Teams install plugins for everything — data ingestion, parsing, transformation, storage, execution — because they want agents that can operate autonomously. Very few teams systematically review the interplay of these components. This is exactly how “agent sprawl” happens: every new MCP adds not just its own risk, but new pathways for exploitation when combined with existing ones. By the time an AI agent has a dozen plugins, it’s less a “tool” and more a programmable backdoor waiting for the right sequence of inputs.Why this is a business problem, not just a technical one
If you think this is a niche security concern, consider the business stakes. MCP-powered agents are increasingly wired into sensitive workflows: sales automation, customer service, DevOps, even security orchestration. A breach here isn’t just about data loss, but an attacker being able to take actions in your environment with the speed, precision, and persistence of an automated system. That kind of exploit doesn’t just steal — it acts. And because many MCP attacks leave little traditional forensic trace, incidents will be harder to detect and harder to investigate. The first high-profile exploit will not be a “wake-up call” for the industry, it will be a headline-grabbing incident with real operational and reputational fallout.What must change now
Security teams need to address MCP compositional risk by design, not as an afterthought. That means:- Limit MCP exposure: Enable only the plugins and servers actively in use. Remove the rest. Every unused MCP is another potential pathway for an attacker.
- Add human-in-the-loop approvals: Use MCP host approval features to require explicit user confirmation for every high-privilege action.
- Isolate execution environments: Contain high-privilege MCPs in separate sandboxes so they can’t be chained together invisibly.
- Implement chain-aware validation: Move beyond static checks. Monitor and validate runtime execution paths across MCPs to catch dangerous compositions before they execute.
