MCP Tool Poisoning: How to Govern and Prove What Your AI Agent Actually Did

A poisoned or rug-pulled MCP tool can redirect your agent without ever showing up in the interaction log. Runtime governance and tamper-evident attestation are how a platform team enforces a limit before the action runs, and proves what happened after.

MCP tool poisoning is dangerous because it can redirect your agent while the interaction log still shows only trusted tools doing ordinary work. A malicious or compromised Model Context Protocol (MCP) server hides instructions inside a tool’s description or schema. Your agent reads that metadata, treats it as ground truth, and acts on it. The user sees a normal response.

For a platform team, that creates two problems. The first is control: how do you stop an agent from carrying out an instruction it should never have followed? The second is proof: once something goes wrong, how do you reconstruct what the agent was told, what it decided, and what it did? Tracing alone answers neither.

This article covers what MCP tool poisoning is, why your normal logs miss it, and how runtime governance plus tamper-evident attestation answer both questions. It also maps the OWASP MCP03:2025 controls to where a runtime governance layer fits, and marks plainly where that layer does not reach.

What MCP tool poisoning actually is

MCP tool poisoning is an attack where a malicious MCP server embeds hidden instructions in a tool’s description or schema. An agent that reads that metadata can be manipulated into unauthorised actions such as exfiltrating data. Invariant Labs first disclosed it in April 2025, and OWASP lists it as MCP03:2025.

The mechanism is simple. The Model Context Protocol lets an agent call external tools through servers. Before choosing a tool, the model reads its description and input schema. Invariant Labs showed that this description is untrusted input: a server can place instructions there that the user never sees.

In their proof of concept, a tool named add, described as “Adds two numbers”, carried a hidden payload. It made the Cursor agent read the user’s local configuration file and SSH keys and send them to the attacker’s server. The confirmation dialog showed only a summarised tool name (Invariant Labs, April 2025).

OWASP frames the whole class as a supply-chain compromise. Per OWASP MCP03:2025, the attacker does not exploit a code bug; they change the contract so that legitimate agents behave incorrectly while passing superficial validation.

Three variants worth knowing

Tool poisoning hides instructions in a tool’s description or schema, as above. Two related variants make the problem harder to see.

An MCP rug pull is when a server changes a tool’s description after the client approved it. The tool you reviewed at onboarding is not the tool running in production. Invariant Labs compares this to a package index entry that is modified after upload, a familiar software supply-chain move.

A shadowing attack is when a malicious server’s tool description changes the agent’s behaviour toward a different, trusted tool. In Invariant Labs’ example, a poisoned add tool silently redirected every message sent by a trusted email tool to the attacker, and instructed the agent not to mention it. Combined with a rug pull, this can hijack an agent while the user-facing interaction log shows only trusted tools.

Why your interaction log will not show the attack

Your interaction log will not show a tool poisoning attack because the malicious instruction rides inside metadata the agent treats as legitimate, so the trace records valid-looking calls to trusted tools. OWASP states this directly: logs and traces will show actions invoked per contract even though the contract was malicious.

Tracing and observability tools capture what an agent did, step by step. That is genuinely useful for debugging, cost, and latency. For a poisoning incident, three gaps remain.

First, the record shows trusted tools. If email went to the wrong recipient because of a shadowing instruction, the trace shows an ordinary send. Nothing in it flags the redirection. Second, a trace that can be edited after an incident is weak evidence in a dispute. Third, tracing sits alongside or after the action; it does not decide whether the action runs.

The distinction is between observability and governance. Observability answers what happened. It is not designed to enforce a limit before an action runs, or to produce a signed, per-session record of every decision. Those are the two jobs a governance layer adds, and they are the two the attack above defeats.

What runtime governance changes before the action runs

Runtime governance evaluates every agent operation before it executes and returns one of four decisions, so a poisoned instruction can be blocked or paused before any data leaves. OpenBox, an AI agent governance platform, wraps existing agents and enforces policy at execution time through this decision layer.

When OpenBox evaluates an operation it returns ALLOW, REQUIRE_APPROVAL, BLOCK, or HALT. ALLOW lets the operation proceed normally. REQUIRE_APPROVAL pauses it and routes it to a human reviewer before it can continue. BLOCK denies the specific operation while the session continues. HALT terminates the entire agent session. When several policies apply, precedence runs HALT over BLOCK over REQUIRE_APPROVAL over ALLOW, so any HALT ends the session regardless of the rest (docs.openbox.ai, Governance Decisions).

Against poisoning, this layer does concrete work. A stateless policy check, authored in OPA/Rego, returns CONTINUE or REQUIRE_APPROVAL for a single operation. Say a poisoned description tries to justify sending a file of credentials to an unapproved domain. The policy can return REQUIRE_APPROVAL and pause that step for a human before anything leaves. OWASP recommends exactly this: a runtime policy decision point before execution.

Behavioral Rules add stateful, multi-step detection. Exfiltration is usually a sequence: read a sensitive file, then send it outside. A stateless check may pass each step on its own. A Behavioral Rule that recognises the read-then-send pattern can escalate it to BLOCK, REQUIRE_APPROVAL, or HALT. For a high-impact action, REQUIRE_APPROVAL puts a human in the loop before execution, which is the pause-and-confirm control OWASP calls for when an operation’s impact crosses a threshold.

The shift is where enforcement sits: before the tool call completes, not in a report afterwards. A poisoned description can still reach the model, but it cannot silently complete a blocked or paused action. What runtime governance does not do is read the server’s mind. It governs what the agent does with a tool, not whether the upstream description was honest, so vetting and pinning servers is still necessary.

What tamper-evident attestation proves after the fact

Tamper-evident attestation gives you a signed, verifiable record of every governance decision in a session. You can reconstruct what an agent was asked to do, and what was allowed, blocked, or paused. OpenBox records each decision and, when a session closes, produces a Proof Certificate you can check for integrity.

Each evaluation records a governance event with the timestamp, the agent, the event type, the verdict (ALLOW, BLOCK, HALT, or REQUIRE_APPROVAL), the reason, workflow and run identifiers, and any approval metadata (docs.openbox.ai, Compliance & Audit). Under the Verify stage of the Trust Lifecycle (Assess, Authorize, Monitor, Verify, Adapt), Session Replay shows the operation context and the decision timeline. A suspected read-then-send sequence, and the verdict on each step, are then visible in one place.

When a session completes, OpenBox builds the cryptographic proof through a fixed pipeline. Each governance event is hashed with SHA-256. The event hashes are combined into a Merkle tree using sorted-pair hashing, producing one session root.

That root is signed, by default in AWS Key Management Service using ECDSA NIST P-256, or through an external attestation endpoint for signing inside a Trusted Execution Environment, an HSM, or custom PKI. The output is a Proof Certificate holding the Merkle root, the signature, and the event count, one per session (docs.openbox.ai, Attestation & Cryptographic Proof).

The record is tamper-evident, which is a narrower and more defensible claim than saying it cannot be altered. The signature does not stop records from being changed; it makes any change detectable. Alter a single event after signing and the recomputed Merkle root no longer matches the signed root, so verification fails. For an incident review or a dispute, detectable integrity is the property that carries weight.

This is what closes the gap from the shadowing example. Even when the user-facing interaction log shows only trusted tools, the governance record shows the operations that were evaluated, the verdicts they received, and a signature that proves the timeline was not edited afterwards. OWASP’s own remediation guidance asks for exactly this: forensic analysis of which actions executed and what changed.

Mapping the OWASP MCP03 controls to a runtime governance layer

OWASP’s MCP03:2025 guidance recommends signed schemas, policy-as-code, provenance logging, and runtime enforcement. A runtime governance layer covers the agent side of that list: enforcing policy before execution and recording signed evidence of every decision. It does not cover the server side, signing and pinning the MCP tool schemas themselves. The table below marks which is which.

Table: OWASP MCP03:2025 recommended controls mapped to a runtime governance layer.

Read the table as a division of labour, not a claim of completeness. The bottom two rows are real controls that a runtime governance layer does not provide; they belong to whoever publishes and hosts the MCP server. Treat the two sides as complementary, not interchangeable.

Where this leaves platform teams

MCP tool poisoning is a supply-chain problem, so the defence is layered: vet and pin the servers you connect, enforce policy on the agent before an action runs, and keep a signed record you can verify afterwards. Vetting and pinning are the server side. Runtime governance and tamper-evident attestation are the agent side.

OpenBox provides the agent side. It enforces the four governance decisions at execution time and produces a Proof Certificate for every session. That is what turns a poisoned instruction from an invisible incident into one you can stop, or at least prove. For the governance decisions and the attestation pipeline, see OpenBox (docs.openbox.ai).

Frequently Asked Questions

What is MCP tool poisoning?

MCP tool poisoning is an attack where a malicious MCP server hides instructions inside a tool’s description or schema. An agent that reads that metadata is manipulated into unauthorised actions, such as leaking files or redirecting output, while the user sees a normal response. Invariant Labs disclosed it in April 2025.

Can observability or tracing tools detect tool poisoning?

Tracing tools record what an agent did, which helps with debugging, but a poisoning attack rides inside trusted-looking tool calls, so the trace shows valid actions. OWASP notes that logs will show actions invoked per contract even when the contract was malicious. Detection needs policy enforcement, not only tracing.

How does runtime governance stop a poisoned instruction?

Runtime governance evaluates each operation before it executes and returns ALLOW, REQUIRE_APPROVAL, BLOCK, or HALT, with precedence HALT over BLOCK over REQUIRE_APPROVAL over ALLOW. A policy can pause a risky step for approval, and a Behavioral Rule can block or halt a read-then-send sequence, before any data leaves rather than after.

What is a Proof Certificate and why is it tamper-evident?

A Proof Certificate is a signed record OpenBox produces per session, holding the Merkle root, signature, and event count. Governance events are hashed with SHA-256 into a sorted-pair Merkle tree and signed with ECDSA NIST P-256. Any later change breaks the root, so tampering is detectable.

Does runtime governance replace vetting MCP servers?

No. Runtime governance controls and records what an agent does with a tool; it does not verify that the MCP server’s tool description is honest. You still need to vet, pin, and monitor the servers you connect, as OWASP MCP03:2025 recommends. The two controls are complementary.