MCP security: how to protect AI agents and their tool integrations

By Wladimir Neuberger · Updated 27 Oct 2026

What MCP is and why it is a security topic

According to its official specification, the Model Context Protocol (MCP) is an open protocol that connects AI applications to external data sources and tools. It distinguishes three roles: hosts are the AI applications that initiate connections, clients are the connectors inside the host, and servers provide context and capabilities. A server can offer resources (data), prompts (templates) and tools (functions the model may execute).

For security, the last point matters most. The specification itself says that MCP enables its capabilities through arbitrary data access and code execution paths, and that tools represent arbitrary code execution and must be treated with appropriate caution. Anyone who connects an MCP server therefore gives a third party a place inside their own agent. The OWASP GenAI Security Project’s risk list for agentic applications names this as a risk of its own: agents load tools, data or templates from third parties at runtime, and those sources may be compromised.

What the specification itself requires

The specification concedes that the protocol cannot enforce its security principles itself; applications have to implement them. The tools page and the “Security Best Practices” page include, among others:

• Human in the loop: there should always be a human who can deny tool invocations. Applications should make clear which tools are exposed to the model and ask for confirmation on calls.
• Validate inputs, control access: servers must validate all tool inputs, implement access controls, rate-limit invocations and sanitise outputs.
• Clients carry duties too: they should ask before sensitive operations, show inputs before the call to avoid data exfiltration, validate results before they reach the model, set timeouts and log usage for later audit.
• Descriptions are not trustworthy: descriptions of tool behaviour, such as annotations, are to be treated as untrusted unless they come from a trusted server.

Typical risks of tool integrations

The following risks are described in the sources. These are conceptual descriptions, not instructions.

• Manipulated tool descriptions: Invariant Labs coined the term “tool poisoning” for this. It means instructions in a tool’s description that users cannot see but the model reads. Simon Willison classes it as a form of prompt injection that can occur whenever a model uses tools and is exposed to untrusted input.
• Changes after approval: according to Invariant Labs, a server can change a tool description after the user has approved it (a “rug pull”). Willison points out that some clients do not notify users of such changes.
• Impersonation and supply chain: as an example of supply chain risk, the summary of the OWASP agentic list names a malicious MCP server that poses as a well-known email service and secretly forwards copies of all mail. Tool misuse there also includes an agent being steered to the wrong tool through a similarly named tool.
• Local servers: according to the specification, local MCP servers run with the client’s privileges. Without isolation and consent, injected startup commands can execute arbitrary code on the machine.

Even the best hardening does not remove prompt injection completely. In 2025 Willison wrote that there is no convincing fix. Plan so that a manipulated agent can only do limited damage.

Measures: our recommendation

The following list is our recommendation from building our own agents, such as the voice agent CITT with connections to calendar and CRM. It draws on the sources above but is not a collection of quotations.

• Allowlist instead of openness: only approved servers may be connected. A named person adds new servers to the register, not the agent and not every developer at will.
• Limit access: every server and tool gets only the permissions the task needs, preferably read-only. The specification recommends starting with few permissions and widening them only when needed instead of granting everything up front. OWASP advises narrow tools rather than open-ended ones such as a shell.
• Pin versions: servers and tool definitions are fixed to a vetted version. Invariant Labs recommends pinning servers and tools and checking integrity with a hash. A changed description triggers a new review.
• Confirmation for consequences: deleting, paying, sending to external parties and changing access require approval by a human, enforced in the application and not merely stated in the prompt.
• Isolation: local servers run in a sandbox with minimal privileges, for example in a container, without access to the home directory, SSH keys or other secrets.
• Logging: every call is stored with server, tool, inputs and trigger. Without this log you cannot reconstruct what the agent did after an incident.

Vetting before use

Before a server goes into a production agent, a short, repeatable check is enough. It does not replace a security test, but it keeps the obvious mistakes out.

• Origin: who operates the server, where is the source code, who maintains it? If the origin is unclear, do not connect it.
• Read the tool list: look at all names, descriptions and parameters in full, not just the short version in the interface. Descriptions that give the model instructions are a warning sign.
• Compare permissions: does the server ask for more access than its purpose needs? Then grant less or choose another server.
• Trial run: run it first with test data and without production credentials, and read the calls in the log.
• Repetition: check again at every update and at fixed intervals, because tools can change after approval.

Frequently asked questions

Sources

• Model Context Protocol — Specification (Überblick, Abschnitt „Security and Trust & Safety“)
• Model Context Protocol — Specification: Tools (Abschnitte „User Interaction Model“ und „Security Considerations“)
• Model Context Protocol — Security Best Practices (u. a. lokale Server, Token Passthrough, Scope Minimization)
• Invariant Labs — MCP Security Notification: Tool Poisoning Attacks
• Simon Willison — Model Context Protocol has prompt injection security problems (9. April 2025)
• Giskard — OWASP Top 10 for Agentic Applications 2026: Security Guide (u. a. ASI02 und ASI04)
• OWASP GenAI Security Project — LLM06:2025 Excessive Agency

This assessment rests on the publications listed. Check the original source before making decisions.

Keep reading

• Permissions and approvals for AI agents: avoiding excessive agency
• Credentials for AI agents: managing keys, tokens and identities safely
• Cyber security in the age of agents: what changes when AI acts on its own