June 24, 2026 · Alastor InfoSec Team
The State of MCP Security: What We're Seeing in Engagements
Model Context Protocol adoption moved faster than most organizations' security review processes could keep up with. Teams wired AI agents into internal tools, databases, and third-party services well before anyone had a mature threat model for what could go wrong. A few patterns keep showing up across engagements.
Tool-Poisoning Is the Most Common Finding
An MCP server exposes a set of tools an agent can call, and the descriptions of those tools are themselves untrusted input the moment they come from a third party. We've repeatedly found tool descriptions crafted to manipulate agent behavior — instructing the model to exfiltrate data, ignore prior instructions, or invoke other tools outside their intended purpose. The agent has no inherent way to distinguish "legitimate tool documentation" from "an instruction embedded in tool documentation."
Over-Permissioned Agents
The second most common pattern: agents connected to MCP servers with far more access than the agent's actual task requires. A support-ticket-summarizing agent with write access to a production database isn't a hypothetical — it's a configuration we've found more than once. Least privilege applies to agents exactly the way it applies to human accounts, and most teams haven't caught up to that yet.
Prompt Injection as a Privilege Escalation Path
Once an agent has tool access, prompt injection stops being a novelty and becomes a genuine escalation path — untrusted content processed by the agent (a document, an email, a webpage) can contain instructions that redirect what the agent does next, using whatever tools it has access to.
What Actually Helps
- Treating every MCP server and tool description as untrusted input, not configuration
- Scoping agent tool access to the minimum required for its specific task, reviewed the same way you'd review an IAM policy
- Testing agent behavior against adversarial tool descriptions and injected content before shipping, not after an incident
MCP Security is built around exactly these failure patterns — continuous testing of agent-to-tool boundaries, not a one-time review before launch.
Talk to our team if you're shipping MCP integrations and want a second set of adversarial eyes on them.