A poisoned tool description can inject hidden instructions into the model’s context and alter how other tools are used. In practice, that means a trusted tool may be coerced into extra actions the user never intended, such as sending data elsewhere or reading sensitive files. The result is cross-tool contamination that is hard to spot without detailed monitoring.
How a poisoned MCP tool description spreads
A poisoned tool description does not just misdescribe one capability, it can become part of the model’s working context and influence how the model interprets other tools. Once that contaminated description is trusted, the model may chain it into later decisions, so a clean tool can be used in a way that reflects the attacker’s hidden instruction rather than the user’s request. That is why tool metadata deserves the same scrutiny as tool output.
In MCP environments, the problem is especially sharp when one tool’s description is allowed to shape another tool’s invocation path. The model may treat the injected instruction as guidance for composition, escalation, or delegation, even if the second tool itself is legitimate. The practical failure is not simply “bad text,” but contaminated orchestration across a tool set that was assumed to be mutually trustworthy. MCP Security Guide is useful here because it treats tool poisoning as a first-class MCP risk rather than a generic prompt problem.
The strongest defence is to treat tool descriptions as untrusted input and to separate descriptive metadata from execution authority. If the agent is allowed to infer too much from free-form descriptions, a malicious description can redirect a trusted tool toward data exposure, side effects, or unnecessary reads. That is why teams should design tool registries, gateways, and agent policies so that a description can inform UI or discovery, but cannot silently expand the effective permission set of another tool.
Why cross-tool contamination is harder to detect than a single bad tool
Cross-tool contamination is difficult because the harmful action often occurs in the second tool, not in the poisoned one. The malicious description may look harmless in isolation, yet it changes the model’s chain of reasoning, so the resulting behaviour only becomes visible after multiple tool calls. That makes the issue a composition problem, not a simple content-filtering problem.
This is why the weakness maps cleanly to agentic tool misuse and identity and privilege abuse. A poisoned description can cause a trusted tool to act outside the user’s intent, which means the real failure is in delegated authority, not just in text handling. The OWASP Agentic AI Top 10 and The agentic AI applications guide both help frame this as a tool-use integrity issue, while Analysis of Claude Code Security is a useful example of why tool-mediated actions need tighter verification than ordinary model responses.
In practice, the risky symptom is an unexpected action sequence, such as a trusted tool being invoked with broader scope, a more sensitive file path, or a destination the user never asked for. That is the contamination boundary practitioners should watch: when one tool’s wording changes the semantics of another tool’s use, the trust model has already failed.
For a broader view of the same mechanism, OWASP Agentic Applications Top 10 is the most direct NHIMG resource because it ties tool poisoning to real agent attack paths and runtime misuse, not just abstract prompt injection.
How to keep trusted tools from inheriting a poisoned description
The practical answer is to constrain how much the model can infer from tool text. Descriptions should be concise, structured, and validated, and high-risk actions should require explicit policy checks rather than relying on the model’s interpretation of prose. If a tool can read files, send data, or trigger external side effects, those actions should be bounded by policy and logged separately from the description layer.
Model Context Protocol: Authorization specification is directly relevant because it shows the direction of travel for stronger MCP authorization, including audience-bound tokens and avoiding token passthrough. That matters here because the more clearly execution is tied to explicit authorization, the less room a poisoned description has to redirect a trusted tool through implied authority.
Practitioners should also treat tool inventory as a control surface, not a convenience list. If the agent cannot reliably distinguish a verified tool description from an injected one, then tool registration, versioning, and integrity checks become part of the security boundary. That is especially important when multiple tools share similar names, overlapping scopes, or chained workflows.
Risk and Threat Considerations
Cross-tool poisoning can turn a single compromised description into a multi-step compromise path. The main risk is not just incorrect output, but unauthorized actions that look legitimate because they are executed through a trusted tool chain. That can expose files, tokens, internal data, or downstream systems before the issue is noticed.
Failure mechanism: An attacker seeds a tool description with hidden instructions that the model then reuses when planning or invoking another trusted tool, causing unintended reads, writes, or data exfiltration.
Impact: The environment may suffer covert data exposure, privilege misuse, or policy bypass across multiple tools, and the contamination can persist until the description, registry, or orchestration layer is corrected.
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 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | Poisoned tool descriptions can drive unintended tool use in agentic workflows. |
| ASI03 — Identity & Privilege Abuse | Cross-tool contamination can cause a trusted tool to act beyond intended authority. | |
| ASI06 — Memory & Context Poisoning | Injected tool text contaminates the model context used for later decisions. | |
| Recommendation — Constrain tool invocation paths so descriptions cannot redirect execution or side effects. Bind each tool action to explicit authorization and least privilege. Isolate untrusted metadata from planning context and validate it before use. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | A trusted tool may be driven into actions beyond the user's intended authorization. |
| Recommendation — Enforce function-level authorization on every sensitive tool action. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Cross-tool contamination is only detectable with detailed action logging. |
| Recommendation — Log tool selection, parameters, and side effects for review. | ||
Practitioner Guidance
What to verify: Verify that tool descriptions are treated as untrusted metadata and that no high-risk action is authorized solely because a description suggested it. If a tool can access sensitive files or external endpoints, confirm that the invocation path is constrained by policy, not by model interpretation.
Common mistake: Teams often harden the model prompt but leave tool metadata, tool registry entries, and chained tool permissions weakly governed. That leaves a gap where the model is “protected” while the orchestration layer remains easy to poison.
What good looks like: A poisoned description changes neither the available permission set nor the recorded action path, and suspicious tool combinations are visible in logs or traces before sensitive data leaves the environment.
Practitioner takeaway: The real control objective is not preventing every misleading description, it is ensuring that no description can quietly expand what a trusted tool is allowed to do.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
