The agent may keep trusting the updated description because the new version is pushed live through the same trusted channel. That creates a re-trust problem: the tool can behave differently after review without a fresh security approval. If the description has been poisoned, the agent can be guided into unsafe tool use while appearing to follow ordinary instructions.
Why an MCP Description Change Matters
An MCP tool description is not just documentation. It helps the agent decide when to call the tool, how to frame the request, and what scope to assume is safe. When that description changes after approval, the trust boundary shifts without a fresh review, so the approved state and the live state can diverge. That is a governance problem even when the underlying tool endpoint itself has not changed.
This matters because prompt-adjacent metadata can alter agent behaviour as much as a code change can alter application behaviour. In practice, teams often treat the description as harmless text, but the agent may use it as operational guidance. If the text is misleading, overly broad, or silently expanded, the system can reclassify an unsafe action as normal usage. The result is not merely confusion; it is a control bypass through trusted instructions.
A useful reference point is the OWASP Agentic AI Top 10, which treats tool and instruction manipulation as a core risk pattern for autonomous systems. That framing is directly relevant here because the issue is not the MCP transport itself, but the way trusted metadata can steer agent decisions after approval. In practice, many security teams discover the problem only after a tool has already been reinterpreted in production, rather than during the original approval cycle.
How It Works in Practice
When an MCP server publishes a new tool description, the update typically arrives through the same channel the agent already trusts. If the agent or orchestration layer does not separate the original approval record from the live descriptor, the new wording inherits the old trust. That means the model may accept a broader purpose, a new side effect, or a more permissive usage pattern without any separate security checkpoint.
The practical failure is usually a mismatch between what was reviewed and what is now being executed. Reviewers may have approved a narrowly defined tool, but later wording can imply different data access, a different operational role, or a stronger recommendation to use the tool in edge cases. In autonomous workflows, that kind of shift can matter more than a conventional documentation edit because the agent is actively selecting actions, not passively reading them.
- Tool descriptions should be treated as policy-relevant metadata, not cosmetic text.
- Approval should bind to a versioned description hash or equivalent immutable reference.
- Any material change to scope, side effects, data exposure, or usage conditions should trigger re-review.
- Runtime monitoring should compare the approved descriptor to the live descriptor, not just log that a tool was called.
For agentic systems, current guidance suggests aligning description changes with explicit reauthorization, especially where the description can change tool selection or expand implied permissions. The OWASP Agentic AI Top 10 resource is a useful external baseline for this class of control, and NHIMG’s analysis of agentic application risk provides additional context on how these issues surface in production. These controls tend to break down when descriptions are edited frequently by multiple owners because drift becomes normalised and review gates are bypassed as operational friction.
Common Variations and Edge Cases
Tighter change control often increases operational overhead, requiring teams to balance fast iteration against the need for stable, reviewable trust boundaries. The hard part is deciding which edits are material. A typo fix is usually not the same as a change that redefines intended use, but in agentic environments the line can be blurry because small wording changes can influence model behaviour.
Best practice is evolving, but a practical rule is to treat changes as material when they alter who should use the tool, what data it may touch, what actions it may trigger, or under what conditions it should be called. A description that becomes more persuasive, more general, or more task-expansive can be risky even if the code behind the tool is unchanged. That is especially true for multi-agent pipelines, where one agent’s description can shape another agent’s delegation logic.
Edge cases also appear when descriptions are generated automatically, localised, or synced from an upstream registry. In those environments, the main risk is not malicious editing alone but uncontrolled drift. The important question is whether the review process can still prove which version the agent trusted at the moment it acted. If it cannot, the approval is no longer a reliable security control.
Risk and Threat Considerations
The material risk is re-trust drift: a previously approved tool can be repurposed through description changes without a fresh approval event. That creates an integrity gap in the control plane for autonomous systems, because the agent may continue to treat altered guidance as authoritative.
Failure mechanism: The agent consumes the updated descriptor through a trusted registration or discovery path, and the changed wording influences tool selection, scope inference, or action framing. If the update is poisoned or simply over-broad, it can steer the agent toward unsafe use while preserving the appearance of ordinary operation.
Impact: Organisations can lose effective control over authorised use, leading to excessive access, unintended data handling, policy bypass, or difficult-to-audit actions that appear consistent with approved tooling.
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 CSA MAESTRO address the attack and risk surface, while NIST AI RMF, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 — Prompt Injection and Tool Manipulation | Changed tool descriptions can steer agent tool use through trusted metadata. |
| Recommendation — Revalidate tool text changes and block unreviewed prompt or tool-manipulation drift. | ||
| CSA MAESTRO | GOV-02 — Agent Governance and Oversight | Approval drift is an oversight failure in agent governance. |
| Recommendation — Require versioned approvals for any agent tool metadata that changes trust scope. | ||
| NIST AI RMF | GOVERN — Govern AI Risk | Description drift creates unmanaged AI system risk and accountability gaps. |
| Recommendation — Govern live tool metadata as a controlled AI risk artifact with traceable approvals. | ||
| CIS Controls v8 | 6.3 — Access Grants Are Managed | Material description changes can silently expand effective access. |
| Recommendation — Revoke or reapprove tool access when metadata changes alter intended use. | ||
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | The issue is trust-boundary drift that needs explicit risk treatment. |
| Recommendation — Classify tool-description changes as risk events and enforce review before trust persists. | ||
Practitioner Guidance
What to prioritise: Bind approval to a specific tool-description version, not just to the tool name or endpoint. If the live descriptor changes in any way that affects purpose, scope, side effects, or data access, treat it as a reapproval event.
What to verify: Confirm that the platform can show which description hash or revision the agent relied on at execution time. If you cannot reconstruct that evidence, you cannot prove the agent acted under the reviewed trust state.
Decision rule: If a description change would make a reviewer interpret the tool differently, assume the agent may also interpret it differently and require revalidation before the new text is trusted.
What practitioners underestimate: The highest risk is often not overtly malicious text, but quiet scope creep. A description that becomes slightly more general can be enough to expand when the agent decides the tool is appropriate.
Practitioner takeaway: The control objective is to keep the approved meaning of a tool stable enough that the agent never inherits new trust from unreviewed wording.
