MCP security risks and how to lock down your AI integrations

The main MCP security risks are tool poisoning (hidden instructions in tool descriptions), prompt injection through content the agent reads, “rug pull” updates that change a trusted server, over-broad permissions, and local servers that run with full user privileges. The MCPTox benchmark measured an average tool-poisoning success rate of 36.5% across 20 models. Reduce risk with an approved server list, least-privilege access, approvals for actions, review of tool descriptions as code, and logging.

Why does MCP create new security risks?

MCP lets an AI model choose and call tools that act on real systems. The model decides what to do from natural-language descriptions, and it also reads content such as emails, web pages and documents that may come from anyone. That mix of instructions and data in one channel is the root of most MCP risks, as security researchers at the Cloud Security Alliance and Microsoft have described. Our beginner’s guide to MCP covers how the protocol works.

What are the main risks?

Tool poisoning: Hidden instructions in a tool’s description tell the model to do something the user did not ask for, such as reading secrets.
Prompt injection: Content the agent reads, like an email or web page, contains instructions that hijack it.
Rug pulls: A trusted server is later updated with malicious behaviour.
Tool shadowing: One server’s tools interfere with or impersonate another’s.
Over-broad permissions: A server with admin rights can do far more damage than needed.
Local execution: IDE-launched local servers can run with full user privileges and no isolation.

What has research found?

The MCPTox benchmark, published at AAAI 2026, tested 45 live MCP servers against 20 models and found tool poisoning succeeded 36.5% of the time on average. In June 2026, Microsoft’s security team showed that modified tool descriptions could make an agent collect and send out sensitive data while each action looked authorised, and its guidance treats tool descriptions as supply-chain assets needing code-level review. OWASP lists tool poisoning in its MCP Top 10. Several high-severity vulnerabilities in IDEs and MCP tooling were disclosed and patched during 2025 and 2026.

How do you lock down MCP?

Keep an approved list: Allow only vetted servers: official vendor servers, reviewed directory listings and your own.
Apply least privilege: Give each server scoped credentials for only the resources its tools need.
Require approval for actions: Confirm anything that sends, changes, deletes or pays.
Review descriptions as code: Treat tool descriptions and MCP config files as code changes needing review.
Pin versions: Avoid automatic updates; review changes before upgrading.
Isolate local servers: Run them in containers or sandboxes, not with full user rights.
Log everything: Record tool calls, inputs, outputs and the user behind them.

What about remote servers and the new spec?

Remote servers should use HTTPS, per-user OAuth and strict validation of inputs. The stateless 2026-07-28 specification hardened authorisation and moved some routing information into headers, which gateways can use for policy but which must be validated against the request body. Security teams should review those changes; see what the stateless MCP spec changed.

How do people and process help?

Train staff to recognise suspicious agent behaviour and report it
Assign an owner for each server and connector
Review the approved list quarterly
Include MCP in penetration tests and incident response plans
Keep humans approving decisions with legal, financial or customer impact

Approval design is covered in human-in-the-loop AI, and monitoring in AgentOps.

What does an attack look like?

A developer installs a free “calculator” MCP server found online. Its visible description says it adds numbers. Hidden in the same text are instructions telling the model to read the developer’s SSH key and include it in the next tool call. The developer asks a simple sum; the agent does the maths and, quietly, sends the key to the attacker’s server as a parameter. Researchers demonstrated this pattern against a popular code editor. An approved server list, isolation of local servers and review of tool descriptions would each have stopped it.

Where should you start?

No single control is enough. Combined, they turn MCP from an open door into a managed integration layer.

The wider API layer needs protection too; see API security best practices for the AI era.

For the wider picture beyond MCP, including prompt injection and data leaks, read our guide to AI security.

How UIUX Studio helps

We review MCP set-ups, build hardened servers and design approval flows that keep agents useful and safe. Talk to our product engineering and technology advisory teams.

Frequently asked questions

What is MCP tool poisoning?

Hidden instructions in a tool’s description that steer the AI model to do something harmful.

Is MCP insecure?

The protocol itself does not stop tool poisoning; security depends on how you deploy and govern it.

Should we block MCP?

No; use an approved list, least privilege, approvals and logging instead.

Are directory connectors safe?

Safer than unknown servers, but still scope permissions and review actions.

What is a rug pull?

When a trusted server is updated later with malicious behaviour.