MCP Tool Poisoning: Runtime Defense for AI Agents

The short version

MCP gives agents a standard way to discover and use tools. That discovery layer includes model-facing text: tool names, descriptions, schemas, prompts, metadata, and returned content. Tool poisoning abuses that channel by hiding instructions where the model may see them but the user may not.

The public research around Invariant MCP-Scan made this class of issue visible, and OWASP now documents MCP tool poisoning as an indirect prompt-injection attack. Scanners are the first gate. Runtime checks are the second gate because poisoned instructions can still arrive through changed tools, dynamic results, or real data the scanner never saw.

What gets poisoned?

A user sees a tool called "search docs" or "create issue." The model sees more: descriptions, argument schemas, examples, hidden metadata, and sometimes tool-provided prompts. Any of that model-facing surface can attempt to influence tool selection or downstream behavior.

Tool descriptions: text that makes one tool look preferred, safer, or mandatory.
Schemas: argument hints that steer the model toward unexpected fields or values.
Tool results: returned documents or API payloads that include instruction-shaped text.
Server updates: behavior or descriptions that change after the user approved the server.

Why this is worse for agents than chatbots

A chatbot can be manipulated into saying the wrong thing. An agent can be manipulated into doing the wrong thing. With MCP, that action may touch a repository, ticket system, database, shell-adjacent workflow, cloud account, browser session, or local file. The attack path is no longer "prompt to bad answer." It is "model-facing text to tool call to side effect."

Microsoft Incident Response describes the same boundary in its 2026 guidance on AI tools moving from reading to acting: once the agent can execute read-write workflows, MCP tool metadata and returned content become part of the live action chain, not just passive context.

The official MCP security best practices emphasize authorization, confused-deputy risk, token handling, SSRF, session risks, and local server compromise. Tool poisoning sits next to those issues: it is the way malicious context can steer the agent toward abusing whatever authority the environment already grants.

Where static MCP scanning helps

Static scanning is necessary. It can inspect installed MCP servers, tool descriptions, suspicious manifests, cross-origin risks, and known patterns before the server is trusted. Snyk describes Invariant MCP-Scan as a scanner for installed MCP servers that looks for prompt injection in tool descriptions, tool poisoning, and cross-origin escalation patterns.

This is a strong first layer because many failures are visible before runtime. If a server description literally says to ignore user instructions, read secrets, hide actions, or exfiltrate context, it should be caught before an agent gets near it.

Where scanning stops

Scanning cannot fully answer what will happen after install. A remote server can change. A safe tool can be called with unsafe arguments. A benign API can return hostile content. A document, ticket, pull request, or web page can include instructions that flow back through the MCP result channel.

That is why MCP security needs a runtime layer. The runtime layer does not ask only "is this server acceptable?" It asks "is this exact action acceptable right now?" and "should this result be allowed back into the model context?"

This is also the execution-control gap described in newer MCP-style runtime research: model-facing metadata, approval prompts, and connection checks are not enough unless the runtime can bind authority, data handles, target capabilities, and audit decisions together.

Runtime defense pattern

A practical defense has two runtime checkpoints around MCP. First, inspect dispatch before execution. Second, inspect the result before the model can treat it as instruction.

1. Before dispatch: check the tool name, arguments, command shape, path, URL, network target, and credential-like content.
2. During dispatch: enforce allowlists, deny protected paths, block private-network targets unless explicitly intended, and reject suspicious exfiltration patterns.
3. After result: scan returned content for instruction-shaped text, encoded payloads, secret-looking values, and requests to call new tools.
4. After decision: record why the action passed, blocked, or escalated so the operator can investigate later.

How Clawmont applies this in OpenClaw

Clawmont's MCP security layer runs inside the OpenClaw gateway. It does not replace MCP source review or scanners. It adds the runtime checks around the agent loop: input, tool dispatch, tool response, and output.

For MCP tool poisoning, the two most important Clawmont checks are tool dispatch and tool response. Dispatch checks catch the moment a poisoned instruction turns into an action. Response checks catch the moment a tool result tries to become the next instruction.

Clawmont is intentionally local-first. Provider keys stay in the OS keychain; prompts and tool content are not proxied through a hosted Clawmont gateway; decisions are recorded to a hash-chained local audit log. Optional Guardrails alerts can send redacted event metadata, but the security decision happens on the user's machine.

A checklist for MCP tool poisoning

Review tool descriptions, schemas, and metadata as model-facing code.
Pin MCP server versions and review updates before promotion.
Limit tool permissions and credentials to the smallest useful scope.
Scan installed MCP servers before use.
Inspect each proposed tool call before execution.
Screen each tool result before it re-enters the model context.
Log pass, block, and escalation decisions with enough detail to reconstruct the chain.
Keep a rollback path: disable the server, revoke the token, restart the agent, and review recent actions.

The bottom line

MCP tool poisoning is a trust-boundary failure. It uses text that exists to help the model use tools and turns that text into an instruction channel. The answer is layered: scan before install, constrain permissions, inspect dispatch, screen results, and keep audit evidence.

If you are securing OpenClaw agents, start with MCP security for AI agents, then read the broader AI agent runtime security definition and the MCP security best practices guide.

Runtime MCP security for OpenClaw

Check tool dispatch, screen tool results, catch credential leaks, and keep audit evidence local.

MCP security product Try attack patterns

Sources and related reading

FAQ

What is MCP tool poisoning?

MCP tool poisoning is an indirect prompt-injection attack where malicious instructions are hidden in model-facing tool descriptions, schemas, metadata, or tool results. The user may not see the instruction, but the model can treat it as trusted tool context.

Can MCP scanning stop tool poisoning by itself?

Scanning helps catch poisoned descriptions and risky server packages before install, but it cannot see every future tool argument, tool result, behavior change, or live API response. Runtime checks are the second layer.

How does Clawmont help?

Clawmont checks OpenClaw prompts, MCP tool dispatch, MCP tool results, and final model output locally. For tool poisoning, the important runtime controls are dispatch checks before execution and result checks before returned content re-enters the model.