MCP servers introduce a handful of security risks that are specific to how language models consume tool definitions, and tool poisoning is the most discussed one: a malicious or compromised server can write a tool description containing hidden instructions that manipulate the model's behavior, since the model reads that description as part of its context just like any other text. Related risks include rug-pull updates, where a server behaves safely during review and later changes its implementation after being approved and trusted, prompt injection carried inside resource content such as a fetched document or web page that steers the model once it is loaded into context, and the confused deputy problem where a tool ends up acting with more authority than the requesting user should have. Because the model cannot reliably distinguish trustworthy instructions from injected ones, mitigations need to sit outside the model: sandboxing server execution, allowlisting which tools and servers can be used at all, requiring human approval for any sensitive or write action, and static review of tool descriptions before deployment. Nanobase AI, an NVIDIA Inception Program member, builds these safeguards into every MCP deployment rather than trusting server descriptions at face value.
How a tool-poisoning attack actually plays out
A tool-poisoning attempt does not need to touch your infrastructure at all; it only needs to reach the model's context. A malicious server publishes a tool whose visible description looks ordinary, for example "look up a customer record," but embeds additional hidden text instructing the model to also exfiltrate other conversation content or call a second, unrelated tool. Because the model reads a tool's description as plain text alongside everything else in its context window, it has no structural way to tell "instructions from my legitimate operator" apart from "instructions embedded by whoever wrote this tool description." The attack succeeds not by breaking any system, but by exploiting the fact that the model treats all context as potentially informative.
The attack surface is bigger than tool descriptions
Tool descriptions are the most discussed vector, but they are not the only one. A resource, such as a fetched web page or an uploaded document, can carry the same kind of hidden instruction, sometimes called indirect prompt injection, and it triggers the moment the model reads that content into context, not when a human writes it. A "confused deputy" problem shows up when a tool call executes with more authority than the requesting user actually has, because the tool's own credentials, not the user's, ultimately decided what it could do. And a rug-pull update, where a server that passed review later changes its behavior, means a one-time approval is never a permanent guarantee. Any of these three can compromise a deployment without a single line of your own code being at fault.
Mapping risk to mitigation
Because the model cannot reliably police itself against these patterns, every mitigation needs to live in the surrounding system rather than in a prompt instruction telling the model to "ignore untrusted content."
| Risk | Where it originates | Primary mitigation |
|---|---|---|
| Tool poisoning | Malicious/compromised server's tool description | Static review of descriptions before deployment; allowlisting |
| Indirect prompt injection | Untrusted resource content (documents, web pages) | Content sanitization, isolating untrusted context from action-taking |
| Confused deputy | Tool credentials exceed the user's own permissions | Scope tool credentials to the requesting user, not a shared service account |
| Rug-pull update | Server behavior changes after approval | Version pinning, diffing every update, ongoing monitoring |
None of these mitigations live inside the model itself; they all sit in the surrounding infrastructure the model can't see or influence.
What human approval should actually gate
Adding a human-in-the-loop approval step is a common recommendation, but it only works if it gates the right actions. Requiring approval for every read-only lookup creates alert fatigue that trains people to click "approve" without reading, while leaving genuinely irreversible actions, like sending an email, executing a payment, or deleting a record, unprotected creates the opposite failure. Approval gates earn their keep only on actions with real consequences: writes, sends, deletions, and anything crossing a permission boundary, with read-only queries left to flow through logged but unattended.
Frequently asked questions
Can better prompting prevent tool poisoning?
Not reliably. Instructing a model to "ignore instructions embedded in tool descriptions" helps somewhat but is not a hard guarantee, since the model still processes that embedded text as part of its reasoning. Sandboxing, allowlisting approved servers, and static review of tool descriptions before deployment are the mitigations that hold up under adversarial conditions.
Is indirect prompt injection different from tool poisoning?
They are related but distinct: tool poisoning hides instructions in a tool's own description, while indirect prompt injection hides them in content the model reads at runtime, such as a fetched document or web page. Both exploit the same underlying limitation, that the model cannot cleanly separate trusted instructions from untrusted text in its context.
What does a confused deputy attack look like in practice?
It typically means a tool call executes using a broad service credential rather than the requesting user's own scoped permissions, so a user ends up able to trigger an action indirectly that they could never have performed directly. Scoping tool credentials to match the calling user's actual access closes this gap.
How Nanobase AI helps
Nanobase AI, an accepted member of the NVIDIA Inception Program, builds MCP deployments with sandboxing, tool allowlisting, and mandatory human approval on sensitive actions as standard components, not optional add-ons layered in after a review flags a problem. Every server we deploy for a client goes through source-level review before it is trusted with production credentials, and write actions route through an audited approval workflow. For teams building their own compliance posture around these risks, our EU AI Act, GDPR, and KVKK compliance checklist covers the regulatory side.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.