Tool descriptor injection is a prompt injection attack against the metadata that describes a tool, such as its name, purpose, arguments, or usage notes. By altering that description, an attacker can mislead an AI agent about when and how to invoke the tool, which can redirect actions or expand tool use.
What tool descriptor injection changes in an agentic system
Tool descriptor injection targets the metadata layer, not the tool runtime itself. By corrupting the description, an attacker can make an AI agent misread a tool’s purpose, arguments, or usage notes, which can redirect tool choice, distort execution intent, or widen what the agent is willing to do.
This is dangerous because agents often rely on tool descriptions during planning and selection. If those descriptions are attacker-controlled, the model may treat a malicious tool as trusted, overuse a capability that should be constrained, or invoke a tool under the wrong assumptions about safety and scope.
Why tool descriptors are a security boundary
Tool descriptors are part of the instruction surface that shapes an agent’s behaviour. They can be treated as documentation by engineers, but to the model they are often active control inputs that influence reasoning, routing, and tool invocation. That makes descriptor integrity just as important as prompt integrity.
In practice, descriptor poisoning is a supply chain problem for agent behaviour. The agent may never see the attacker directly, but it still absorbs manipulated metadata from plugins, MCP servers, registries, tool catalogs, or generated tool manifests. The exploit succeeds when the agent trusts that metadata more than the user’s intent or the operator’s policy.
For a practical defence lens, NHIMG’s Prompt Injection Guide covers tool description poisoning alongside other prompt injection patterns and layered defences.
Where the attack lands in the agent lifecycle
Tool descriptor injection usually matters before the first tool call, when the agent is deciding what each tool does and whether it should be used. That means the attack can influence planning, ranking, selection, and argument construction, even when the underlying tool implementation is secure.
The same weakness can also persist after deployment if descriptors are fetched dynamically or assembled from multiple sources. A poisoned description can survive through catalog refreshes, version drift, or third-party tool updates, creating a durable manipulation point that is easy to overlook in testing.
Because the attack can be embedded in ordinary-looking metadata, it often blends into normal integration work. That is why defenders should treat tool descriptions as untrusted input unless they are tightly governed and reviewed.
How defenders reduce exposure
Defenders should separate tool identity from tool description, and should not let free-text metadata become the main source of trust. Where possible, tool use should be constrained by explicit policy, fixed schemas, allowlists, and agent-side checks that verify the tool being invoked matches the expected capability.
Tool catalogs and agent frameworks should also be reviewed as part of the broader agent supply chain. Signed manifests, pinned versions, controlled publishing, and review of tool metadata reduce the chance that a malicious or altered descriptor changes behaviour unnoticed.
The strongest control pattern is to assume descriptions may be wrong, incomplete, or hostile, and to force the agent to rely on hard validation rather than narrative text. That is especially important when tools can access credentials, write data, trigger workflows, or take actions that are difficult to reverse.
Risk and Threat Considerations
Tool descriptor injection can turn a benign integration into an action-confusion attack. The danger is not only incorrect tool selection, but also the downstream effects of an agent using the wrong tool with the wrong authority, which can cause data exposure, unwanted actions, or privilege expansion.
Failure mechanism: An attacker alters the tool description so the agent misclassifies what the tool does, then the agent selects, parameterises, or trusts that tool in ways the operator never intended.
Impact: The result can be unsafe tool invocation, corrupted outputs, unintended side effects, or a broader compromise path if the tool can reach sensitive systems, secrets, or external services.
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 MITRE ATT&CK address the attack and risk surface, while OWASP ASVS sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI04 — Agentic Supply Chain Vulnerabilities | Tool descriptor poisoning changes what an agent trusts about tools. |
| ASI02 — Tool Misuse | Poisoned descriptors can drive the agent to invoke tools incorrectly. | |
| ASI03 — Identity & Privilege Abuse | Misdescribed tools can induce the agent to use authority it should not exercise. | |
| Recommendation — Vet and pin tool metadata sources, and gate tool publication to prevent descriptor tampering. Constrain tool selection with explicit policy and validate each invocation against expected purpose. Scope agent credentials narrowly and require policy checks before privileged tool actions. | ||
| MITRE ATT&CK | T1588 — Develop Capabilities | Adversaries may prepare malicious tool metadata as part of staging. |
| Recommendation — Hunt for staged malicious infrastructure and altered integrations before deployment. | ||
| OWASP ASVS | V15 — Secure Architecture | Tool descriptors are part of the trust boundary that architecture must define. |
| Recommendation — Design agent tooling so descriptions are advisory, not authoritative, for safety decisions. | ||
Practitioner Guidance
What to watch for: Treat sudden changes in tool usage, unexpected tool selection, or inconsistent agent reasoning as signs that the metadata layer may be compromised. If the model starts preferring a tool that does not match its documented function, the descriptor deserves immediate review.
Governance implication: Ownership of tool definitions should sit with the same discipline that governs code and policy, not with ad hoc prompt authorship. The people who publish or approve tool metadata need a clear review path because a small wording change can materially alter agent behaviour.
Practitioner takeaway: Secure the description as if it were executable influence, because for an agent, it often is.