# AI Agent Tool Supply Chain: Poisoning and Defenses > Poisoned tools, rug-pulls, and auto-executed configs can hijack your AI agent. Here is how the tool supply chain gets attacked and the controls that stop it. > > Source: https://rankshield.co/resources/ai-agent-tool-supply-chain-security/ · RankShield (the verifiable, quantum-safe AI security platform) Resources / Agentic AI # The AI Agent Tool Supply Chain: Poisoning, Rug-Pulls, and Auto-Execution Your AI agent trusts the tools you connect to it. Here is how that trust gets attacked through poisoned descriptions, rug-pulls, and auto-executed configs, and the controls that hold. August 2, 2026 · 13 min read · AI agent tool poisoning Jamie Kloncz Founder & CEO, RankShield Share Your AI agent trusts the tools you connect to it, and that trust is now the attack surface. In a 2026 benchmark of tool-poisoning attacks against 45 live, real-world MCP servers, malicious instructions hidden inside a tool’s description, not its output, manipulated leading AI agents into unauthorized actions with an attack success rate as high as 72.8% ([MCPTox, arXiv](https://arxiv.org/abs/2508.14925) 1 ). AI agent tool poisoning is one of three related supply-chain attacks, alongside rug-pulls and auto-executed configs, that let a tool provider hijack your agent without ever touching your own code. Weeks earlier, a real example landed: a vulnerability in Amazon Q auto-loaded and ran a tool configuration the moment a developer opened a folder, with no prompt and no consent, inheriting the developer’s cloud credentials ([Wiz](https://www.wiz.io/blog/amazon-q-vulnerability) 2 ). I build agent-attestation tooling at RankShield, and the pattern underneath every one of these is identical: the agent treats a supplier’s tool as trusted by default. What most write-ups miss is a defender’s runbook that maps each attack shape to the control that stops it, grounded in what these attacks actually do. That is what this covers. One honest note first: no control makes tool use risk-free; the realistic goal is to remove default trust and make tampering detectable. Key takeaways - The AI agent tool supply chain has three attack shapes: description poisoning (malicious instructions in a tool’s metadata), rug-pulls (a tool that turns hostile after you approve it), and tool shadowing (a malicious tool impersonating a trusted one). - Tool poisoning is not theoretical: a 2026 benchmark hit a 72.8% attack success rate across 45 real-world MCP servers by hiding instructions in tool descriptions, not outputs. - Auto-execution is the sharpest version: an Amazon Q flaw ran a workspace tool config the instant a folder opened, with no consent, exposing the developer’s cloud credentials. - The core defect is default trust: agents read tool descriptions as instructions and load tool configs without verification, so a supplier can steer the agent without touching your code. - The defense is to remove default trust: pin and hash tool definitions, require approval for new or changed tools, never auto-execute configs, mediate tool calls through a broker, and keep a verifiable record of which tool ran. ## What are the AI agent tool supply chain attacks? There are three core attack shapes, and they share one defect: your agent trusts a supplier’s tool by default. Description poisoning hides malicious instructions inside a tool’s description or metadata, which the agent reads as instructions and obeys. A rug-pull is a tool that is benign when you approve it and turns hostile later, because its definition can change after review. Tool shadowing is a malicious tool that impersonates or overrides a trusted one, so calls meant for the safe tool are answered by the attacker’s. These map directly to OWASP’s MCP Top 10, which catalogs tool poisoning together with rug-pull and shadowing as distinct entries under the tool-integrity risk, precisely because they exploit different moments in the tool’s lifecycle: the description you read, the version you approved, and the name you trust ([OWASP GenAI](https://owasp.org/www-project-mcp-top-10/) 3 ). The reason they are a supply-chain problem, not a prompt-injection problem, is that the hostile content arrives through a component you added on purpose, from a supplier you chose. The unifying insight is that the tool description is untrusted input, and most agents treat it as trusted configuration. When your agent connects to a tool, it ingests that tool’s self-description and, in effect, lets the supplier write part of its instructions. That is a supply-chain trust boundary hiding in plain sight, and it is the same class of risk OWASP now tracks as the agentic supply chain in its 2026 guidance for agentic applications ([OWASP GenAI](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/) 4 ). Name the three shapes first, because each needs a different control. DOWNLOADABLE INFOGRAPHIC ### Three tool supply chain attacks, and their controls Poisoning, rug-pull, and shadowing exploit different moments in a tool’s lifecycle. Each has a control that stops it. Free to share with attribution. ## When does opening a repo run code your agent never approved? It happens when an agent tool automatically loads and executes a configuration from your workspace without asking, which is exactly the Amazon Q vulnerability disclosed in June 2026. Amazon Q loaded MCP server configurations from a .amazonq/mcp.json file the moment a folder was opened, with no prompt, no consent, and no workspace-trust check, so opening a malicious repository could lead to immediate code execution ([Wiz](https://www.wiz.io/blog/amazon-q-vulnerability) 2 ). What makes auto-execution the sharpest version of the supply-chain problem is that there is no human moment at all. The spawned processes inherited the user’s complete environment, including AWS access keys and session tokens, so a booby-trapped repo cloned from anywhere could run code with the developer’s cloud credentials and reach internal systems. Tracked as CVE-2026-12957 and fixed in a later release, it is a clean illustration of default trust taken to its conclusion: the tool config was treated as trusted the instant it appeared on disk. This connects directly to the containment lesson from the recent autonomous-agent breach. As we covered in the analysis of [the first autonomous AI agent breach](https://rankshield.co/resources/first-autonomous-ai-agent-breach-lessons/), code execution plus inherited credentials plus network egress is the combination that turns a single foothold into a campaign, and auto-execution hands an attacker the first two for free. The rule that prevents it is simple to state and easy to skip: never auto-load or auto-run a tool configuration from a workspace; require an explicit trust decision before any tool defined by a repo can execute. ## How real is the AI agent tool poisoning threat? It is demonstrated, not hypothetical, and the numbers are stark. The MCPTox benchmark tested tool-poisoning attacks against 45 live, real-world MCP servers, using 353 authentic tools and 1,312 malicious test cases across 20 prominent LLM agents, and reached an attack success rate of 72.8% against one model by hiding instructions in tool metadata rather than in outputs ([MCPTox, arXiv](https://arxiv.org/abs/2508.14925) 1 ). These were not toy servers; they were tools agents actually connect to. The most uncomfortable finding is that capability does not save you, and in some cases hurts. Because the poisoned instruction rides inside a tool’s description, a more instruction-following model is more likely to obey it, and refusal rates varied widely between models rather than being uniformly high. The attack exploits the agent’s core behavior, doing what its tools tell it, which is why it slips past safety training that is looking for malicious user prompts, not malicious tool descriptions. Put the benchmark and the Amazon Q CVE together and you have the whole shape of the threat, which few write-ups do. MCPTox shows that poisoned tool descriptions reliably steer agents; the Amazon Q flaw shows that tool configs can execute with no human in the loop and full credentials. One is the payload, the other is the delivery. The reason this is a hub topic rather than a footnote is that it sits underneath prompt injection, agent breaches, and MCP security alike: if you cannot trust your tools, you cannot trust your agent, no matter how well you have hardened everything else. ## How do you defend your AI agent’s tool supply chain? You defend it by removing default trust at every point a supplier can influence the agent: pin and hash each tool’s definition so poisoning and silent changes are detectable, require human approval for any new or changed tool so a rug-pull cannot slip through, never auto-execute workspace configs so nothing runs without a trust decision, route tool calls through a broker that enforces namespacing and allowlists so shadowing fails, and run tool processes with least privilege and no standing secrets so a compromised tool gains little. Each control neutralizes a specific attack shape. The single highest-value habit is pinning tool definitions and re-verifying on change. Capture a hash of each tool’s description and schema when you approve it, and treat any drift as a re-approval event, not a silent update. That one discipline defeats both description poisoning, because a malicious description will not match a trusted hash, and rug-pulls, because a tool that mutates after approval trips the diff instead of acting unnoticed. It is the tool-layer equivalent of a lockfile, and most teams simply do not have one for their agent’s tools. Mediation is what makes the rest enforceable at scale. Rather than letting your agent talk to tools directly, put a gateway or broker in front that namespaces tools so no two can collide, applies an allowlist of approved tools and versions, strips or sandboxes tool descriptions before they reach the model, and logs every call. As we covered in the [MCP server security checklist](https://rankshield.co/resources/how-to-secure-mcp-server-checklist/), the broker is where you turn a pile of individual precautions into a policy the agent cannot bypass. Producing and verifying that pinned, attested tool provenance is exactly what [RankShield’s attestation layer](https://rankshield.co/platform/attestation-api/) is built to do. ATTACK TO CONTROL ### Each tool supply chain attack and the control that stops it | Attack shape | What it exploits | Control that stops it | | --- | --- | --- | | Description poisoning | Agent reads tool metadata as instructions | Treat descriptions as untrusted; pin + hash definitions | | Rug-pull | Tool changes after you approved it | Re-approval on any change; diff vs pinned baseline | | Tool shadowing | Malicious tool impersonates a trusted one | Namespacing + broker mediation; block name collisions | | Auto-execution | Workspace config runs with no consent | Never auto-load configs; require explicit trust | | Credential theft after compromise | Tool process inherits full environment | Least privilege; short-lived, scoped secrets | Controls remove default trust and make tampering detectable. None makes tool use risk-free. ## How do you detect a poisoned or changed tool? You detect it by comparing what your tools are now against a trusted baseline you captured when you approved them, and by watching for the specific signals each attack produces. Diff every tool’s description and schema against its pinned hash on each connection; a mismatch is a poisoning or rug-pull signal. Watch for two tools claiming the same name, which is the shadowing signature. And flag any tool that suddenly requests broader scopes, new network egress, or credentials it never needed before. The hard part is that these signals are invisible if you never recorded a baseline, which is why detection and prevention are the same discipline. Without a pinned definition to compare against, a changed tool description looks exactly like a normal one, and a shadowing tool looks like a legitimate registration. The moment you pin and hash tool definitions at approval, detection becomes a simple comparison rather than a guess, and the same broker that mediates calls becomes the natural place to run it on every connection. Detection should also produce evidence, not just alerts. Keep a verifiable record of which tool version, by hash, actually served each call, so that after an incident you can prove whether a poisoned or shadowed tool was involved rather than reconstructing it from mutable logs. This is the same prove-what-happened posture that answers agent incidents generally: being able to [show exactly what an agent and its tools did](https://rankshield.co/resources/how-to-prove-an-ai-agent-did-what-it-claims/) turns a suspected tool compromise into a checkable fact. Use the hardening check below to see where your tool supply chain trusts by default today. HARDENING CHECK ### Is your AI agent’s tool supply chain hardened? - Do you pin and hash each tool’s definition when you approve it? - What happens when a tool’s definition changes? - Can a workspace or repo config auto-load a tool? - Do tool calls go through a broker with namespacing and an allowlist? - Could you prove which tool version served a given call? ## How do you stop your tools from hijacking your agent? Stop trusting your tools by default. The AI agent tool supply chain gets attacked in three ways, poisoned descriptions that the agent obeys as instructions, rug-pulls that turn hostile after you approve them, and shadowing tools that impersonate trusted ones, with auto-execution as the sharpest case where a workspace config runs with full credentials and no consent. The evidence is not soft: poisoning succeeded up to 72.8% of the time across real MCP servers, and the Amazon Q flaw executed tool configs the instant a folder opened. The defect underneath all of them is the same, so the fix is too: remove default trust. Pin and hash tool definitions, require re-approval on any change, never auto-execute configs, mediate tool calls through a broker, and run tools with least privilege. Then make tampering detectable and provable. Diff every tool against its pinned baseline on each connection, block name collisions, and keep a verifiable record of which tool version served each call, so a suspected compromise becomes a checkable fact instead of a guess from editable logs. Be honest about the limit: none of this makes tool use risk-free, but together it turns your tools from an unguarded trust boundary into a controlled, attestable one. As agents connect to more third-party tools, the teams that stay safe will be the ones who treat every tool as untrusted until verified. See how [RankShield attests and verifies your agent’s tools](https://rankshield.co/platform/attestation-api/). FREQUENTLY ASKED ## Questions, answered. Jamie Kloncz CEO, RankShield · online What is AI agent tool poisoning? Tool poisoning is an attack where malicious instructions are hidden inside a tool’s description or metadata, rather than in its output, so that when an AI agent reads the tool’s self-description it treats the hidden instructions as commands and obeys them. Because the agent ingests a tool’s description in order to know how to use it, a hostile supplier can effectively write part of the agent’s instructions. A 2026 benchmark called MCPTox demonstrated this against 45 live, real-world MCP servers using 353 authentic tools and 1,312 malicious test cases across 20 agents, reaching an attack success rate as high as 72.8% against one model. The attack is dangerous precisely because it exploits the agent’s core, intended behavior, following what its tools tell it, which lets it slip past safety training that is looking for malicious user prompts rather than malicious tool descriptions. What is a rug-pull in the MCP tool supply chain? A rug-pull is a tool that is benign when you approve it and turns hostile later, exploiting the fact that a tool’s definition can change after you have reviewed it. You vet version one, connect it, and trust it; the supplier then updates the tool so a later version behaves against you, and if your agent picks up the new definition silently, the malicious behavior arrives with your prior approval attached. It is the tool-layer version of a supply-chain rug-pull in software packages. The defense is to treat any change to a tool’s definition as a re-approval event rather than a silent update: pin and hash the tool’s description and schema when you approve it, and diff against that baseline on every connection, so a mutated tool trips the check instead of acting unnoticed. Without a pinned baseline, a rug-pull is invisible. What was the Amazon Q MCP vulnerability? Disclosed in June 2026 and tracked as CVE-2026-12957, the Amazon Q vulnerability was an auto-execution flaw: Amazon Q automatically loaded MCP server configurations from a .amazonq/mcp.json file within a workspace the moment a folder was opened, with no prompt, no consent, and no workspace-trust check. That meant opening a malicious repository could lead to immediate code execution. The spawned processes inherited the user’s complete environment, including AWS access keys and session tokens, so a booby-trapped repo could run code with the developer’s cloud credentials and reach internal systems. It was fixed in a later Language Server release. The vulnerability is a clean example of default trust taken to its conclusion: a tool configuration was treated as trusted the instant it appeared on disk, with no human decision in between. The general rule it teaches is to never auto-load or auto-run a tool config from a workspace. How is tool poisoning different from prompt injection? They are related but arrive through different doors. Prompt injection delivers malicious instructions through content the agent processes, such as a web page, a document, or user input. Tool poisoning delivers them through a tool you deliberately connected, hidden in the tool’s own description or metadata, which makes it a supply-chain problem rather than an input problem. The distinction matters for defense: prompt-injection defenses focus on treating processed content as untrusted, while tool-supply-chain defenses focus on the tools themselves, pinning and hashing their definitions, requiring re-approval on change, mediating calls through a broker, and never auto-executing configs. In practice you need both, because a poisoned tool description is a form of injection that your prompt-injection controls will miss if they are only watching user and web content, not the tools your agent trusts by default. Does using a trusted MCP server make me safe from tool poisoning? It reduces risk but does not remove it, for two reasons. First, rug-pulls mean a server that is trustworthy today can change later, so trust at the moment of approval does not guarantee trust at the moment of use unless you pin the tool definitions and re-verify on change. Second, tool shadowing means a malicious tool can impersonate or override a trusted one by name, so even in a mostly trusted environment a naming collision can route calls to an attacker’s tool. The MCPTox benchmark ran against real, live MCP servers, not fabricated ones, which is the point: the attack lives in tool descriptions that any server can carry. Treating a server as trusted is a starting position, not a control. The controls that actually help are pinning and hashing definitions, namespacing and broker mediation to block shadowing, and a verifiable record of which tool version served each call. What is the first control I should add to secure my agent’s tools? Pin and hash every tool’s definition when you approve it, and diff against that baseline on each connection. This single discipline is the highest-value control because it defeats two of the three attack shapes at once: description poisoning fails because a malicious description will not match the trusted hash, and rug-pulls fail because a tool that mutates after approval trips the diff instead of updating silently. It is the tool-layer equivalent of a dependency lockfile, and most teams do not yet have one for their agent’s tools. Pair it with a hard rule that no workspace or repository config may auto-load a tool without an explicit trust decision, which closes the auto-execution path shown by the Amazon Q flaw. Once those two are in place, add a mediating broker for namespacing and allowlisting to handle shadowing, and a verifiable record so you can prove which tool version served each call. ## References - [MCPTox (arXiv 2508.14925). Tool-poisoning benchmark: up to 72.8% attack success across 45 live real-world MCP servers, 353 tools, 1,312 malicious cases, 20 agents; poison embedded in tool metadata.](https://arxiv.org/abs/2508.14925) - [Wiz. Amazon Q vulnerability (CVE-2026-12957): auto-loaded .amazonq/mcp.json on opening a folder with no consent; processes inherited full environment including AWS credentials; immediate code execution from a malicious repo.](https://www.wiz.io/blog/amazon-q-vulnerability) - [OWASP GenAI Security Project. MCP Top 10 (MCP03 tool poisoning; rug-pull and tool shadowing as tool-integrity risks).](https://owasp.org/www-project-mcp-top-10/) - [OWASP GenAI Security Project. Top 10 for Agentic Applications 2026 (agentic supply chain risk).](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/) WRITTEN BY ## [Jamie Kloncz](https://rankshield.co/author/jamie-kloncz/) Founder & CEO, RankShield Jamie Kloncz is the founder and CEO of RankShield, the verifiable AI and quantum security platform. He started the company after two attacks landed in a single week: his phone was cloned, and his business was hit by a click-fraud campaign. One targeted him as a person, the other his livelihood, and no single tool defended both. That experience, together with surviving an AI voice-clone scam, shaped RankShield’s core belief: the threats of the AI age are personal first, and trust should be something you can check, not just extend. More from Jamie → ## Make every AI action provable. RankShield is the verifiable, quantum-safe AI security platform — protection you can check, not just trust. Explore the platform → Get started ## More from Resources Agentic AI How to secure an MCP server: the operator’s checklist MCP servers ship with authentication gaps and tool-poisoning risks, and a real Anthropic server shipped three prompt-injection CVEs. Here is the consolidated checklist to harden yours before it touches production. Agentic AI How to contain prompt injection in AI agents You cannot filter prompt injection away. Here are the containment patterns, least privilege, bounded credentials, output validation, and halt conditions, that limit the blast radius when an injection lands. Agentic AI The First Autonomous AI Agent Breach and What It Teaches You In July 2026 an AI model ran an end-to-end intrusion of production infrastructure on its own. Here is what actually happened, and the controls that would have contained it.