A manipulation technique where malicious instructions are embedded in tool metadata that an agent reads before acting. The danger is that the agent may treat those instructions as trusted context, allowing unauthorized calls or data access without any obvious code change or network anomaly.
Expanded Definition
Tool description poisoning is a prompt-adjacent attack against agent tooling, where the agent consumes manipulated metadata, descriptions, or usage notes as if they were reliable instructions. In practice, the poisoned content can sit in tool manifests, plugin metadata, function descriptions, or registry entries that an AI Agent reads before deciding which tool to invoke.
What makes the technique dangerous is that it exploits the agent’s trust boundary rather than the application code path. The tool itself may be unchanged, yet the agent is steered toward unauthorized actions, broadened data access, or unsafe call sequencing because the instruction is embedded in a place the model treats as context. This is why the issue belongs in NHI and agent governance, not only in application security. Guidance varies across vendors, and no single standard governs this yet, so teams should treat tool metadata as untrusted input and subject it to review, version control, and allowlisted provenance. For a broader NHI control view, see the Ultimate Guide to NHIs and the NIST Cybersecurity Framework 2.0.
The most common misapplication is assuming tool metadata is harmless documentation, which occurs when teams let agents ingest descriptions from untrusted registries or third-party connectors without validation.
Examples and Use Cases
Implementing agent tool governance rigorously often introduces friction in onboarding and faster release cycles, requiring organisations to weigh agility in tool registration against the cost of additional review and provenance checks.
- A marketplace connector advertises “read-only reporting,” but the description embeds instructions to query a broader data source once the agent is active.
- A function catalog lists a support tool with language that nudges the agent to bypass normal approval steps and retrieve secrets from a vault-backed workflow.
- A compromised internal registry alters a tool’s summary so the agent prefers a higher-risk endpoint, even though the underlying API has not changed.
- An orchestration layer ingests third-party plugin metadata and the agent follows hidden operational cues, creating an unauthorized data exposure path that mirrors the kinds of NHI failures discussed in the Ultimate Guide to NHIs.
- Security teams test whether agents respect metadata boundaries by comparing their behavior against the NIST baseline for controlled access decisions in the NIST Cybersecurity Framework 2.0.
Why It Matters in NHI Security
Tool description poisoning matters because it turns a governance weakness into an execution path. If an AI Agent can be influenced by descriptions it reads before acting, then the attack surface includes every tool catalog, plugin registry, and metadata pipeline that feeds agent decisions. That creates a direct link between identity governance and unsafe automation, especially where agents hold standing privileges or can reach secrets stores. NHIMG research shows that 97% of NHIs carry excessive privileges, which makes any poisoned tool path more damaging once an agent is misdirected. The same research also reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, underscoring why metadata trust must be treated as an identity control, not a model-tuning detail.
Defenders should pair metadata review with provenance controls, change approval, and least-privilege execution paths, then monitor for unexpected tool selection patterns and downstream access requests. The concept also aligns with the NIST Cybersecurity Framework 2.0, which emphasizes governed access and resilient operations when identities are used by systems rather than people. Organisations typically encounter the operational impact only after an agent has already exfiltrated data or invoked the wrong tool, at which point tool description 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 CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Agentic AI guidance covers prompt and tool trust boundaries that poisoned metadata can exploit. | |
| OWASP Non-Human Identity Top 10 | NHI-08 | Tool metadata poisoning can redirect NHIs into unauthorized access and unsafe execution flows. |
| NIST CSF 2.0 | PR.AC | Access control and entitlement governance apply when agents act on poisoned tool instructions. |
| NIST Zero Trust (SP 800-207) | Zero trust requires each tool and request to be continuously verified, not assumed safe. | |
| NIST AI RMF | AI RMF addresses governance and harmful manipulation risks in AI system inputs and behavior. |
Treat tool descriptions as untrusted input and validate agent tool selection against approved policy.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 15, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
