AML.T0110 AI Agent Tool Poisoning: Detect Poisoned Definitions, Code and Responses

An agent trusts its tools to do what they say, and a poisoned tool uses that trust to steer the agent, act behind its back or feed it instructions. MITRE ATLAS records this as AML.T0110 AI Agent Tool Poisoning, a Persistence (AML.TA0006) technique for the Agentic AI platform, created in March 2026 and expanded in July 2026 with three sub-techniques: AML.T0110.000 Definition and Instructions, AML.T0110.001 Implementation and AML.T0110.002 Runtime Response. ATLAS applies it to built-in integrations, local packages, remote services, Model Context Protocol (MCP) servers and agent skills. This guide maps MCP tool poisoning and its relatives onto the ATLAS structure, shows which control catches which layer, and covers testing and response. It is for agent platform owners, application security teams and detection engineers. Hands-on detection of poisoned MCP definitions is covered in MCP Tool Poisoning Detection; this page does not repeat it.

Source note: technique, case study and mitigation details follow the MITRE ATLAS data release 2026.10 (modified 28 October 2026). Confirm against the official text before relying on it.

Key takeaways

• Three layers, three control sets. Definition poisoning is caught by reviewing and hashing what the model sees; implementation poisoning needs code and behaviour controls; runtime response poisoning needs output validation and enforcement outside the model.
• Hashing definitions is not enough. The OWASP MCP Security Cheat Sheet notes that definition hashing detects metadata changes, not changes to server code behind an unchanged definition, which is exactly where the Postmark case sat.
• A tool can act without being called. ATLAS describes tool shadowing, where one tool's definition changes how the agent uses another trusted tool, just by being in the same context.
• Persistence is the point. ATLAS places the technique under Persistence: once installed, a poisoned tool keeps influencing the agent, and installed copies can keep their behaviour after the listing is removed.
• Know the boundary. A benign tool that faithfully returns attacker content is AML.T0099 AI Agent Tool Data Poisoning, not AML.T0110; malware merely shipped in a tool package may be an ordinary supply chain compromise.

The technique and its sub-techniques

ATLAS defines a poisoned tool as one represented or trusted as performing a benign function whose definition, implementation or responses make agent behaviour differ materially from that function. Poisoning may exist when the tool is first published, arrive through AML.T0010 Supply Chain Compromise, or be added later through AML.T0109 AI Supply Chain Rug Pull. ATLAS lists the effects as accessing sensitive data, altering the inputs or destinations of other tools, running unauthorised commands, concealing actions and exfiltrating information, and notes that tool poisoning often enables AML.T0051 LLM Prompt Injection, AML.T0053 AI Agent Tool Invocation and AML.T0086 Exfiltration via AI Agent Tool Invocation.

How each layer has been used

Definition and instructions

Invariant Labs published the first widely cited description of MCP tool poisoning on 1 April 2025 (ATLAS AML.CS0054). A tool's docstring told the agent to read credential files, hide this from the user and pass the contents in an otherwise unnecessary parameter, so the data reached the tool's server. Invariant also showed shadowing, where a poisoned tool's description redirected emails sent through a different, trusted tool, and the main experiments ran in Cursor. ATLAS notes that the model may receive a fuller tool description than the user interface shows, so a human reviewer can miss what the model reads.

The ClawdBot case (AML.CS0049) applied the same idea to agent skills: a researcher's proof-of-concept skill on the ClawdHub registry carried model-readable instructions in a rules file that led the agent to run a shell command reaching the researcher's server. ATLAS records 16 users running it in the first eight hours. See the Agent Skills Security Guide.

Implementation

The postmark-mcp npm package (AML.CS0053) was an unofficial copy of Postmark's MCP server. Versions up to 1.0.15 worked normally; version 1.0.16, released in mid-September 2025, added one line that blind copied every email sent through the tool to an attacker address. No instruction reached the model, and nothing in the tool definition changed. Postmark published a warning on 25 September 2025. See postmark-mcp Malicious MCP Server 2025 and, for the update path, the MITRE ATLAS AML.T0109 AI Supply Chain Rug Pull guide.

Runtime response

OWASP's MCP Tool Poisoning page describes a malicious server returning plausible data with embedded directives that the model treats as trusted input, and calls the root cause a trust gap between connect time and runtime: descriptions are reviewed once, responses enter the context unchecked. The MCP specification allows tool results to carry text, images, audio, resource links, embedded resources and structured content, so poisoned content can arrive in many forms. Once one tool's output is in context, it can steer calls to every other tool, which is how runtime poisoning becomes AML.T0086 exfiltration.

What to detect and where

The OWASP MCP Security Cheat Sheet recommends logging every tool invocation with full parameters, user context and timestamps, sending logs to a SIEM, and alerting on new tools being called and abnormal call frequency, with secrets and personal data redacted from logs. ATLAS mitigation AML.M0024 AI Telemetry Logging and Monitoring covers the same ground.

Mitigations by layer

"Primary" means the control directly targets that layer; "Partial" means it helps against some forms; "Supports" means it reduces impact rather than detecting the poison. This rating is our assessment from the sources below.

• From the MCP specification: clients must consider tool annotations untrusted unless they come from trusted servers, should show tool inputs to the user before calling the server, should validate tool results before passing them to the model, and should log tool usage. There should always be a human able to deny tool invocations.
• From the OWASP cheat sheet: hash the complete definition including inputSchema, outputSchema and annotations, because a changed readOnlyHint or destructiveHint can alter approval behaviour with no visible description change; require strict schemas with additionalProperties: false; re-prompt for consent when definitions change.
• ATLAS mitigations: AML.M0028 Enforce Access Controls for AI Agent Tools, AML.M0029 Human In-the-Loop for AI Agent Actions, AML.M0032 Segmentation of AI Agent Components, AML.M0033 Input and Output Validation for AI Agent Components, AML.M0014 Verify AI Artifacts and AML.M0023 Maintain an AI Bill of Materials each address part of the problem. See the MITRE ATLAS Mitigations Guide.
• Enforce outside the model: OWASP advises access control at the tool execution layer and in trusted application code, not in the system prompt. A poisoned tool can rewrite what the model believes, but not a policy the gateway enforces.

Implementation

1. Inventory tools: list every tool, MCP server and skill each agent can load, with source, version, credentials and whether it is local or remote. See the MCP Server Inventory Template.
2. Classify by privilege and origin: separate tools holding sensitive credentials (email, code, cloud, payments) from tools that read external content.
3. Baseline definitions in report mode: hash current definitions and log changes for two weeks before blocking.
4. Add the update gate: pin versions and require code diff review for tools in the sensitive class.
5. Add runtime controls: output schema validation, per-tool credentials and egress allowlists at the gateway.
6. Enforce: block unapproved definitions and unpinned tools, with a documented path to roll back to the last approved version.

Decision guidance

• Local or remote tool: a local tool gives you version control but runs code on your hosts, so implementation poisoning matters most; a remote tool can change behaviour at any time without a version, so definition hashing, response validation and scoped tokens matter most.
• Community or in-house tool: for sensitive operations with simple APIs, a small internal wrapper can cost less than reviewing every upstream release.
• Small organisation: start with an allowlist of tools from official sources, exact pinning and per-tool credentials.
• Large organisation: add an MCP gateway that enforces approved definitions and validates responses. See the MCP Gateway and MCP Server Governance Guide.

How to test

• Definition test: in a test environment, add a benign test server whose description contains a harmless marker instruction and confirm the scanner flags it and the gateway blocks it.
• Change test: change a test tool's description or annotation after approval and confirm re-approval is required.
• Implementation test: release a test tool version that calls a new outbound destination and confirm egress controls block and alert.
• Response test: return a result that fails the output schema and one containing a marker instruction, and confirm validation and confirmation steps hold.

The MCP Security Testing Guide covers the wider test plan.

Response

1. Disable the tool for all agents and find every install through the inventory, including copies on developer machines.
2. Preserve the tool definition, version, code and agent traces for the exposure window.
3. Rotate every credential the tool held and any secret that passed through it.
4. Review downstream logs for actions the tool or the steered agent took.
5. Record the incident against AML.T0110 and the relevant sub-technique. See the MCP Incident Response Playbook.

Where identity fits

Every tool acts with an identity. In the Postmark case the copies left through the victim's own account, so the email service saw nothing foreign. Give each tool a dedicated, narrowly scoped credential with an owner and review date, so a poisoned tool can reach little and the rotation list is known. Tools that harvest the credentials passed to them are covered in the MITRE ATLAS AML.T0098 AI Agent Tool Credential Harvesting guide.

Measuring it

• Definition coverage: share of tools with an approved, hashed definition.
• Pinning coverage: share of local tools pinned to an exact version.
• Credential isolation: number of tools sharing a credential with another tool or a user.
• Response validation: share of tool calls whose results are validated against a schema.
• Drift events: definition changes detected and how many were re-approved or blocked.

Common failure patterns

• Reviewing only the visible description: missing parameter names, schemas and annotations the model also reads.
• One-time approval: no re-approval when definitions or versions change.
• Trusting hashes alone: unchanged definitions over changed code, as in postmark-mcp.
• Shared context for all tools: external and high-privilege tools loaded together, enabling shadowing.
• Policy in the prompt: relying on system prompt rules that a poisoned response can override.

Framework mapping

Practitioner checklist

• Inventory every tool, MCP server and skill per agent, with source, version and credentials.
• Review full definitions, including schemas and annotations, before approval.
• Hash approved definitions and re-approve on any change.
• Pin local tools and review code diffs before updates.
• Give each tool a scoped credential and an egress allowlist.
• Validate tool results against schemas and treat them as data.
• Keep high-privilege tools apart from tools that read external content.
• Enforce authorisation and confirmation outside the model.

Standards and references

• MITRE ATLAS: AI Agent Tool Poisoning
• MITRE ATLAS: Poisoned Postmark MCP Server Email Exfiltration
• MITRE ATLAS: Data Exfiltration via Remote Poisoned MCP Tool
• Model Context Protocol Specification: Tools
• OWASP Cheat Sheet Series: MCP Security Cheat Sheet
• OWASP: MCP Tool Poisoning
• Invariant Labs: MCP Security Notification: Tool Poisoning Attacks

Related NHI Mgmt Group resources: MCP Security Guide · MCP Tool Poisoning Detection · MITRE ATLAS AML.T0080 AI Agent Context Poisoning · MITRE ATLAS Guide