A failure mode where an agent is steered by the natural-language description of a tool rather than by a direct prompt. The description becomes an instruction carrier, so a legitimate tool can be used to perform an action the operator never intended.
What Tool Description Coercion Is
Tool description coercion happens when an agent treats a tool’s natural-language description as if it were executable instruction. The description stops being metadata and becomes a hidden control channel that can steer tool use away from the operator’s intent.
How the Coercion Works
The failure is subtle because the tool itself may be legitimate, well-scoped, and otherwise safe. The problem emerges when the agent over-trusts descriptive text, especially in systems that blend prompts, tool manifests, and runtime instructions into one context window. In practice, a malicious or poorly written description can redirect selection, alter parameters, or encourage an action path the operator never explicitly asked for.
This is related to prompt injection and tool misuse, but the mechanism is narrower: the attack surface is the description field or other natural-language tool metadata, not the user prompt alone. That makes the issue especially relevant in agentic systems where the model is allowed to interpret documentation-like text as operational guidance.
Why It Matters for Agentic Systems
Tool descriptions influence planning, routing, and invocation, so they can shape what the agent believes a tool is for and when it should be used. When that description is ambiguous, overbroad, or attacker-controlled, the agent may perform an action with real side effects even though the operator only intended a benign lookup or limited workflow step.
In agentic workflows, the impact scales quickly because one coerced tool call can chain into additional actions, external requests, or state changes. A description that implies authority, urgency, or necessity can also bias the model toward over-execution, especially when the surrounding policy language is weak or inconsistently enforced.
Common Failure Patterns
Tool description coercion usually appears when the model cannot reliably separate explanatory text from instructions. The risk increases when tool manifests are verbose, when multiple tools overlap in capability, or when descriptions include action verbs that resemble direct orders rather than neutral summaries.
It also appears when agents rely on semantic matching instead of strict policy gates. If the agent chooses tools because a description sounds relevant, rather than because the request and authorization context truly justify it, the description can become a covert instruction layer.
Defensive controls should therefore treat tool metadata as untrusted input, even when it comes from a trusted integration path. The safest designs make tool selection depend on explicit policy, constrained schemas, and clearly separated authorization logic rather than on free-form natural language alone.
Risk and Threat Considerations
Tool descriptions can become an attack vector when an adversary can influence connector metadata, documentation, marketplace content, or any other text the agent ingests while deciding how to act. The practical danger is not just incorrect routing, but unauthorized side effects executed under the cover of a legitimate tool invocation.
Failure mechanism: The agent misreads the description as instruction, then follows that framing when selecting, parameterising, or chaining a tool call. That can produce privilege misuse, unintended external actions, or multi-step abuse paths that are hard to notice in review.
Impact: The result can be data exposure, unintended transactions, destructive operations, or escalation into broader agent compromise if the coerced tool has access to sensitive systems or credentials.
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 NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | Tool descriptions can steer agent tool selection and misuse |
| ASI03 — Identity & Privilege Abuse | Coerced tool use can trigger unauthorized agent action and privilege abuse | |
| Recommendation — Constrain tool selection so descriptions cannot override explicit authorization and task intent. Enforce privilege boundaries so coerced tool calls cannot expand agent authority. | ||
| MITRE ATT&CK | T1204 — User Execution | Natural-language steering relies on the target following malicious instructions |
| Recommendation — Hunt for instruction-following paths that cause unsafe tool execution. | ||
| NIST SP 800-53 Rev 5 | SA-11 — Developer Testing and Evaluation | Tool behavior and descriptions need validation against misuse cases |
| AC-6 — Least Privilege | Damage from coerced tool use depends on how much authority the tool can exercise | |
| Recommendation — Test tool metadata and routing logic for instruction-injection and misuse failure modes. Limit tool permissions so coerced invocations have minimal blast radius. | ||
Practitioner Guidance
What to watch for: Treat any natural-language tool description that sounds imperative, persuasive, or operationally loaded as a governance signal. Descriptions should explain function, inputs, and boundaries, not try to steer behaviour.
Governance implication: Owners should review tool metadata with the same care they apply to code-adjacent policy text, because the description can materially change runtime behaviour. The key question is whether the agent can be misled by the wording even when the tool itself is technically legitimate.
Practitioner takeaway: Separate descriptive metadata from executable intent as tightly as possible, because once the model starts treating prose as policy, the tool description itself becomes part of the control surface.
Related resources from NHI Mgmt Group
- Who is accountable when a third-party MCP tool changes its description?
- How should teams respond when an MCP tool behaves differently from its description?
- How do security teams know whether an MCP tool description is actually good enough?
- What happens when an MCP tool description is changed after approval?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org