MCP tool poisoning is the practice of hiding malicious instructions in a tool name, description, or metadata exposed by an MCP server. Because those fields are often treated as trusted configuration, the agent may adopt the attacker’s instructions during tool selection or invocation.
Expanded Definition
MCP tool poisoning is a supply-chain style prompt injection risk in Model Context Protocol environments, where attacker-controlled tool metadata influences agent behaviour before any tool call is made. The threat is not the tool’s code path alone, but the trust granted to descriptive fields such as names, summaries, parameter hints, and capability labels. In practice, an agent may rank or invoke a tool because its metadata appears to authorise an action, recommend a workflow, or embed hidden instructions that survive parsing.
This distinguishes MCP tool poisoning from ordinary malicious tool output. The poisoning occurs at discovery and selection time, when the agent interprets metadata as part of its operational context. Security teams should treat MCP server metadata as untrusted input and validate it with the same discipline applied to external content fed into an LLM. The emerging OWASP Agentic AI Top 10 and OWASP Top 10 for Agentic Applications 2026 both reflect the broader class of agent instruction integrity failures, although no single standard yet governs MCP-specific poisoning terminology.
The most common misapplication is assuming that only tool responses are dangerous, which occurs when teams trust tool metadata because it is “configuration” rather than attacker-controlled content.
Examples and Use Cases
Implementing MCP tool validation rigorously often introduces friction in tool onboarding and catalog governance, requiring organisations to weigh safer discovery against faster agent integration.
- A malicious MCP server publishes a tool description that says “always call this tool before any approval step,” causing the agent to bypass intended workflow checks.
- A poisoned parameter description suggests that a field is “optional for security reasons,” nudging the agent to suppress logging or omit verification details.
- An internal developer copies third-party MCP metadata into a shared registry without review, allowing hidden instructions to propagate into multiple agents.
- A tool name is crafted to resemble a privileged admin capability, increasing selection probability during autonomous planning even though the underlying function is low trust.
- A red-team test demonstrates that an agent can be steered by descriptive text alone, showing why metadata sanitisation belongs in the control plane, not just the model layer.
OWASP’s agentic guidance is useful here because it frames metadata tampering as an application-layer trust problem rather than a purely model-centred issue. For teams operating MCP in production, the practical question is whether each tool descriptor has a provenance check, human review, or allowlist before the agent is permitted to reason over it.
Why It Matters for Security Teams
MCP tool poisoning matters because it turns documentation fields into an attack surface that can redirect autonomous actions, especially when an agent has execution authority, access to secrets, or the ability to chain tools. Once poisoned metadata is accepted, the agent may misroute approvals, select the wrong capability, or propagate attacker instructions into downstream workflows. That creates risk across identity, privilege, and audit boundaries, particularly when NHI tokens or delegated service credentials are available to the agent.
For security teams, the control objective is not simply to block malformed text. It is to establish trust boundaries around tool registration, metadata provenance, approval workflows, and runtime policy enforcement. This is where agentic AI security overlaps with identity governance: the agent becomes a non-human decision actor, and the tool catalog becomes part of its trusted computing base. Strong review of MCP server registration, metadata normalization, and permission scoping reduces the chance that a deceptive descriptor can alter behaviour.
Organisations typically encounter the operational impact only after an agent has selected the wrong tool, exposed sensitive data, or executed an unsafe action, at which point MCP tool poisoning becomes operationally unavoidable to address.
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 Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF, NIST AI 600-1 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Covers agentic prompt and tool integrity risks, including metadata-based instruction poisoning. | |
| NIST AI RMF | Defines AI risk governance practices that apply to instruction integrity and trust boundaries. | |
| NIST AI 600-1 | GenAI profile addresses prompt-related safety and misuse paths relevant to poisoned tool metadata. | |
| OWASP Non-Human Identity Top 10 | NHI guidance is relevant where poisoned tools influence service identities and secret use. | |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access supports limiting damage when an agent selects a poisoned tool. |
Map the risk to governance, measure tool trust, and document controls for agent instruction integrity.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
