This is a technique where a tool’s description or metadata contains instructions that steer an AI agent into leaking data or taking unsafe actions. The model may treat the description as operational guidance, even when it should not. Effective governance requires reviewing tool text, not just code, before allowing deployment.
Expanded Definition
Tool Description Prompt Injection is a form of prompt manipulation where untrusted tool metadata, help text, or descriptions is interpreted by an AI agent as if it were operational instruction. The danger is not the code itself, but the text boundary around the tool.
This matters most in agentic systems that assemble actions from tool catalogs, plugin manifests, or function signatures. If the model cannot reliably distinguish descriptive text from executable intent, a malicious or compromised tool entry can steer the agent toward disclosure, privilege misuse, or unsafe external calls. That boundary failure is why tool review must include metadata, not just source code.
The term is closely related to prompt injection in general, but it is narrower: the attack surface is the tool description layer rather than user content or retrieved documents. Industry usage is still evolving, so some teams describe it as tool metadata injection or indirect prompt injection through tool schemas. The underlying issue is the same: instruction trust is assigned to text that should only be treated as reference material.
A useful practical boundary is this: a benign description explains capability, constraints, and usage; an injected description tries to influence agent behaviour beyond that scope.
Examples and Use Cases
Tool Description Prompt Injection appears in environments where agents select and call tools dynamically. It is especially relevant when descriptions are generated, copied from external sources, or edited by multiple teams without a security review.
- A support agent reads a tool description that says to "share the latest customer record first," and the model treats it as a valid instruction to reveal data.
- A workflow orchestrator ingests third-party plugin metadata that quietly instructs the agent to prefer one action path over another, changing decision flow.
- An internal developer adds a misleading description to a tool registry entry, causing the agent to invoke a broader-scope action than intended.
- A catalog entry for a file or ticketing tool includes text that nudges the model to bypass normal checks, creating an unsafe execution path.
- An attacker who gains influence over tool metadata can shape the agent’s reasoning without touching the underlying code, which is a common tradeoff in systems that prioritise rapid tool onboarding over strict content governance.
For background on the broader attack class, see the OWASP Agentic AI Top 10.
Real-world reporting has already shown how indirect instruction channels can be abused in agentic workflows, including Gemini AI Breach
When tool descriptions are treated as trusted instructions, the agent’s decision boundary becomes attackable. The result can be data leakage, unsafe tool selection, privilege overreach, or actions that look model-approved even though they were induced by hostile metadata. In practice, this often shows up as an approval problem rather than a code problem. Teams may harden the underlying tool implementation while leaving the description field editable, generated, or externally sourced. That leaves a governance gap where the agent can be steered before any control inside the tool is even reached. NHIMG research shows that identity and access failures scale quickly in machine environments, with 97% of NHIs carrying excessive privileges, broadening the blast radius when an agent is manipulated into calling the wrong capability. That makes tool-description review a control over both instruction integrity and downstream access scope. The practical symptom to watch for is behaviour that changes after a description update even when the code and permissions have not changed. That usually indicates the agent is binding to text too early in its reasoning chain. In NHI and agentic AI governance, tool descriptions are part of the trust boundary. They are not harmless documentation when an autonomous system uses them to decide what to call, what to reveal, or which path to take. This changes governance in a specific way: review must cover tool text, registry entries, schema annotations, and generated metadata alongside code and secrets handling. A secure deployment process therefore needs ownership for description provenance, change control, and approval of external tool sources. The term is also relevant to machine identity governance because a manipulated agent often acts through service credentials, API keys, or delegated access. If the agent is steered into unsafe tool use, the resulting action is executed with machine authority, not human caution. For organisations building agentic workflows, the key question is whether the tool catalog is treated as an input channel with security impact. If it is, then description governance becomes part of the access-control model rather than a content-management detail. This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance. OWASP Agentic AI Top 10, MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.Security Implications
Domain and Governance Relevance
Standards & Framework Alignment
Framework Control / Reference Relevance OWASP Agentic AI Top 10 TOP-10 — Agentic Applications Top 10 Covers indirect prompt injection through tool metadata and agent instructions. Recommendation — Treat tool descriptions as untrusted inputs and validate agent instruction boundaries. MITRE ATT&CK T1204 — User Execution Agent follows hostile text as an instruction path to unsafe action. Recommendation — Hunt for instruction-following abuse paths where text steers execution decisions. CIS Controls v8 16.11 — Monitor and Control Third-Party Services Tool descriptions often come from external or delegated sources that need review. Recommendation — Review third-party tool metadata before allowing it into production workflows. OWASP Non-Human Identity Top 10 NHI-03 — Secrets and Credential Exposure Misled agents can expose machine credentials or tokens through unsafe tool use. Recommendation — Restrict agent access so poisoned descriptions cannot trigger credential disclosure. NIST CSF 2.0 PR.AA — Identity Management, Authentication, and Access Control Agent tool decisions can expand or misuse authorised access if metadata is trusted. Recommendation — Gate tool authorization so metadata cannot bypass access-control decisions. Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
