What breaks in practice when MCP tool poisoning is left to the runtime alone?

Why runtime-only containment fails against MCP tool poisoning

Runtime controls can limit damage after a bad tool is invoked, but they do not establish that the tool definition itself is the one reviewed and approved. If the description, schema, or registration metadata changes after review, the agent can still consume the poisoned definition as authoritative. In practice, that means the trust decision has to cover tool identity and definition integrity, not just execution-time containment.

A useful mental model is that runtime enforcement answers “what can happen now?”, while tool poisoning asks “what was the agent actually asked to trust?”. Those are related but different control problems. If you only harden the runtime, you may still allow a malicious or modified tool entry to shape the agent’s plan, arguments, or downstream tool chain before the runtime ever constrains the result. That is why MCP security guidance treats authorisation and registry integrity as separate from sandboxing and guardrails, and why the MCP Security Guide matters here.

Practically, tool poisoning also breaks assumptions about provenance. An operator may approve a benign tool at one point in time, but a later change can preserve the same name while altering the description, schema, or endpoint in ways the agent interprets as safe. The agent runtime can still execute the tool “safely” in a narrow sense, while the broader decision chain has already been compromised by a tampered definition. That is a definition-integrity failure, not merely an execution failure.

One more consequence is that runtime-only thinking tends to underestimate registry and supply-chain paths. If a poisoned definition is delivered through a trusted MCP registry, local config file, or hosted server, the issue sits upstream of the runtime’s last-mile protections. In those cases, the more relevant question is whether the tool inventory, publication flow, and approval state are protected well enough to prevent silent drift between review and use.

What actually breaks in the control model

The first break is trust anchoring. The agent and operator are no longer relying on the same artifact. Review may have covered one definition, while the runtime later consumes another. That mismatch creates an integrity gap that can survive even when the runtime blocks obvious abuse.

The second break is provenance continuity. A tool can look legitimate because it keeps the same label, yet its semantics have changed. If the system does not bind approval to an immutable definition hash, signed metadata, or a controlled publication path, the runtime has no reliable basis to distinguish the approved version from the poisoned one.

The third break is control placement. Runtime containment is a downstream safeguard. It is useful, but it cannot replace upstream validation of registry state, approval records, and definition drift. In other words, the place where the attack succeeds is often before execution, not during it.

Risk and Threat Considerations

Tool poisoning matters because it turns a trusted integration point into a covert influence channel. The attacker does not need to defeat runtime guardrails if they can alter the tool definition that the agent already believes is legitimate. That can lead to misdirected actions, unsafe tool chaining, or hidden data exposure even when the runtime itself remains intact.

Failure mechanism: A tool definition is changed after review, or a malicious definition is introduced through a trusted publication path, and the agent continues to rely on the altered metadata as if it were approved.

Impact: The environment can end up enforcing the wrong trust decision, with downstream consequences ranging from erroneous execution to credential exposure, data leakage, or abuse of a privileged integration path.

Practitioner Guidance

What to verify: Treat the reviewed tool definition as a versioned security object. Verify that the schema, description, endpoint, and approval state are bound together, and that a later invocation cannot silently substitute a different definition without re-review.

Decision rule: If your control only limits what the runtime can do after invocation, it is incomplete for mcp tool poisoning. Add a separate integrity check for the tool registry or configuration source before you trust the agent’s execution path.

What practitioners underestimate: The dangerous part is often not the tool’s effect at runtime, but the gap between approval and execution. Once that gap exists, containment may reduce blast radius, but it does not restore trust in what was approved.

Practitioner takeaway: Runtime controls are a backstop, not a substitute for definition integrity. For MCP, the security boundary has to include the tool artifact itself, or you are defending the consequence while leaving the trust decision exposed.

Related resources from NHI Mgmt Group

• How do security teams detect MCP tool poisoning in practice?
• What breaks when MCP tool access is left too broad or too large in Cursor environments?
• What breaks in practice when MCP tool permissions are checked only inside the tool implementation?
• What breaks when MCP tool calls rely on agent identity alone?