The runtime can reduce the blast radius, but it cannot prove that a tool’s description or schema is the one an operator approved. If the definition changes after registry review, the agent may still trust and execute it. That makes definition integrity a separate trust problem, not just a containment problem.
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.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | MCP tool poisoning can steer an agent into misusing a trusted tool definition. |
| ASI03 — Identity & Privilege Abuse | Poisoned tool definitions can induce actions under the agent's delegated authority. | |
| ASI04 — Agentic Supply Chain Vulnerabilities | Tool poisoning is a supply-chain integrity problem for agent tooling and metadata. | |
| Recommendation — Validate tool provenance and require re-approval when a tool definition changes. Constrain delegated authority and re-check privilege before executing tool actions. Protect the tool publication path and verify signed or immutable tool artifacts. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | The issue is definition integrity, which maps directly to integrity controls. |
| CM-5 — Access Restrictions for Change | Preventing silent post-review tool changes requires controlled modification rights. | |
| AU-2 — Event Logging | Tool-definition changes need auditability to detect poisoning after approval. | |
| Recommendation — Use integrity checks to detect unauthorized changes to tool definitions and metadata. Restrict who can change approved tool definitions and require reauthorization. Log tool registry and definition changes with enough detail to support review. | ||
| NIST Zero Trust (SP 800-207) | SC-7 — Continuous Verification and Least Privilege | Runtime containment helps, but Zero Trust still requires verifying what is being trusted. |
| Recommendation — Verify each tool invocation against least-privilege policy instead of trusting registration state alone. | ||
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?