Introduction
MCP security is now critical: seemingly harmless plugins can combine to create invisible attack surfaces that enable silent execution without human involvement.
Why it matters: MCPs (connectors between AI agents and tools or APIs) are becoming the execution layer of software, and composition can multiply risk far beyond single components.
MCP security: quick definition
MCPs link agents to tools/APIs and perform actions; MCP security assesses how untrusted inputs and privileged actions interact.
Context
The analyzed research covered 281 MCP configurations from agent frameworks and plugin stacks. It shows that combining plugins that accept untrusted input with plugins that perform privileged actions creates a hard-to-detect multiplier of risk that static checks miss.
The problem / Challenge
In real deployments a single crafted Slack message, email, or controlled web content can trigger background code execution without human review. Key findings from the study include:
- More than 7 in 10 MCP plugins expose powerful actions
- 72% of MCPs allow sensitive operations (write to disk, execute code, call high-permission APIs)
- Two MCP plugins can raise exploit risk to 36%, three push it over 50%
- Installing 10 plugins can push exploitation risk to 92%
- 13% accept attacker-controlled inputs (web scraping, Slack, email)
- 9% combine untrusted inputs with privileged execution rights enabling full exploitation without zero-days
Why composition is dangerous
One plugin can look safe; when plugins chain together—input → transformation → execution—they create programmable backdoors without lateral movement or exotic malware.
Observed real exploits
- An agent fetched remote HTML, passed it to a shell plugin and executed code automatically.
- A crafted email triggered prompt injection that, via a code interpreter, led to automatic execution.
- A Slack message executed terminal commands through a connected automation plugin.
Solution / Approach
Defenses require context-sensitive, chain-aware validation and runtime controls. Practical recommendations:
- Use MCP host approval to require user confirmation for sensitive server calls
- Limit exposure by enabling only actively used servers and tools
- Isolate execution to contain the blast radius of high-privilege actions
- Implement runtime, chain-aware validation that inspects inputs, transformations and sinks before execution
- Focus monitoring on plugin chains and external input streams (Slack, email, scraping)
Quick mitigation checklist
- Audit installed plugins and privileges
- Disable unused plugins
- Separate parsing and execution in isolated environments
- Audit flows that route external input directly to executors
Conclusion
MCP security needs a paradigm shift: treat plugins as active code with context-aware validation and execution isolation. Reducing compositional risk is achievable with host approvals, exposure limits, isolation and focused monitoring of plugin chains.
FAQ
How do I measure compositional risk in my MCP deployment?
Identify pairs/triples of plugins that accept external input and perform privileged actions; prioritize combinations with access to files, shells or sensitive APIs.
What immediate actions improve MCP security?
Enable host approval, disable unused plugins, isolate execution environments and add runtime, chain-aware validation.
Can a single plugin threaten MCP security?
Alone it may appear safe, but combined with others it can enable exploits; composition is the main risk multiplier.
Which external inputs pose the highest MCP security risk?
Sources like web scraping, email ingestion and Slack messages are high risk when processed automatically without human review.