The failure is that server approval and tool allowlists validate access, but not the intent embedded in tool metadata. A poisoned description can redirect an agent into a legitimate tool call that still appears authorised. Teams need controls that inspect tool provenance, parameter history, and behavioural context, not just whether the server was approved.
What actually fails in MCP when tool descriptions steer the agent
The failure is not that the tool was unauthorised in a server sense. The failure is that the agent is influenced by metadata that looks like guidance but is not part of the approval decision. When a description can shape tool selection, a legitimate tool call can still be misdirected, which makes the control boundary too weak if you only trust allowlists and server approval.
This matters because MCP tooling often sits at the point where an agent turns language into action. If the description is misleading, outdated, or poisoned, the agent may choose the wrong tool while still remaining inside the approved server set. That creates a gap between what was permitted and what was intended, which is why provenance and behavioural context matter alongside approval.
Why approved tools can still be abused through metadata
Tool approval answers a narrow question: is the server or tool exposed to the agent at all? It does not answer whether the description, examples, or surrounding metadata are trustworthy. In practice, that means a poisoned tool description can act like a steering signal, nudging an agent toward an action the operator never meant to encourage. For practical MCP authorisation guidance, see the MCP Security Guide and the Model Context Protocol: Authorization specification.
That is why this class of issue is closer to intent manipulation than classic access control failure. The server may be valid, the token may be valid, and the call may even match policy, but the agent’s reasoning has been steered by untrusted content. The control problem is therefore not just “who can call the tool?” but also “what story did the agent believe when it chose the tool?”
In agentic systems, this is especially dangerous when descriptions resemble operational instructions, claim authority, or contain task framing that the model treats as high-confidence context. The agent can then follow a legitimate path into the wrong action, which is why tool metadata must be treated as an input to be governed, not as harmless documentation. The broader agentic threat surface is covered well in OWASP Agentic AI Top 10 and Agentic AI Security Guide.
What controls need to change beyond allowlists
Practitioners need to separate approval from trust. Approval should decide whether a tool may exist in the environment; a second layer should decide whether the agent should use it for this request. That second layer needs to consider tool provenance, parameter history, policy constraints, and whether the tool’s recent behaviour still matches its declared purpose. If a tool description can influence routing, then the description itself becomes part of the control surface and should be reviewed like other security-relevant metadata.
What to verify: confirm that the agent evaluates the tool against current policy and provenance, not only against the server allowlist. Verify that description changes, registry updates, and connector swaps are tracked as security-relevant events, because a safe tool name can conceal an unsafe instruction path.
Common mistake: teams often assume that approval of the endpoint means approval of every action the agent takes through that endpoint. That shortcut breaks down when the model uses descriptions or examples as a decision cue. If the description can alter behaviour, it needs governance, review, and change control just like code or prompt content.
What good looks like: the agent’s tool choice is explainable from policy and context, not from opaque metadata alone. The environment records which description version was used, which parameters were supplied before, and why the action was permitted. That gives you a way to detect when the agent was steered versus when it was genuinely following an authorised path.
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 SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | Tool descriptions steering agent choice is a tool misuse path. |
| ASI03 — Identity & Privilege Abuse | Approved calls can still be abused when authority is steered into unintended actions. | |
| Recommendation — Constrain tool selection with policy checks that ignore untrusted metadata cues. Bind tool execution to explicit authorization and least privilege per action. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Approval must enforce what an agent may execute, not just expose a tool. |
| AU-2 — Event Logging | Tool provenance and parameter history need auditability to detect steering. | |
| CM-3 — Configuration Change Control | Description changes can alter agent behaviour and must be controlled. | |
| Recommendation — Enforce policy at execution time, not only at tool registration. Log tool metadata changes, selections, and resulting actions for review. Treat tool description updates as controlled changes requiring review. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | The issue is an architecture failure in how untrusted tool metadata is consumed. |
| Recommendation — Design the agent tool path so untrusted metadata cannot drive trust decisions. | ||
| OWASP Non-Human Identity Top 10 | NHI-10 — Human Use of NHI | Human-authored tool metadata can steer non-human execution paths. |
| Recommendation — Separate human-authored descriptions from agent authorization decisions. | ||
Practitioner Guidance
Decision rule: if the tool is approved but the description could influence routing, treat the description as an untrusted input and require additional decisioning before execution. Do not rely on server approval as the final gate when the agent can be manipulated into a legitimate but unintended call.
What to prioritise: provenance checks, parameter lineage, and behavioural context should come before broad expansion of the tool catalog. In other words, it is better to know exactly why an agent chose a tool than to make the catalog larger and hope the allowlist will absorb the risk.
Practitioner takeaway: the control objective is not merely to approve tools, but to constrain how an agent interprets them. If metadata can steer action, it must be governed as part of the decision path, not treated as neutral documentation.