MITRE ATT&CK v20 adds prompt injection techniques: how to use the new IDs

Until this month, a security team that wanted to label an agent incident in MITRE ATT&CK itself had to borrow from neighbouring techniques or switch to MITRE ATLAS, the separate AI-focused knowledge base that has long had an LLM Prompt Injection technique. The v20 release, dated 13 October 2026, changes that. MITRE says the biggest change is "expanded coverage of recent adversary activity and tradecraft", including "AI-focused and AI-enabled Techniques in Enterprise" and new campaigns, among them attacks on U.S. water utilities and an AI-assisted breach of Mexican government infrastructure.

For teams that run coding agents and other AI tools, this is the first time ATT&CK itself, the framework most detection and threat-intelligence work is built on, has a shared name for what those tools get attacked with. The entries are short, and the gaps matter as much as what is there.

What v20 adds

Five of the nine new Enterprise techniques and sub-techniques concern AI systems directly:

• T1698 Indirect Prompt Injection, under the Execution tactic. Prompts embedded in content an AI system is expected to process, which MITRE lists as "web pages, documents, emails, tickets, code, or other sources".
• T1699 Direct Prompt Injection, also under Execution. Malicious prompts typed directly into an LLM's interface, including instructions to ignore earlier rules or claims to be a researcher or privileged user.
• T1700 AI-Enabled Exfiltration, under Exfiltration. An injected prompt makes an agent use its sanctioned tool connections to move data out.
• T1685.007 Impair Autonomous Defenses, under Defense Impairment. Content that targets AI-assisted security analysis, for example malware carrying fake system messages so an LLM analyser thinks it has hit an error and stops.
• T1608.007 AI Result Poisoning, under Resource Development. Public web content staged so that AI search and assistants retrieve, cite or recommend attacker-controlled material.

The others are Anti-Automation Evasion with two CAPTCHA sub-techniques, and Steal Application Specific Passwords. The release also gives Supply Chain Compromise: Compromise Software Dependencies and Development Tools a major version change, from 1.3 to 2.0. Enterprise now counts 227 techniques and 479 sub-techniques.

The procedure examples are about coding agents

T1699's two procedure examples both involve an AI coding tool. In the Mexico campaign (C0064), the page says the adversary "abused Claude Code" by using a file-write operation in the prompt to create a claude.md file holding a 1,084-line document of penetration testing scripts used in the campaign. In the earlier campaign Anthropic reported (C0062), the adversary claimed to be an employee of a cybersecurity firm running defensive tests in order to get restricted operations authorised.

The first example is worth noting for engineering teams. The attacker put their material in the instruction file the coding agent reads. We covered a related pattern, where a poisoned rule file steers the agent, in rule-file prompt injection. T1685.007 points the same way: one of its mitigations is to stop artefacts under analysis from "modifying agent configuration, instruction files, analysis state" or other trusted AI resources.

Mitigations put the decision outside the model

Read the mitigation text on T1698 and T1699 together and one idea repeats. Under Execution Prevention, T1698 says to "Prevent instructions contained in retrieved or externally supplied content from independently authorizing consequential agent actions". T1699 says to enforce tool, API, command and resource authorisation "outside the model".

The rest of the list is familiar access control applied to agents: dedicated identities for AI agents with minimal permissions, separate read and write access to files and repositories, restricted network destinations for agents that process untrusted content, and extra authorisation for privileged operations. Nothing in it relies on the model detecting the injection. It lines up with the per-agent identities and least-privilege tool profiles in the OWASP Top 10 for agentic applications, and it is a useful passage to quote when someone proposes a better system prompt as the fix.

The detection strategy needs data you may not have

DET0927, the detection strategy for AI-enabled exfiltration, has three analytics:

• On the application side (AN2078): an agent accesses protected data, invokes a tool or API with it, and the destination records a successful transfer to a recipient or service outside the allowed data flows. The log sources are SaaS audit logs and agent trace records.
• On Windows and Linux endpoints (AN2079 and AN2080): an AI-associated process reads data outside its permitted scope, then starts something able to transfer it, then connects to a destination that isn't on the approved list, all within a time window and from the same process lineage.

Every analytic depends on values you have to define. MITRE lists them as tunable fields, including the data an AI identity is permitted to access, the expected process tree for AI tools, the legitimate destinations, the allowed source-to-tool-to-destination flows, and the detection windows that link access to transfer. If you haven't written these down for your coding agents, the analytic can't separate an agent doing its job from one being used against you.

AI Result Poisoning is blunter. Its detection strategy says there is no target-side analytic, because a defender "cannot reliably distinguish" deliberate staging from ordinary publishing using their own telemetry.

Gaps to plan for

• Platforms. T1698, T1699, T1700 and T1685.007 list SaaS and Windows as platforms. DET0927 includes a Linux analytic, and one of T1685.007's references describes a macOS backdoor, yet neither Linux nor macOS appears on the technique pages. Many coding agents run on macOS and Linux, so tooling that filters ATT&CK by platform may hide these techniques from the machines where they matter most.
• No sub-techniques. Prompt injection through a repository file, an issue, a tool result or an MCP server response all map to one technique, T1698. Your own tagging will need more detail than the IDs give.
• Version 1.0. All five entries are new. Expect descriptions, platforms and mitigations to change in later releases, and record the ATT&CK version alongside any mapping.

What it means for engineering and security leaders

• Use the IDs. Tag agent incidents, threat models and red-team findings with T1698, T1699 and T1700 so they show up in the same reports as everything else your security team tracks.
• Ask your detection team which of DET0927's fields they can fill in today for each AI tool in use. The answer is a list of telemetry you are missing.
• Treat agent instruction and configuration files as protected, given that MITRE now cites one as part of a real campaign.

Practical takeaways

• Write down, per agent or AI tool, the data it may read, the tools it may call and the destinations it may reach. These are the inputs DET0927 asks for.
• Make sure tool calls by agents are logged with the person, the machine, the tool and the outcome, so the application-side analytic has something to run on.
• Alert on writes to agent instruction files such as CLAUDE.md, AGENTS.md and rule files that don't come from a reviewed change.
• Don't filter these techniques out of macOS and Linux coverage just because the platform field omits them.

SpanDock's MCP gateway records every call it handles in Activity: the connector and tool, the outcome and why, the person and computer, the duration, and how many items were redacted. Arguments and results are recorded only if an administrator turns that on, with a notice to the people concerned. That covers the tool-invocation part of an analytic like AN2078 for calls that go through the gateway. The gateway is on the Premium and Enterprise plans.