A coverage heatmap lands in your inbox. Three new cells on it are shaded green, labelled with the AI-related entries from the latest ATT&CK release, and somebody on the board has already seen it. The question you will be asked is not what the framework contains. It is whether the agent that reads your support tickets can be made to do something it should not, and whether you would see it happen. Those are different questions, and the MITRE ATTACK v20 AI techniques answer only the first one by halves.
This piece treats the AI entries as a test plan rather than a taxonomy lesson. For each behaviour: what the technique presumes an attacker actually achieved, how to reproduce that consequence in a real stack, and what evidence survives a sceptical reviewer.
What ATT&CK v20 Actually Added for AI
The shape of the addition matters more than the labels. ATT&CK has moved to describe adversary behaviour that involves AI components inside ordinary enterprise environments: instructions delivered to a model directly by a user, instructions delivered indirectly through content the model ingests, the use of AI systems to assist or carry out collection and exfiltration, and the poisoning of AI-produced results so that downstream decisions change.
Before you put any of this in a report, pull the exact technique names, IDs and sub-technique structure from attack.mitre.org for the specific version you are mapping to, and cite that version number in the document. IDs get renumbered, techniques get split into sub-techniques, and a vendor datasheet is not a source. A wrong ID in a report is worse than no ID, because it invites the reader to go and check, and then to distrust everything else.
Why these entries sit in the Enterprise matrix
AI components are no longer a research annexe. A retrieval system reads the same SharePoint your staff read, an agent holds an API token with the same scopes a junior analyst would get, and a summarisation step sits between a mailbox and a human decision. Attacks against those components are ordinary intrusion steps, with ordinary consequences: access, execution, collection, exfiltration. Putting the behaviours in Enterprise says something useful about where they belong in a kill chain.
What the update does not do
It describes behaviour. It does not tell you whether your own agent is exploitable, it does not rank your exposure, and it does not convert into a control set. The entries list mitigations, and here is the first thing people get wrong: a mitigation listed against a prompt injection technique is a reduction, not a block. The model cannot separate its instructions from the data it reads. Input filtering and a sterner system prompt lower a success rate; they do not remove the technique. “Mitigation implemented”and “technique prevented”are two different claims, and a map that renders both as the same green cell will mislead whoever reads it.
ATT&CK v20 or ATLAS? Which Framework Answers Which Question
Confusing them is the first mistake. MITRE ATLAS covers adversarial machine learning against the model and its lifecycle: training data manipulation, model theft and extraction, evasion of a classifier, supply chain compromise of weights or dependencies. The AI entries in the Enterprise matrix cover the intrusion around and through the AI component: how untrusted content reaches it, what executes with the agent’s credentials, what data is collected, how it leaves.
Plenty of real findings belong in both. An attacker who poisons a knowledge base to steer answers has done something ATLAS describes at the data layer and something ATT&CK describes at the business-impact layer. Present that as one finding with two references, not as two findings. Double-counting inflates a risk register and gets noticed at the second read.
The mapping error to avoid is the opposite move: filing a model-level weakness as an enterprise technique because the report looks thinner without it. A jailbroken chatbot that produced an off-policy paragraph has not performed exfiltration. Map it where it belongs, or do not map it.
Turning a Technique ID Into a Test Case
Start with the system, not the matrix. Draw the permissions the agent holds, every channel that feeds it text, every tool it can call and every surface its output renders on. Half the AI entries will be unreachable in a given architecture, and saying so in the report is a finding of its own. A read-only RAG assistant with no tool calling has a different exposure to an agent with a Jira token and an SMTP relay.
For each technique that is reachable, write down the consequence the entry presumes before you write a payload. Data left the boundary. A tool ran. An answer changed. That sentence becomes the pass or fail condition, and it keeps the test honest, because the alternative is testing to output. A model producing a forbidden sentence is not exfiltration. Jailbreak transcripts get mapped to technique IDs far too readily, and the ATT&CK entries presume an action on objective, so the honest mapping needs the record that left the boundary or the tool-call log that shows execution, not the model agreeing to help.
Scope the chain across the model boundary. The injection arrives as untrusted data; the execution happens with the agent’s credentials. Those are two different halves of the same finding, and the write-up should name the permission that made it possible, because that is the control which changes the outcome. The wording of the payload is disposable. The token scope is not. Our AI red teaming methodology walks through the scoping stage in more detail.
Indirect Prompt Injection: Proving Blast Radius, Not Compliance
The root cause resists fixing because it is structural. Instructions and data arrive in the same channel, in the same format, with no reliable marker between them. That is the whole vulnerability, and it is why OWASP lists prompt injection as LLM01 in its Top 10 for LLM Applications rather than as one issue among many. The longer treatment is in our piece on why prompt injection defines LLM security.
Place payloads in the channels the agent actually consumes. Ticket bodies. Shared documents the retrieval step indexes. Email threads it summarises. Web pages a browsing tool fetches. Repository files a coding agent reads. A payload typed into the chat box tests the chat box; a payload in a ticket tests the system.
The confused deputy pattern
Take an internal support agent that reads ticket bodies and can call a customer lookup tool. A crafted ticket instructs it to run the lookup for an unrelated account and append the result to the public reply. The agent is the confused deputy: it holds permissions the attacker does not, and it has been persuaded to use them on the attacker’s behalf. The model did nothing anomalous by its own lights. It followed instructions.
Demonstrate it with the least damaging proof that still shows real impact. A single synthetic customer record, seeded for the test, appearing in a channel the attacker can read. Not a bulk pull. Not live personal data. The point is to establish that the boundary does not hold, and one record does that as well as ten thousand. The same pattern through tool-calling infrastructure is covered in our walkthrough of proving blast radius on MCP servers.
Evidence that survives review has four parts: the request that carried the payload, the tool call that executed, the artefact that moved, and the permission scope that allowed it. Screenshots of model text alone get sent back.
AI-Enabled Exfiltration and Result Poisoning: The Two Most Teams Skip
Egress often runs through the interface itself. A chat client that renders markdown images will fetch a URL when it renders, and a URL can carry conversation content in a query parameter. No network beacon from the model, no outbound connection from the server, just a browser doing what browsers do. Link previews, outbound webhooks and automated summary emails all behave the same way. Where rendered output has no egress allow-list, this maps cleanly to the exfiltration behaviour and it still works in plenty of production clients.
Result poisoning gets skipped because it is slower to prove. Index one crafted page alongside legitimate policy documents and ask the question it was written to influence: a refund threshold, a pricing tier, an approval route. Then ask it twenty times. One screenshot of a wrong answer proves nothing, because the next run may be right; a drift rate across repeated runs proves plenty. Among the RAG security risks worth separating out, provenance is the sharpest: if the pipeline does not log which chunks informed which answer, nobody can attribute a bad answer to a bad document after the fact, and the incident becomes unreconstructable.
Design for the assumption that the model will be fooled. Scope the agent’s credentials to the task rather than the user. Require human approval on irreversible actions, meaning anything that spends money, sends externally, deletes or grants access. Allow-list egress destinations at the rendering layer. The NCSC guidelines for secure AI system development take the same line, as does the NIST AI Risk Management Framework on documented control boundaries. Our notes on securing AI agents and their tool use cover the permission side in practice.
Coverage Claims, Non-Determinism and Write-Ups That Hold Up
Per-technique pass or fail does not survive non-determinism. The same payload against the same endpoint will succeed sometimes and fail other times, and a client who retests will contradict your report within a week. Record the number of trials, the observed success rate, the model name and version, the system prompt in force and the harness used. Report a rate, with its conditions, not a tick.
Detection mapping is unverifiable without telemetry. Most organisations cannot evidence detection of these behaviours because they log nothing useful: no tool-call records, no retrieval provenance, no prompt and response capture. Write the telemetry gap up as a finding in its own right, before anybody claims coverage. A green detection cell over a system with no logs is a decoration.
Question any tooling that advertises coverage of the MITRE ATTACK v20 AI techniques. The test question is where each reported fact came from. A model asserting that an endpoint is vulnerable is not a measurement; a captured tool call and a retrieved artefact are. That distinction decides whether the output is actionable or merely confident, and it is the same scepticism we apply to AI-assisted pentest tools generally. There is a great deal of noise in this space.
For the board, keep each finding to five fields: the technique reference and version, reproduction steps, the observed consequence, a confidence statement with the trial count, and the fix that changes the outcome. Auditors want the second and fifth. Boards want the third.
The Short Version
The AI entries in ATT&CK describe behaviour, and the MITRE ATTACK v20 AI techniques are only useful to you once each one is restated as a consequence you can reproduce in your own stack. Test to the consequence, not the sentence. Name the permission, not the payload. Run each case several times and report a rate. Treat missing tool-call logs and retrieval provenance as findings before anyone claims detection. And remember that a mitigation against prompt injection reduces a success rate; it does not close the technique, however much that dents the heatmap.
Frequently Asked Questions
What are the AI techniques in MITRE ATT&CK v20?
They describe adversary behaviour involving AI components in enterprise environments: instructions supplied directly to a model, instructions delivered indirectly through content the model ingests, AI-assisted collection and exfiltration, and the poisoning of AI-produced results. Technique names and IDs change between releases, so take them from attack.mitre.org for the exact version you are citing rather than from a vendor summary.
Is MITRE ATT&CK v20 the same thing as MITRE ATLAS?
No. ATLAS covers adversarial machine learning against the model and its lifecycle, including training data manipulation, model extraction, evasion and supply chain compromise. The ATT&CK Enterprise entries cover the intrusion around and through AI components. A finding can reference both, but it should be reported once.
How do you test indirect prompt injection against an ATT&CK mapping?
Place the payload in a channel the system genuinely consumes, such as a ticket body, an indexed document or a fetched web page, and define success as the consequence the technique presumes rather than the model’s reply. Capture the request, the tool call, the artefact that moved and the permission scope that allowed it. A transcript on its own is not a mapping.
Can you claim detection coverage for the new AI techniques?
Only where you can show the telemetry that would detect them: tool-call records, retrieval provenance, and prompt and response capture. Without those, a detection claim cannot be verified by anyone, including you. Record the gap as a finding first, then revisit coverage once logging exists.
Does mapping AI findings to ATT&CK v20 actually help a team fix anything?
It helps with communication and with spotting where a behaviour sits in a chain, which matters for detection engineering and for board reporting. It does not tell you whether your agent is exploitable, and it does not prioritise your remediation. The fix usually comes from the permission model and the egress path, not from the technique reference.