The agent can follow malicious or misleading instructions embedded in metadata that should have been treated as untrusted. That breaks the assumption that documentation is harmless and turns descriptive text into a control input, allowing unauthorized actions to occur without obvious infrastructure compromise.
Why This Matters for Security Teams
Trusting MCP tool descriptions by default turns metadata into an attack surface. In practice, that means the agent may treat human-readable instructions as if they were policy, then execute a tool call that was never intended by the platform owner. This is the same class of failure highlighted in NHIMG coverage of OWASP Agentic Applications Top 10, where untrusted input becomes operational control.
The risk is not limited to prompt injection in the classic sense. MCP servers often package tool names, descriptions, and usage hints alongside access to real systems, so the model can be nudged into making unsafe decisions without any obvious infrastructure compromise. That is why current guidance increasingly treats tool metadata as untrusted input and recommends runtime checks rather than static trust. When teams miss this, they usually discover the problem only after an agent has already chained a benign-looking tool description into a harmful action.
The scale of the issue is visible in NHIMG research on MCP exposure: The State of MCP Server Security 2025 reports that only 18% of MCP server deployments implement any form of access scoping for tool permissions. In other words, descriptive text is often standing in for actual control. In practice, many security teams encounter abuse only after an agent has already acted on misleading metadata, rather than through intentional policy design.
How It Works in Practice
The safer pattern is to treat MCP tool descriptions as advisory text, not authoritative instruction. The agent should receive a cryptographic identity for the workload, then request access at runtime under policy that evaluates intent, context, and destination risk. That shifts control away from static trust and toward verifiable authorization. In agentic environments, this is closer to NIST AI Risk Management Framework thinking than traditional app trust models.
Operationally, teams should separate three layers:
- Tool discovery, where descriptions are visible but not trusted.
- Policy decisioning, where runtime authorization checks approve or deny the request.
- Execution, where the tool receives only the minimum data and scope needed for that task.
That design works best when paired with short-lived credentials, just-in-time issuance, and workload identity so the agent proves what it is before it can act. It also aligns with the threat model described in CSA MAESTRO agentic AI threat modeling framework, which emphasises tool governance, privilege boundaries, and abuse-resistant orchestration. NHIMG’s Gemini AI Breach — Google Calendar Prompt Injection shows why this matters: a seemingly harmless text path can become an execution path when the system fails to distinguish instructions from untrusted content.
In practice, policy-as-code engines such as OPA or Cedar are useful because they evaluate each request against current context, not a precomputed trust label. The key question is not whether the tool description looks legitimate, but whether this agent, at this moment, should be allowed to invoke this capability with these parameters. These controls tend to break down when legacy MCP gateways expose broad tool permissions and the platform cannot enforce per-request authorization because the server only supports coarse static roles.
Common Variations and Edge Cases
Tighter metadata controls often increase integration overhead, requiring organisations to balance developer convenience against runtime safety. That tradeoff becomes more visible in multi-agent systems, where one agent may generate tool calls for another, and the resulting chain can amplify a single misleading description into broader misuse. Best practice is evolving here, and there is no universal standard for this yet.
One edge case is internal-only tool catalogs. Teams sometimes assume that a private MCP server is automatically trustworthy, but insider risk, compromised connectors, and misconfigured registries can make internal descriptions just as dangerous as external ones. Another is RAG-style enrichment, where tool metadata is dynamically assembled from multiple sources; in that case, the description itself may be partly synthetic and therefore even less trustworthy.
For governance, the practical rule is simple: descriptions can inform UX, but they should never grant authority. That means reviewable allowlists for high-impact tools, scoped credentials per task, and logging that captures both the description shown to the agent and the actual policy decision made at runtime. NHIMG’s AI Agents: The New Attack Surface report shows why this matters operationally, with 80% of organisations reporting agent actions beyond intended scope. When agents can escalate through chained tool use, the description becomes a lure, not a safeguard.
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, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Tool metadata trust is a prompt injection and tool abuse problem. |
| CSA MAESTRO | T4 | MAESTRO covers agent tool governance and abuse-resistant orchestration. |
| NIST AI RMF | AI RMF applies to runtime risk controls for autonomous agent decisions. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | MCP tool access depends on handling NHI credentials and scopes safely. |
| NIST CSF 2.0 | PR.AC-4 | Access control must reflect runtime context, not static descriptive text. |
Establish continuous risk evaluation for agent actions, not static trust in descriptions.
