Tool metadata poisoning is the manipulation of the descriptive information attached to an AI tool, such as its name, purpose, parameters, or usage notes, so the system is misled about what the tool does. In agentic systems, poisoned metadata can steer tool selection, change execution assumptions, or expose data through unintended calls.
What Tool Metadata Poisoning Changes
Tool metadata poisoning corrupts the descriptive layer that agents rely on to decide whether to call a tool, how to call it, and what output to expect. The attack does not need to break the tool itself, only the trust placed in its metadata.
In agentic systems, the metadata is often the first filter between a goal and execution. If an attacker can alter names, descriptions, parameter hints, or usage notes, they can influence tool choice, create false confidence, or push the agent toward calls that were never intended.
Why It Is Dangerous in Agentic AI
Metadata poisoning is dangerous because tool selection is frequently model-driven and probabilistic. A poisoned description can make a risky tool look safe, hide a sensitive capability, or cause the agent to prefer a tool that leaks data, performs broader actions, or routes requests to an attacker-controlled service.
This is especially harmful when the system treats metadata as authoritative evidence of function. Once the agent believes a tool is appropriate, downstream controls may never get a chance to correct the decision, which turns a small integrity failure into an execution failure.
How Poisoned Metadata Misleads Tool Selection
Common failure modes include tool name collision, misleading purpose text, altered parameter descriptions, and deceptive usage notes. Those changes can steer the model toward the wrong tool, confuse routing logic, or make the model believe a sensitive parameter is benign.
That same manipulation can also change execution assumptions. For example, the agent may think a tool is read-only, assume a parameter is harmless, or trust a tool because its description appears to come from a known integration path. The problem is not just what the tool does, but what the system thinks it does.
What Defenders Should Validate
Organisations should treat tool metadata as security-relevant input, not documentation. The practical controls are to verify tool identity, pin approved definitions, compare metadata against an authoritative registry, and review changes to names, descriptions, schemas, and parameter hints before they are made available to agents.
That control stance is easier to maintain when tool trust is assessed before connection. NHIMG’s MCP Server Trust Assessment is useful here because it frames provenance, tool review, and change control as part of approval, while the AI Agent Tool and Plugin Security Guide covers tool poisoning, scoped permissions, and validation in the agent layer. For incident handling, MCP Incident Response Playbook is a practical reference for revocation, blast-radius triage, and recovery after a malicious tool or server is discovered.
Risk and Threat Considerations
Tool metadata poisoning can create both integrity and disclosure risk. If a poisoned description causes the agent to invoke the wrong tool or trust the wrong parameters, the result can be unintended actions, privilege misuse, or exposure of data to an untrusted endpoint.
Failure mechanism: The attacker alters tool metadata so the agent’s planning and selection logic makes a bad trust decision before any runtime policy or human review can intervene.
Impact: The agent may select an unsafe tool, pass sensitive inputs to the wrong destination, or carry out actions that appear legitimate but were induced by false metadata.
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 CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI04 — Agentic Supply Chain Vulnerabilities | Tool metadata poisoning is a supply-chain manipulation of agent tool descriptors. |
| ASI02 — Tool Misuse | Poisoned metadata can steer agents into misusing tools through bad selection or assumptions. | |
| ASI03 — Identity & Privilege Abuse | Misleading metadata can redirect privilege-bearing tool use and widen access. | |
| Recommendation — Vet, pin, and sandbox tool definitions before agents can trust them. Enforce per-tool policy and pre-execution checks before tool invocation. Scope tool credentials and privileges to the minimum required action. | ||
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | Trusted tool metadata should be controlled as part of approved configuration baselines. |
| CM-5 — Access Restrictions for Change | Tool metadata changes need restriction and approval before they reach agents. | |
| SI-7 — Software, Firmware, and Information Integrity | Poisoned metadata is an integrity failure that should be detected and blocked. | |
| Recommendation — Maintain approved tool metadata as a controlled configuration baseline. Restrict who can alter tool descriptors and require approval for changes. Detect and reject untrusted tool metadata before execution. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Agent tool trust depends on controlled access and permission boundaries. |
| STA — Security Testing and Assurance | Tool metadata poisoning should be included in assurance and test cases. | |
| Recommendation — Tie tool access to approved identity and access policies. Test agent tool paths for deceptive metadata and unsafe selection behavior. | ||
Practitioner Guidance
What to watch for: Treat unexpected changes in tool names, descriptions, parameter labels, or usage notes as security events. Those fields should be versioned, reviewable, and compared against a trusted source, especially when tools are added dynamically or supplied by third parties.
Governance implication: Ownership of tool metadata needs to be explicit. If multiple teams can publish or modify tool descriptors, the organisation should define who approves changes, who can consume them, and what evidence is required before an agent is allowed to trust them.