ATT&CK Finally Has a Name for Prompt Injection. Now Write the Detection.

The headline version of MITRE ATT&CK v20 is "MITRE adds AI attacks." It's accurate, and it's also probably the least interesting way to read the release. AI-specific attack knowledge has lived in MITRE ATLAS for years. What changed on October 13 is that prompt injection now has an Enterprise ATT&CK ID, and Enterprise IDs are what a SOC's detection rules, coverage heatmaps, incident tickets, and vendor dashboards actually key on. So this piece has two goals that pull against each other. We wanted to give MITRE real credit for where it put these techniques, because the placement is the smartest part of the release, and we wanted to be honest that most of what a defender needs on day one (detections and real procedure examples) is not there yet.

What v20 actually added

ATT&CK moved from v19.2 to v20.0 on October 13, 2026 (MITRE ATT&CK updates; MITRE ATT&CK blog). In the Enterprise matrix it added nine techniques and sub-techniques, and the changelog confirms that five of them are about AI (v20 changelog). The other four don't seem like filler either. There is a new Anti-Automation Evasion technique (T1696) for automating or avoiding CAPTCHAs, and Steal Application Specific Passwords (T1697), which suggests MFA bypass is still very much a business.

ID	Name	Tactic	Detection strategy in v20
T1699	Direct Prompt Injection	Execution	none yet
T1698	Indirect Prompt Injection	Execution	none yet
T1700	AI-Enabled Exfiltration	Exfiltration	DET0927, three analytics
T1608.007	Stage Capabilities, AI Result Poisoning	Resource Development	DET0922, which says no target-side analytic exists
T1685.007	Disable or Modify Tools, Impair Autonomous Defenses	Defense Impairment	none yet

Two quieter changes belong in the same conversation. MITRE rewrote T1195.001, the software supply chain technique, so it now covers IDE configuration files and AI agent skill files like SKILL.md that run with the permissions of the agent process. And it added a new campaign, C0064, an AI-assisted breach of Mexico's government infrastructure between December 2025 and February 2026 in which the operators used Claude Code and GPT-4.1 (v20 changelog). If you only read the five new IDs, you might miss that MITRE is also treating agent tooling as part of the software supply chain. In my opinion, that may turn out to matter more.

Why I care where these landed

I have a soft spot for ATT&CK, and I should admit it up front. Tony G and I came back from MITRE ATT&CK Con in 2018 genuinely impressed (ATT&CK Con), and for a while we ran a two-day workshop that walked students through an offensive mission technique by technique against the ATT&CK knowledge base, using Metasploit and Meterpreter, Unicorn, and other tools, and then turned around and covered the defensive side (A Walk Down Adversary Lane). The lesson that workshop kept teaching, in my experience, was that the framework's value sits in the shared language far more than in the list. When the red team says "T1059" and the detection engineer hears the same thing, an exercise turns into a backlog.

That's why the placement matters more to me than the count. MITRE filed both prompt injection techniques under Execution, not Initial Access. That appears to be a statement about the model. It says the LLM is an execution environment, the prompt is the payload, and the tools the model can call are the capabilities that payload inherits. It's most likely the same mental model we use for PowerShell or a macro. For years the industry has argued about whether prompt injection is "really" a vulnerability, a social engineering trick, or a model quality problem. ATT&CK just answered with a tactic column, and I tend to believe it's the right answer.

ATLAS still exists and still goes deeper on model-specific attacks; the closest equivalents to the new IDs are AML.T0051.000 and AML.T0051.001 for direct and indirect injection and AML.T0086 for exfiltration through agent tool calls (ATLAS data). But in most cases SIEM rule packs, breach-and-attack-simulation tools, and coverage reports don't key on ATLAS IDs. As far as we could tell, the v20 technique pages don't cross-reference their ATLAS siblings either, so for now your team will probably have to maintain that mapping itself.

Direct versus indirect is the whole game

If you take one thing from v20, take the split between T1699 and T1698, because it moves the trust boundary to a place most security programs have probably never looked.

Direct prompt injection (T1699) is the attacker typing into the model's interface. MITRE's description is the familiar list of "ignore previous instructions," role-play, and pretending to be a researcher or a privileged user to get content or actions the guardrails should block (T1699). The procedure examples are the interesting part. In C0064, a file-write request inside a prompt got Claude Code to write a document full of penetration testing scripts. In C0062, the AI-orchestrated espionage campaign Anthropic reported, the operator posed as a security firm doing defensive testing. In both cases the attacker was the user. That's important, because it suggests your identity controls still mean something. You know who typed the prompt.

Indirect prompt injection (T1698) is a different animal. The attacker never touches the model. They plant instructions in a web page, a document, an email, a ticket, or a code comment and wait for someone's agent to read it (T1698). MITRE's references include "Clinejection," where an injected issue turned an AI coding bot into a GitHub Actions supply-chain attack. Here the user is the victim, the content is the attacker, and the agent sits in between holding the user's permissions. It appears to be the confused deputy problem, rebuilt in natural language.

The mitigations MITRE lists for the two are telling, and they seem almost all architectural rather than model-level. Enforce authorization "outside the model" (M1038), require human approval for privileged AI actions (M1026), give agents their own least-privilege identities (M1018, M1022), and segment where agents can send data (M1030). Notice what isn't on the list, which is "train a better model." MITRE is quietly agreeing with what we said about Meta's agents last week, that the guardrail has to live in the product, not the model.

Exfiltration through the tools you approved

T1700 is where v20 gets practical. MITRE describes adversaries using injection to make enterprise agents exfiltrate data by weaponizing "sanctioned tools available to the agent," and it notes that Exfiltration Over Web Service (T1567) will often apply at the same time (T1700). The agent probably doesn't need malware. It needs a send-mail tool, a file-share connector, or the ability to render a link with your data in the query string, which is the pattern we saw in EchoLeak and CamoLeak. MITRE doesn't cite either of those on the T1700 page, but they're the textbook shape of the technique.

The good news is that this is the one AI technique where MITRE shipped real detection logic. DET0927 has three analytics. The SaaS version (AN2078) looks for an agent touching a protected data scope, then invoking a tool or API with that data, and then a destination recording a transfer outside the authorized AI data flows. It uses SaaS audit logs and, for AWS, Bedrock agent traces. The Windows and Linux versions (AN2079 and AN2080) chain an AI-associated process reading out-of-scope data with the same process lineage spawning something that can move data and connecting outside approved endpoints, using Windows Security events 4663, 4670, and 4656, PowerShell logging, Sysmon, and auditd (v20 changelog).

Read the analytic carefully and you'll notice it's full of placeholders like $ProtectedDataScope$, $AuthorizedAIDataFlows$, and $AuthorizedAIEndpoints$. I'd call that MITRE being honest that the hard part is yours, rather than a flaw. Most organizations I've seen likely can't yet answer "which identity is our agent, and what is it allowed to read and send?" Until you can, the analytic has nothing to compare against. So the first detection engineering task for T1700 is really an inventory task. Give every agent its own identity, write down what it may touch and where it may send, and log both.

Poisoning the answer, and the analytic that says no

T1608.007, AI Result Poisoning, is probably the technique I'd show an executive. Adversaries seed the public web with fake sites, fabricated claims, and sources that look independent but reinforce each other, so AI search and assistants retrieve, cite, or recommend attacker-controlled material (T1608.007). MITRE draws the line against SEO poisoning neatly. SEO poisoning tries to move a link up a results page. This targets systems that collapse many sources into a single confident answer, and it needs no access to the model at all.

And then MITRE does something I wish more vendors did. The detection strategy, DET0922, says plainly that there is "no target-side behavioral analytic," because enterprise telemetry can't tell deliberate staging from ordinary publishing (v20 changelog). That's a null result, published on purpose. It's also arguably the most useful sentence in the release, because it tells you where not to spend your SIEM budget. If you want visibility, look outside your perimeter. Monitor for lookalike domains and brand impersonation, log the links your users click out of AI answers at the web proxy, and treat domains that show up in AI-recommended answers as a threat-intel feed of their own.

When the malware talks to your AI analyst

T1685.007, Impair Autonomous Defenses, is the one that should probably make SOC leaders a little uncomfortable. Adversaries use indirect injection to make LLM-assisted analysis ignore data, miss alerts, abort early, or shut itself off. MITRE describes malware carrying fake prompt scaffolding, including fake system messages that convince the model it hit an error, and cites SentinelOne's research on macOS.Gaslight, a backdoor whose prompt injection targets the analyst rather than the sandbox (T1685.007). I have not independently analyzed that sample, so I'm relying on MITRE's description of it.

The parent technique is worth noticing too. T1685, Disable or Modify Tools, came out of v19's restructuring, which retired Defense Evasion, gave its ID to a new Stealth tactic, and created a Defense Impairment tactic for attacks on your security tooling (TA0112). So MITRE has put "talk the AI triage agent out of its job" in the same family as killing an EDR agent or clearing event logs. That seems exactly right to me. If an AI agent can close an alert, it's most likely a security control, and controls get attacked.

MITRE's main mitigation here is audit (M1047), which means keeping a record of analysis status, provenance, and why the analysis ended. My practical version is shorter. Never let an AI verdict be the only gate that closes an alert, compare AI triage results against a non-LLM pipeline on a sample of cases, and write a few simple string rules for fake "system" or "error" text inside samples. Malware that addresses your model by name is not subtle (it's just new).

What's missing, plainly

v20 is a good release with honest gaps, and it's better to know them before your coverage report does. Three of the five AI techniques ship with no detection strategy at all, and the fourth's strategy is that detection isn't possible on the target side. Only T1699 has procedure examples, so mapping your incidents to the others will likely involve some judgment. The listed platforms for most of the new techniques are SaaS and Windows, even though the Gaslight backdoor MITRE cites is macOS malware and one of MITRE's own T1700 analytics targets Linux. And the ATT&CK pages don't point to their ATLAS counterparts, which appears to leave two MITRE frameworks describing overlapping behavior with different IDs.

None of that is a reason to ignore v20. It's a reason to read the coverage heatmap your vendor shows you next quarter with some skepticism. A green cell on T1698 will most likely mean someone wrote a rule. It may not mean the rule can see an instruction hidden in a PDF your agent summarized.

What I'd do this quarter

If you run detection engineering, add the five IDs to your ATT&CK Navigator layer now, mark them honestly (mostly gaps), and use T1700's DET0927 as your first build because it's the only one with real logic. Before you write it, inventory your agents. Give each one a dedicated identity, document what it may read and where it may send, and make sure the LLM gateway, the tool-call log, and any MCP server logs are flowing into the same place as your SaaS audit and endpoint telemetry.

If you run a red team, the direct and indirect split is your new test plan. Direct injection tests your guardrails and your identity controls. Indirect injection tests everything your agents read, which means seeding a test document, a test email, and a test ticket with instructions and watching what your agents do with them. Then report it with the new IDs, so the blue team can find it in the same backlog as everything else.

The model became an execution environment

The real news in ATT&CK v20 is not five new rows in a matrix. It's that the most widely used adversary framework in the industry now treats a language model the way it treats a shell. Text probably became code the moment we gave models tools, and the framework just caught up with that. That changes who owns the problem. Prompt injection is no longer only the AI team's model-quality issue. It's the SOC's execution problem, the identity team's least-privilege problem, and the data team's egress problem, all at once.

We spent two decades teaching people not to run untrusted code. Now we're building systems whose whole job is to read untrusted text and act on it. ATT&CK finally has a name for what happens next. The detections are your job.

Further reading

• MITRE ATT&CK, v20 release notes and detailed changelog
• MITRE ATT&CK blog, ATT&CK v20 (Oct 13, 2026)
• Technique pages: T1699, T1698, T1700, T1608.007, T1685.007
• MITRE ATLAS, data release 2026.09
• OWASP, LLM01:2025 Prompt Injection
• Coverage: GBHackers, Cyber Press, Skillthropic, SecurityWeek
• Earlier on this site, How Attackers Attack AI and What is the MITRE ATT&CK Framework?