MCP tool poisoning shows why AI agent metadata needs governance

At a glance

What this is: This is an analysis of MCP tool poisoning and rug pull attacks, showing how malicious tool descriptions can steer AI agents into unsafe actions without visible alerts.

Why it matters: It matters because identity teams now have to govern not just access to tools, but the trust model around AI agent tool metadata, runtime changes, and auditability across NHI and autonomous systems.

By the numbers:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Unosecur's guide to MCP tool poisoning detection for SOC analysts

Context

MCP tool poisoning is an identity governance problem disguised as a tooling issue. In practice, the agent is trusting plain-text tool metadata as an operating instruction, which means the security boundary sits in a place most IAM and SOC programmes do not currently treat as controlled identity context.

That creates a semantic gap between approved access and approved behaviour. When tool descriptions can change after review, the enterprise is no longer governing a fixed integration. It is governing a moving trust relationship between the agent, the tool server, and the metadata the agent reads at runtime.

For AI agent programmes, this is a reminder to treat tool descriptions, invocation context, and session-scoped logging as part of the identity plane, not just the observability plane.

Key questions

Q: What breaks when MCP tool definitions change without re-approval?

A: What breaks is the assumption that a previously trusted tool still behaves the same way. If definitions can change silently between sessions, the agent may continue using a modified capability under old approval. That undermines auditability, makes security reviews stale, and hides new malicious instructions.

Q: Why do MCP-connected AI workflows create new governance risk?

A: MCP-connected workflows expand the identity perimeter because a model can act through tools and data sources rather than only through a human user session. That creates delegated access paths that must be governed like other non-human identities. The risk increases when credentials, tool permissions, and downstream actions are not mapped together.

Q: How do security teams detect MCP tool poisoning in practice?

A: Start with three signals: a stored baseline of approved descriptions, runtime diffing against the live version, and validation rules for imperatives or undeclared endpoints. Then tie those signals to agent sessions so a change can be blocked before the tool is invoked.

Q: Who is accountable when a third-party MCP tool changes its description?

A: The owning organisation remains accountable for the agent outcome, even if the tool server is managed elsewhere. Third-party control does not remove the need for internal approval, monitoring, and revocation logic. Shared responsibility only works when the runtime behaviour is observable and governable.

Technical breakdown

How MCP tool descriptions become an attack surface

Model Context Protocol connects AI agents to tools, but the agent does not just call the tool blindly. It reads the tool’s description and uses that natural-language text to decide whether and how to invoke it. That creates a semantic attack surface: the description is not code, yet it can influence runtime behaviour as if it were. If an attacker controls tool metadata or the server that serves it, they can insert instructions that survive normal API and code review controls.

Practical implication: security teams need a control over tool metadata itself, not only over tool authentication and API permissions.

Why rug pull attacks break trust in runtime metadata

A rug pull is a delayed poisoning pattern. The tool appears clean during review, then its description changes later on the provider’s server. Because many agents fetch metadata at runtime, the approved version and the active version are no longer the same thing. This breaks the assumption that an integration approved at onboarding remains stable over time. The security failure is not just malicious content, but the absence of a governed baseline for text that now influences action.

Practical implication: teams should compare live tool descriptions against an approved baseline before each session or invocation.

What schema validation and metadata diffing actually detect

Metadata diffing detects change, while schema validation detects suspicious content patterns. Diffing answers whether the description has changed since approval. Validation asks whether the text contains imperatives, undeclared endpoints, or cross-tool references that do not belong in a functional description. Neither layer is perfect on its own, but together they turn opaque text into something security tools can at least inspect. Without both, malicious instructions can hide in plain sight and pass through as routine context.

Practical implication: build both baseline comparison and content validation into the MCP control path before the agent can act on a tool.

Threat narrative

Attacker objective: The attacker wants the agent to carry out malicious actions through a trusted tool path while evading normal monitoring and approval controls.

1. Entry occurs when a malicious actor controls an MCP tool’s metadata or the server that delivers it, then plants or swaps in poisoned instructions inside the description.
2. Escalation happens when the AI agent treats that description as trusted context and follows the embedded instruction during a normal tool invocation.
3. Impact is hidden exfiltration, unauthorized system access, or other unsafe agent behaviour that appears to the SOC as a legitimate tool call.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

The core failure is trust in mutable tool metadata. MCP tool poisoning works because enterprises treat tool descriptions as informational text when the agent treats them as operational instruction. That semantic mismatch creates a governance blind spot across agentic AI and NHI control planes. The practical conclusion is that metadata now needs the same assurance model as any other access-bearing identity artefact.

Runtime metadata diffing exposes a new identity control point. Security teams have long baselined secrets, certificates, and permissions, but not the descriptive context that shapes agent behaviour. That is a structural gap in current IAM thinking, not just a logging deficiency. The result is a new control category: identity context integrity, which must be treated as part of the agent trust chain.

The semantic gap is the named concept practitioners should remember. It is the distance between a tool’s intended function and the instructions an agent can absorb from plain text. Once that gap exists, an attacker no longer needs to alter code or permissions to influence behaviour. Practitioners should treat any runtime text that can steer execution as governed identity context, not incidental metadata.

SIEM visibility alone is insufficient for MCP governance. Logging tool calls after the fact does not solve the problem if the agent has already consumed poisoned instructions at invocation time. This is a control-plane issue, not a detective-control issue. The field should expect more runtime validation at the protocol layer, because retrospective monitoring cannot reliably reconstruct what the agent believed when it acted.

MCP governance will converge with NHI lifecycle discipline. Tool descriptions, session context, and approval state now behave like living identity assets that change over time. That means review, change control, and revocation logic must extend beyond credentials to the metadata that drives machine decisions. The practitioner takeaway is simple: if the text can change the action, it belongs in lifecycle governance.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That is why teams should read OWASP Agentic Applications Top 10 next, because runtime tool trust is now a control problem, not a model problem.

What this signals

Semantic gap governance: enterprises should now treat agent-readable metadata as part of the access boundary, because the next control failure will not always be a broken permission but a trusted instruction hidden in plain text. That shifts the operating model from static approval to continuous assurance.

With 80% of organisations already reporting AI agents performing actions beyond their intended scope, the governance question is no longer whether rogue behaviour can happen. The issue is whether your current IAM and SOC stack can show what changed, who approved it, and which session consumed it.

For teams building agent controls, the practical next step is to align runtime validation with protocol-layer visibility and reference the OWASP Top 10 for Agentic Applications 2026 alongside internal change control.

For practitioners

• Baseline every tool description at approval time Capture the exact text of each MCP tool description when it is reviewed and store the baseline as a governed record. Use that baseline for later comparison before an agent is allowed to invoke the tool.
• Compare live metadata before each agent session Fetch the current description from the MCP server at session start and compare it to the approved baseline. Any addition, deletion, or wording change should pause tool use until reviewed.
• Block imperative language inside tool descriptions Flag descriptions that tell the agent to search, append, send, ignore, or otherwise act outside the tool’s declared purpose. Treat undeclared URLs, IPs, and cross-tool references as high-risk indicators.
• Require session-scoped logging for agent tool calls Log the tool description version, parameters, session ID, and agent identity in the same event so investigators can reconstruct what the agent saw before execution. Without that linkage, metadata poisoning is difficult to prove.
• Insert a human review gate for changed descriptions Do not let a changed description auto-approve itself because the tool remains technically reachable. Route unexpected diffs to a reviewer who can confirm whether the update was intended.

Key takeaways

• MCP tool poisoning turns plain-text tool metadata into an execution path that current SOC and IAM controls often do not see.
• The attack works because runtime descriptions can diverge from approved baselines, which makes static review an incomplete control.
• Practitioners should govern metadata integrity, session logging, and change approval as part of AI agent identity control.

Key terms

• MCP tool poisoning: MCP tool poisoning is the practice of hiding malicious instructions in a tool name, description, or metadata exposed by an MCP server. Because those fields are often treated as trusted configuration, the agent may adopt the attacker’s instructions during tool selection or invocation.
• Rug Pull Attack: A rug pull attack is a delayed poisoning pattern where a tool appears safe during review and then changes later on the provider’s server. The agent fetches the new description at runtime, so the approved state and the active state are no longer the same.
• Semantic Gap: The semantic gap is the distance between what a tool description is supposed to be, a functional explanation, and what it can become, a covert instruction set. In agentic environments, that gap is a governance problem because the model may treat plain language as authority.
• Runtime Metadata Diffing: Runtime metadata diffing is the practice of comparing the live tool description with an approved baseline before an agent is allowed to act. It turns mutable text into a monitored control point and helps detect poisoning, unexpected updates, and silent drift.

What's in the full article

Unosecur's full blog post covers the operational detail this post intentionally leaves for the source:

• The exact five MCP detection rules and how they are intended to be tuned in a SOC pipeline
• The runtime metadata diffing workflow for comparing approved and live tool descriptions
• The schema validation patterns used to flag imperatives, undeclared endpoints, and cross-tool references
• The gateway-layer telemetry model that ties tool calls to session context and agent identity

👉 The full Unosecur post covers the semantic gap, rug pull behaviour, and gateway-level detection logic in more operational detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing identity controls across human and non-human programmes, it is worth exploring.