A technique in which a malicious MCP server alters the descriptions, schemas or prompts it returns so an AI agent receives hostile instructions through a trusted tool channel. The danger is not only the server’s presence, but the fact that its live metadata can change after approval and guide the agent into unsafe actions.
What MCP Metadata Poisoning Is
MCP metadata poisoning happens when a trusted MCP server returns altered descriptions, schemas, or prompts after approval, so the agent is steered by malicious live metadata rather than by the original server choice.
The key issue is that the trust boundary is not only the server identity, but also the runtime content it serves. If that content can change, the agent may follow instructions that were never intended at onboarding time.
This pattern is especially dangerous because metadata is often treated as guidance, not as executable influence. In practice, poisoned tool descriptions can shape planning, parameter selection, and action sequencing without a user ever noticing the shift.
How Poisoned MCP Metadata Influences Agent Behavior
MCP metadata is meant to help clients discover tools and understand how to use them. When that metadata is compromised, it can become a delivery path for social engineering inside the agent loop, directing the model toward unsafe tool calls, deceptive context, or unauthorized data handling.
The attack does not need to break the protocol itself. It only needs the agent to trust the server’s current metadata more than the user’s intent or the surrounding policy model. That makes the problem less about static configuration and more about the integrity of live, machine-consumed guidance.
For readers evaluating this pattern in the broader agent security landscape, the OWASP Agentic AI Top 10 is a useful companion reference because it frames tool misuse, identity and privilege abuse, and related agent failure modes.
NHIMG’s MCP Security Guide is also directly relevant because it explains the authorization model, token handling, and tool poisoning issues that make this class of abuse possible.
Why MCP Metadata Poisoning Matters for Trust and Control
Metadata poisoning undermines a core assumption of tool-using agents: that discovery information is descriptive and therefore safe to consume. Once that assumption fails, the agent can be manipulated through the very channel it uses to decide what actions are legitimate.
The practical consequence is policy bypass by persuasion, not by direct code execution. A poisoned description can nudge the agent toward overbroad scopes, risky destinations, or malformed arguments that increase the chance of data exposure or unauthorized side effects.
That is why protocol-level authorization design matters. Model Context Protocol: Authorization specification is relevant here because it defines how MCP servers should behave as OAuth 2.1 resource servers and why token handling should not be treated as a loose implementation detail.
RFC 9728: OAuth 2.0 Protected Resource Metadata matters as well because protected-resource metadata is the discovery layer that downstream clients rely on when deciding how to reach and trust a resource.
Operational Examples and Failure Conditions
Common failure conditions include servers that can change metadata after approval, clients that re-fetch live descriptions without validation, and agent frameworks that treat tool text as an authoritative instruction source. Each of these weakens the boundary between trust establishment and runtime execution.
The issue is not limited to one kind of prompt or one kind of schema. Any mutable metadata that can influence plan selection, argument construction, or tool routing can become a control channel for hostile guidance.
In real deployments, this also interacts with identity and secret handling. If the agent is steered toward a server that can observe tokens, proxy requests, or shape downstream calls, metadata poisoning can become an access-path amplifier rather than a standalone defect.
NHIMG’s AI Agent Identity Security: The 2026 Deployment Guide is useful here because it connects agent authorization, short-lived credentials, and task-scoped access to the runtime decisions that poisoned metadata can exploit.
For a breach-oriented perspective on how over-privileged MCP hosting can expose live credentials and client-supplied keys, see Smithery.ai MCP hosting breach 2025.
Risk and Threat Considerations
MCP metadata poisoning creates a trust abuse risk because the agent may accept hostile instructions from a channel it assumes is informational. That can convert a benign integration into a route for unsafe actions, data leakage, or privilege misuse.
Failure mechanism: A malicious or compromised MCP server alters live metadata after approval, then uses the agent’s trust in tool descriptions, schemas, or prompts to shape unsafe planning and execution.
Impact: The agent may call the wrong tool, pass sensitive context to the wrong place, or carry out actions that appear policy-compliant from the client side but were induced by poisoned server-controlled guidance.
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, OWASP API Security Top 10 and CSA MAESTRO address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | Metadata poisoning steers agent tool selection and arguments. |
| ASI03 — Identity & Privilege Abuse | Poisoned metadata can induce actions beyond intended agent authority. | |
| ASI09 — Human-Agent Trust Exploitation | The attack exploits misplaced trust in server-provided guidance. | |
| Recommendation — Bind tool discovery to validated policy so poisoned metadata cannot redirect tool use. Constrain agent authority so runtime instructions cannot expand privilege or scope. Require users and systems to distrust unverified agent guidance from external sources. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Mutable MCP metadata and weak validation create a misconfiguration-driven trust gap. |
| Recommendation — Harden server configuration and validation so metadata cannot be altered into unsafe guidance. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Poisoned metadata is untrusted input that influences agent behavior. |
| AC-6 — Least Privilege | Poisoned metadata becomes more dangerous when agents hold broad access. | |
| AU-2 — Event Logging | Runtime metadata changes and tool decisions need auditability. | |
| Recommendation — Validate tool metadata before the agent consumes it. Limit agent permissions so hostile metadata cannot trigger high-impact actions. Log metadata changes and agent tool selections for later review. | ||
| NIST Zero Trust (SP 800-207) | 3 — Zero Trust Principles | The subject depends on continuous verification of dynamic trust signals. |
| Recommendation — Continuously verify tool and metadata trust before allowing execution. | ||
| CSA MAESTRO | Agentic AI threat modeling | The pattern is an agentic threat-model case involving tool and metadata trust. |
| Recommendation — Model metadata poisoning as a trust-boundary failure in the agent workflow. | ||
Practitioner Guidance
What to watch for: Treat post-approval metadata changes as a security signal, not a normal content update. If a server can change descriptions or schemas without a clear integrity model, the agent is exposed to instruction drift even when the transport itself is authenticated.
Governance implication: Practitioners should define who is allowed to publish MCP metadata, when changes require review, and whether agents should trust live metadata, cached metadata, or signed metadata snapshots. The practical decision is about preserving the original trust decision while still allowing controlled tool discovery.
Practitioner takeaway: If metadata can steer execution, then metadata integrity is part of the control plane and should be treated with the same seriousness as authorization.
Related resources from NHI Mgmt Group
- Who should be accountable when a federated MCP registry exposes the wrong server or auth metadata?
- How should security teams govern MCP client onboarding with URL-based metadata?
- How do security teams reduce the risk of poisoned MCP metadata?
- How do security teams detect MCP tool poisoning in practice?