Your firewall has no opinion about a tool description. Your WAF cannot tell a helpful instruction from a hostile one. That is the whole problem with agent security in a sentence.
The numbers are not comfortable reading. An academic study of 1,899 MCP servers found roughly 5.5% showed signs of tool poisoning, and a separate scan of 1,808 servers reported that 66% had security issues of some kind. This is a young ecosystem with an old problem.
The Attack Classes That Actually Matter
Tool Poisoning
A malicious or compromised server embeds adversarial instructions inside its tool descriptions. The model reads those descriptions as guidance, because that is exactly what they are for. Researchers have demonstrated a poisoned server silently reading and exporting a user entire message history, with no user error and no network exploit required.
Worse, a server can change a tool definition after you approved it. Approval at install time is not approval forever.
Indirect Prompt Injection
The agent reads a document, a ticket, a web page or an email that contains instructions aimed at the agent rather than the human. The content is data, the agent treats it as a command. This remains the top-ranked LLM risk for good reason, and it is genuinely hard to solve at the model layer.
Over-Privileged Access
The dullest and most common one. The agent has a token that can do far more than the task requires, so a small compromise becomes a large one. Nobody writes a blog post about this and it causes most of the damage.
Why Your Existing Controls Miss It
The NSA Artificial Intelligence Security Center published a Cybersecurity Information Sheet on MCP security design in May 2026, and its framing is worth borrowing. Authentication, authorisation and input validation remain necessary, but agentic systems introduce genuinely new risks: dynamic tool invocation, implicit trust relationships and context sharing.
Its conclusion is blunt. These are not isolated problems that can be patched at the interface or endpoint level. The agentic environment has to be treated as a continuum, because a misaligned assumption at one stage compounds into an exploitable condition at another.
Six Defences, In Priority Order
- Least privilege, per tool. Scope credentials to the narrowest thing that works. Read-only until proven otherwise.
- Allowlist your servers. Route everything through a gateway where only registered servers are reachable. This caps blast radius more than any detection tool.
- Pin and re-review versions. Treat a tool description change like a dependency update, because that is what it is.
- Separate data zones. Align tools and models with data classification. An agent touching public docs should not share context with one touching payroll.
- Approve irreversible actions. Injection is far less dangerous when the worst outcome still needs a human to click.
- Log every tool call. MCP has no standardised audit trail yet. If you do not record it at your layer, the incident review has nothing to read.
What Improved in the Protocol
The 2026-07-28 spec tightened authorisation meaningfully. Authorisation servers should return the iss parameter per RFC 9207 and clients must validate it before redeeming a code, closing an authorisation server mix-up hole. Client credentials are now bound to the issuer that minted them, and Dynamic Client Registration is deprecated in favour of Client ID Metadata Documents.
Good progress, and none of it protects you from a tool description you never read.
Conclusion
Treat every MCP server as third-party code with a voice, because that is what it is. Allowlist what your agents can reach, scope every credential to a single job, keep a human in front of anything irreversible, and log the lot. The organisations that get burned in the next year will not be the ones running exotic architectures. They will be the ones who installed a convenient server on a Friday and never looked at it again.
Frequently Asked Questions
Can prompt injection be solved with better prompting?
No. System prompt hardening raises the bar and never closes the gap. Architectural containment is the actual answer, which means limited permissions and human approval on irreversible actions.
Are official servers from big vendors safe?
Safer, not safe. Review what permissions they request and what data they can reach. A well-run vendor with an over-broad token is still an over-broad token.
How do I audit an MCP server before installing it?
Read every tool description in full, check what credentials it asks for, confirm where it sends data, and pin the version. If you cannot see the source or the description is vague, that is your answer.