Subscribe to the Non-Human & AI Identity Journal
Home FAQ AI Security What breaks when MCP tool descriptions can influence…
AI Security

What breaks when MCP tool descriptions can influence AI agents?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated August 11, 2026 Domain: AI Security

Package-centric review breaks down because the risky behaviour may live in plain-English metadata rather than executable code. When an agent treats descriptions or returned text as guidance, an attacker can steer tool choice, data handling, or downstream actions without a traditional vulnerability. The control gap is at the model boundary, not just the package boundary.

Why This Matters for Security Teams

MCP tool descriptions matter because they are part of the agent’s decision surface, not just documentation. If a model uses plain-English descriptions to select tools, summarise outputs, or decide what to do next, an attacker may influence behaviour without touching source code. That shifts the risk from classic software defects to prompt and context manipulation, which is why guidance from the OWASP Agentic AI Top 10 is so relevant here.

The practical issue is trust. Security teams often assume tool manifests are safe because they are “just metadata,” but in agentic systems metadata can function like policy input. If descriptions contain ambiguous phrasing, hidden instructions, or overly broad capability claims, the model may route sensitive data to the wrong tool or choose an action the operator never intended. That creates a control gap between the package boundary and the model boundary, where traditional application scanning sees nothing unusual.

In practice, many security teams encounter this only after an agent has already selected the wrong tool or exposed data through a benign-looking integration, rather than through intentional review of the metadata itself.

How It Works in Practice

In MCP-style environments, the agent typically ingests tool names, descriptions, input schemas, and sometimes returned text before deciding which tool to call. If those descriptions are vague, overloaded, or attacker-influenced, they can act as steering signals. The model may infer that a tool is “safe,” “recommended,” or “approved” based on wording alone, even when the actual capability is broader than the label suggests. That is why current guidance suggests treating tool metadata as security-relevant content, not as cosmetic documentation.

A stronger control pattern is to separate human-friendly descriptions from model-facing instructions. Keep descriptions terse, factual, and non-persuasive. Use allowlists, explicit permissions, and deterministic policy checks outside the model to decide whether a tool can be called. For higher-risk actions, require confirmation before execution and log the exact prompt, tool selection, and returned content so the decision chain can be investigated later. This aligns well with the NIST AI Risk Management Framework, which pushes governance, measurement, and monitoring around AI behavior rather than relying on model intent.

  • Review tool descriptions for hidden instructions, persuasive language, and security-sensitive claims.
  • Classify tools by impact, then restrict high-impact tools to explicit approval paths.
  • Validate tool outputs before they reach other tools or user-facing actions.
  • Instrument monitoring for unusual tool selection patterns, especially after retrieval or summarisation steps.

Where this matters most is in chained workflows, because one tool’s returned text can become the next tool’s instruction. These controls tend to break down when descriptions are generated dynamically from untrusted content or when the agent can discover and invoke tools with minimal policy gating.

Common Variations and Edge Cases

Tighter tool governance often increases operational overhead, requiring organisations to balance safer agent behaviour against faster developer iteration. That tradeoff is real, especially when teams want self-service tool registration or rapid experimentation.

Best practice is evolving for how much text an agent should be allowed to “understand” from tool metadata. There is no universal standard for this yet, but the direction of travel is clear: the less the model is asked to infer from prose, the better. Some teams replace rich descriptions with short capability labels and move the detailed guidance into operator-facing documentation. Others hash and sign tool manifests so that changes to descriptions are reviewed like code changes, not treated as harmless copy edits.

Edge cases appear when a tool must legitimately return free-form text, such as search, ticketing, or content moderation workflows. In those cases, the safest approach is to sandbox the output, constrain downstream actions, and compare the behaviour against known attack patterns in the MITRE ATLAS adversarial AI threat matrix. The emerging consensus is that provenance, policy enforcement, and output validation must sit outside the model if the workflow can trigger real-world action. CSA MAESTRO agentic AI threat modeling framework is also useful here for mapping agent trust boundaries and tool interaction risk.

For security teams, the key lesson is that MCP tool descriptions become part of the threat surface whenever the agent uses them as instructions, hints, or policy shortcuts.

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, MITRE ATLAS and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST AI 600-1 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10LLM07Tool metadata can steer agent decisions like prompt injection and tool abuse.
NIST AI RMFGOVERNThis is a governance problem at the model boundary, not only software code.
MITRE ATLASAML.T0051Adversarial model steering maps to attack patterns against agent decision-making.
NIST AI 600-1MPGenAI systems need output and prompt controls around tool-mediated workflows.
CSA MAESTROTRUSTMAESTRO addresses trust boundaries and execution risk in agentic systems.

Apply GenAI profile controls to restrict inputs, outputs, and unsafe model actions.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on August 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org