Tool description poisoning

What tool description poisoning is

Tool description poisoning is a prompt-injection style attack on agent tooling metadata, not on the application code itself. The attacker hides manipulative instructions in a tool’s description, manifest, or schema so the agent reads them as trusted context and may later follow them when choosing actions, calling tools, or requesting data.

What makes the technique effective is timing and trust. The harmful text is presented before execution, often during tool discovery or planning, so it can shape the agent’s interpretation of what the tool is for, what it is allowed to do, or which workflow should be preferred. That can turn ordinary metadata into a control plane for abuse.

Why tool metadata becomes a security boundary

Tool descriptions are meant to help an agent decide whether and how to use a capability. Once metadata starts influencing authorization decisions, the description itself becomes part of the security boundary. A poisoned description can steer the agent toward unauthorized calls, broaden scope in practice, or convince it to expose data that a normal request path would not justify.

The risk is strongest when the agent treats metadata as authoritative without separating guidance from instructions. This is closely related to prompt injection, but the attack surface is narrower and more operationally deceptive because the malicious text is wrapped inside a structure that defenders often assume is harmless documentation.

In agent ecosystems, this can arise in tool catalogs, plugin manifests, MCP server descriptors, or other machine-readable registration formats. The danger is not only one bad tool, but the propagation of untrusted instructions through orchestration layers that reuse the same metadata across many runs.

When the tool description is trusted too early, the agent may privilege the injected text over user intent, policy constraints, or upstream approval logic. That creates a path for action selection to be influenced before any explicit security check fires.

How organisations reduce exposure to poisoned tool descriptions

Defence starts with treating tool metadata as untrusted input until it has been reviewed, pinned, or validated against an approved registry. The most effective pattern is to separate descriptive text from executable policy, then enforce tool allowlisting, scoped permissions, and provenance checks on every tool source before an agent can consume it.

Reviewing the supply path matters because poisoning often arrives through third-party or rapidly changing tool definitions rather than through a direct compromise of the agent itself. Organisations should know where tool metadata is sourced, who can update it, and whether changes are versioned and auditable.

For a deeper treatment of this attack path and its controls, see AI Agent Tool and Plugin Security Guide and OWASP Agentic Top 10 ASI04 Guide, which both focus on tool trust, provenance, and scoped execution.

Where agents depend on external tool ecosystems, organisations should also verify the trust chain before connection, not after abuse. The MCP Server Trust Assessment is useful here because it aligns evaluation with identity, provenance, and tool-review discipline.

Detection, compromise review, and recovery

Tool description poisoning may not create an obvious exploit signature in code or network telemetry, so defenders need to look for behavioural change in the agent. Sudden shifts in tool choice, unexpected calls to high-risk tools, or requests that do not match the user’s intent can all indicate that metadata has altered planning.

After suspected exposure, review the tool registry, the fetched metadata, and the agent’s decision trail to identify which description influenced the action. If the metadata source was compromised, treat the issue as a content integrity incident, not just a prompt problem, because the poisoned text may persist until the source is corrected or replaced.

Recovery may require revoking access to the affected tool source, revalidating cached metadata, and re-running any workflows that may have consumed the poisoned description. Where data access or credential use was triggered, rotate the impacted secrets and inspect downstream logs for secondary misuse.

The MCP Incident Response Playbook is a practical reference for blast-radius triage, token revocation, credential rotation, and recovery actions after malicious tool content or server compromise.

Why this matters for agent safety and trust

Tool description poisoning shows that agent safety depends on more than model prompt hygiene. If a system cannot distinguish operational instructions from descriptive metadata, then any attacker who can alter a tool definition may gain influence over runtime behaviour without changing the agent code at all.

This is one reason tool trust, metadata review, scoped permissions, and provenance checks belong in the security model for agentic systems. The same control gap can recur across plugins, gateways, and registries, so the safer pattern is to assume metadata can lie until it has been validated by a trusted control point.

For a broader framework view, the Prompt Injection Guide provides the wider attack context, while the external OWASP Agentic AI Top 10 and MITRE ATLAS adversarial AI threat matrix situate tool poisoning within the larger landscape of agentic abuse and adversarial AI technique.

Related resources from NHI Mgmt Group

• How should security teams detect tool description poisoning in agentic systems?
• How should security teams reduce the risk of AI tool poisoning?
• What is the difference between prompt injection and tool poisoning?
• What is the difference between prompt injection and tool poisoning in agentic systems?