Topic starter
19/08/2026 3:26 pm
TL;DR: A review of 281 MCP configurations finds that 72% expose high-privilege actions and 13% accept attacker-controlled inputs, creating compositional attack paths where a single crafted message can trigger silent code execution, according to Pynt. Traditional API security assumptions fail once MCPs become the execution layer for agents.
Editorial analysis by NHI Mgmt Group, based on content published by Pynt: “The State of MCP Security”.
By the numbers:
- 72% of MCPs allow sensitive operations such as writing to disk, executing code, or calling high-permission APIs.
- 13% of MCP plugins accept attacker-controlled inputs from sources like web scraping, Slack, or email.
- With three MCPs in a system, the chance of a silent exploit exceeds 50%.
Key questions
Q: What breaks when MCP plugins are combined without chain-aware controls?
A: The failure is not in any one plugin, but in the path between them.
Q: Why do untrusted inputs become dangerous in MCP-based agents?
A: Because the same workflow that reads external content can also trigger privileged actions.
Q: What do security teams get wrong about MCP plugin risk?
A: Teams often treat plugins as if they were ordinary extensions, when in practice they can become trust-bearing execution components.
Practitioner guidance
- Map every MCP chain end to end Document where untrusted content enters, where it is transformed, and which connector can trigger execution or privileged API calls.
- Require approval for high-risk tool calls Use host approval and contextual review for actions that write to disk, execute code, or invoke high-permission services.
- Isolate execution-capable connectors Separate parsers, scrapers, and execution tools so a single malicious input cannot traverse the full chain.
Bottom line: MCP risk emerges when untrusted inputs and privileged execution tools are combined inside the same agent workflow, not when any single plugin is viewed in isolation.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:10 pm
MCP compositional risk is a governance failure before it is a technical flaw. The article shows that the decisive weakness is not any single plugin, but the absence of chain-aware control over how plugins combine. That matters because agent programmes often inventory tools, not executable paths, and the latter is where the risk actually lives. Practitioners should treat composition as the control boundary, not the connector catalog.
A few things that frame the scale:
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: How should organisations govern approval for agent tool calls?
A: Approval should be reserved for actions that materially change state, reach privileged systems, or execute code. Teams should require contextual confirmation at the host level, then back it with execution isolation so a missed prompt does not become a full compromise.
👉 Read our full editorial: MCP compositional risk is creating silent AI execution paths