AI Agent Tool Poisoning: What the 2026 Standards Say

Key Takeaways

• In summer 2026, two standards bodies and a national cyber agency formalized the same threat: an autonomous AI agent can be subverted through the tools it calls, not only the prompts it reads. MITRE ATLAS minted a dedicated technique for it, AI Agent Tool Poisoning (AML.T0110), with a modified date of 31 July 2026.
• Tool poisoning has three distinct forms in the ATLAS taxonomy. The technique defines sub-techniques for poisoning a tool's Definition and Instructions, its Implementation, and its Runtime Response, each with its own maturity rating.
• The threat is already realized, not theoretical. MITRE rates the implementation sub-technique "Realized" and cites a real malicious Model Context Protocol server, the Postmark backdoor, as its example.
• OWASP names the underlying design flaw Excessive Agency. LLM06:2025 Excessive Agency attributes it to three root causes: "excessive functionality; excessive permissions; excessive autonomy," and prescribes human-in-the-loop approval for high-impact actions.
• The UK's NCSC published interim guidance on the same problem. Its agentic AI post (20 August 2026) recommends running agents in a sandbox, giving each agent a unique identity, restricting its credentials, and keeping a human in the loop for higher-risk actions.
• The defenses these sources converge on are structural, not instructional. Least-privilege tool allowlists, sandboxed execution, unique agent identity, and a human gate on mutating actions all limit what a poisoned tool can accomplish even if the model is fooled.
• This is a recency land-grab: the technique IDs are weeks old. The standards are authoritative and citable, and almost nothing else on the web references them yet.

AI agent tool poisoning is the subversion of an autonomous agent through the tools it uses, by tampering with a tool's model-visible definition, its executable code, or the responses it returns, and as of 31 July 2026 it is a named technique in MITRE ATLAS (AML.T0110) rather than a research curiosity. For any team running an agent that calls tools against production, this reframes agent security: prompt injection is only one entry point, and the tool layer is now a documented attack surface with its own taxonomy. This post lays out what MITRE, OWASP, and the NCSC actually say, and which defenses they converge on.

What is AI agent tool poisoning (MITRE ATLAS AML.T0110)?

Tool poisoning is tampering with the tools an agent trusts so that the agent's behavior diverges from what those tools claim to do. MITRE ATLAS defines the parent technique this way: "Adversaries may poison tools used by AI agents by introducing or modifying malicious content or behavior in a tool's model-visible definition, executable implementation, or runtime responses." The tools in scope are broad, explicitly including "Model Context Protocol (MCP) servers and tools, and agent skills or similar capability packages."

The defining property is misrepresentation. In the ATLAS wording, "a poisoned tool is represented or trusted as performing a benign function, but its definition, implementation, or responses cause agent behavior or tool-mediated effects to differ materially from the represented function." The technique carries a created date of 30 March 2026 and a modified date of 31 July 2026, and MITRE rates its overall maturity "Realized." It is distinct from an agent faithfully retrieving malicious external data, which ATLAS files separately.

This matters because most agent-security discussion still centers on prompt injection, where the attacker manipulates the text the model reads. Tool poisoning is a different surface: the attacker manipulates the capabilities the model is handed. ATLAS notes tool poisoning "frequently enables other techniques such as LLM Prompt Injection," so the two compound rather than compete.

What are the three types of tool poisoning in MITRE ATLAS?

ATLAS breaks AML.T0110 into three sub-techniques, each attacking a different layer of a tool, and each with its own maturity rating.

Sub-technique	ATLAS ID	What is poisoned	Maturity
Definition and Instructions	AML.T0110.000	The tool's model-visible description, schema, parameter names, docstrings	Demonstrated
Implementation	AML.T0110.001	The tool's executable code, so normal invocation has hidden side effects	Realized
Runtime Response	AML.T0110.002	The content the tool returns, to steer the model's later reasoning	Feasible

The distinctions are precise. Definition poisoning works even if the tool is never called: MITRE notes "the model may process malicious instructions that are invisible or only partially visible to a human reviewer," because an agent often sees a fuller tool description than a person does in the UI. It also enables "tool shadowing," where one poisoned tool's definition alters how the agent invokes a different, trusted tool.

Implementation poisoning needs no manipulation of the model at all. MITRE's example is concrete: "a poisoned email tool may send the requested message while silently adding an adversary-controlled blind-copy recipient." The malicious effect comes from code that runs on invocation, and MITRE notes installed copies "may continue to exhibit the poisoned behavior even after the malicious package or remote listing is removed." This sub-technique is rated "Realized," and its cited example is the Postmark MCP backdoor, a real npm package.

Runtime response poisoning attacks the channel back into the model: a compromised tool "deliberately returning content intended to influence the model's subsequent reasoning, decisions, or actions." Because tool outputs are folded into the model's context, a poisoned response can direct the agent to call other tools or exfiltrate data, with "poisoned instructions mixed with legitimate results."

What is Excessive Agency in the OWASP LLM Top 10?

Excessive Agency is OWASP's name for giving an LLM-based system more capability, permission, or independence than the task requires. It is entry LLM06:2025 Excessive Agency in the OWASP Top 10 for LLM Applications, and it is the design flaw that makes tool poisoning damaging. If the agent could only ever do a little, poisoning its tools would achieve little.

OWASP attributes Excessive Agency to three root causes, quoted verbatim: "excessive functionality; excessive permissions; excessive autonomy." An agent wired to more tools than it needs, holding broader credentials than the task requires, or allowed to act without confirmation is exactly the agent a poisoned tool can turn into a weapon.

The prescribed mitigations are a least-privilege checklist: minimize the tools an agent can reach, minimize each tool's functionality and permissions, execute tools in the user's own security context, and, for high-impact actions, "Utilise human-in-the-loop control to require a human to approve high-impact actions before they are taken." OWASP's guidance elsewhere in the Top 10 is to implement authorization in the downstream systems the agent calls rather than trusting the model to decide what is allowed. That principle is what survives a poisoned tool: if the system enforcing the permission is not the thing that was poisoned, the attack is contained.

How do you secure autonomous AI agents in production?

The three sources converge on structural controls rather than prompt-level fixes, because a poisoned tool defeats any defense that trusts the tool. The controls that hold are the ones enforced outside the agent's judgment.

1. Least-privilege tool allowlists. Expose the smallest set of tools that the task needs, and gate powerful tools behind an explicit allowlist rather than making everything callable by default. This is OWASP's "minimize extensions" applied directly, and it shrinks the surface a poisoned definition can exploit.
2. Sandboxed execution. Run tools in an isolated environment so a poisoned implementation cannot reach beyond its box. The NCSC states this directly: "Always run AI agents within a sandboxed environment that controls and manages what resources can and cannot be communicated with."
3. Unique agent identity and scoped credentials. The NCSC recommends that "All agents should be assigned their own unique identity in a class which differentiates them from human or individual systems," and that "you should restrict the credentials available to the agent." An agent that authenticates as itself, with narrow credentials, limits what a poisoned tool can do with its access.
4. A human gate on mutating actions. Both OWASP and the NCSC land here. The NCSC's model is "Human-in-the-loop: humans approve actions before they happen," and it adds that "for higher risk scenarios, we recommend having human oversight alongside technically enforced controls." A human approving the write is the control that a poisoned runtime response cannot forge.
5. Authorization in downstream systems. Enforce permissions in the systems the tools call, not in the model. If the poisoned component is not the component checking the permission, the check still holds.

The NCSC guidance is explicitly interim, described by the agency as advice that formal guidance will "build upon, and ultimately supersede," so cite it as a current NCSC blog position rather than a finished standard. The MITRE and OWASP entries are the durable references.

How does a least-privilege AI SRE hold up against tool poisoning?

By making the structural controls the default rather than an option a user has to remember. An AI SRE that gates powerful tools behind an allowlist, runs execution in a sandbox, and denies mutating writes when no human is present is applying exactly the controls MITRE, OWASP, and the NCSC recommend, and doing so before any specific tool is trusted.

Aurora is built on that footing. Its most powerful capabilities sit behind an explicit tool allowlist rather than being callable by default, it supports sandboxed Kubernetes execution for tool runs, and its structural chokepoint denies all mutating writes when no interactive human is present, so a poisoned tool cannot drive an unattended change into production. Remediation is limited to a pull request a human merges, which is OWASP's human-in-the-loop control applied to the highest-impact action. The layered design is described in AI agent guardrails, and the accountability trail that goes with it in who is accountable when an AI agent changes prod. None of that requires a novel defense; it requires refusing Excessive Agency by default.

The summary

As of summer 2026, tool poisoning is a named MITRE ATLAS technique (AML.T0110) with three sub-techniques, one already rated Realized with a real malicious MCP server as its example. OWASP names the enabling design flaw Excessive Agency and traces it to excessive functionality, permissions, and autonomy. The NCSC's interim guidance adds sandboxing, unique agent identity, and scoped credentials. The through-line is that prompt-level defenses do not survive a poisoned tool, and the controls that do are structural: least privilege, sandboxing, downstream authorization, and a human gate on mutating actions.

Sourcing note. AML.T0110 technique names, IDs, maturities, descriptions, and the created (30 March 2026) and modified (31 July 2026) dates are quoted from MITRE ATLAS release 2026.07 in the official mitre-atlas/atlas-data repository, verified 31 August 2026. OWASP wording is quoted from LLM06:2025 Excessive Agency in the OWASP Top 10 for LLM Applications repository. NCSC quotes are from "Managing the cyber risk of agentic AI," published 20 August 2026, which the NCSC labels interim advice. Aurora's controls are described from its open-source repository.