When a detection may claim an AI attack name — and when it may not
MITRE's AI-focused matrix, ATLAS, imports techniques from the enterprise matrix. Importing one does not make a detection an AI detection. This note is the test we adopted for deciding which of our detections may carry an ATLAS name, the four that qualified, and the one we refused twice.
The problem is that importing is not scoping
ATLAS describes attacks on AI systems. Many of its rows are imports: the same adversary behaviour the enterprise matrix already names, restated because it matters on a machine that serves or trains a model. An import inherits its twin's description, and inheriting a description does not add an AI condition to it.
So a detector that fires on credential theft could be relabelled with an AI name whenever it happens to fire on a machine that runs a model. That relabelling is nearly free to implement and it is usually wrong. It would let us report AI-attack coverage that consists of ordinary detections standing near a GPU.
The test we settled on is narrow, and it is a property of the ATLAS row rather than of our detector:
Read the row. If its text says nothing about AI beyond the citation, then the AI-ness of any claim can only come from the machine the act happened on, and routing the claim through what we know about that machine is honest. If the row's text does name an AI condition, that condition is the claim, and we have to meet it on its own terms or decline.
The four rows that qualified
Each was admitted only after its ATLAS description was read at the source on the date shown. Two carry an AI clause of their own and two do not, which is the point: the test admits both, for opposite reasons.
The ATLAS text contains no machine-learning word at all — its one illustrative clause names SSH keys. So the AI-ness cannot come from the row, only from the machine, and the route is honest. This is also the read that overturned an earlier assumption of ours: we had expected the row to justify recognising model artefacts by file extension, and it does not. Doing that would have asserted a scope MITRE never wrote.
Here the row's own text does add an AI clause: the credentials taken can be used to reach other AI services, and to reach tools and data that are part of the AI development lifecycle. Note what that scopes by — what the credentials reach, not the machine they came from. We admitted it because our detectors observe the material itself.
Pure enterprise text — virtual-machine artefacts, registry substrings, hardware-address prefixes, two process names. Its only AI touch is a citation link, which is a reference and not a scope. Admitted on the same grounds as the first row, and worth having because the act itself is about the analysis environment: a payload fingerprinting its host before detonating, on a machine that serves a model, is checking whether the AI system it landed on is real or an analyst's.
The first row here whose own text supplies the AI clause rather than borrowing it: enumerating processes can identify the AI software stack, which leads an adversary to new targets. That makes the route unusually tight rather than merely permissible. The classification we consume is earned from an observed model-serving process, so on exactly the machines where this fires, the enumeration returns the process that earned the classification. The claim and its evidence are the same fact seen from two sides.
The row we refused twice
One row, covering the use of alternate authentication material, was blocked on one ground, had that ground expire, and is still refused on a better one. We think this is the most useful part of the note, because it is the case where the honest answer changed and the verdict did not.
First refusal: we did not detect the twin
The original reason was mechanical. The enterprise technique it imports was not something we detected, so there was nothing to relabel. That is a fact about our build, and facts about a build expire.
The expiry
It did expire. A separate piece of work earned that technique — specifically the pass-the-hash and pass-the-ticket variants — and the original objection evaporated. A published claim of ours had become stale, and the row was now eligible under the only test we had written down.
Second refusal: the row names a condition we cannot meet
Re-reading the row at the source produced a different answer. Its AI clause is a single sentence, and it says that AI services commonly use alternate authentication material as the primary way users make queries, which is what makes them vulnerable. That scopes by the material, not by the machine.
The material our detectors observe is a Windows credential hash or a Kerberos ticket on a command line. The material that sentence describes is the token that queries an AI service. Routing this row through what we know about the machine would therefore assert that lateral movement on a computer which happens to serve a model is this technique — when the row's own AI clause points somewhere else entirely.
This is the test returning the opposite verdict from the first row's, on the same reasoning. The first row has no AI clause, so its AI-ness could only ever come from the machine and the route is honest. This row has one, and it names a content condition our platform cannot currently meet.
What it would take, priced
We checked rather than guessed, and it is not one search away. Our generative-AI decoder emits action, actor, agent, application, client, conversation, decision, model, provider, request identifier, tool and user — nothing that carries authentication. The large-language-model security record carries user, tenant, prompt, completion, token counts, tool calls and retrieval documents, with no credential field at all.
So the unlock needs a new field on that stream — the format of the presented key, or a masked token identifier — after which the model-platform key formats we already recognise become the join. Until that field exists, the row stays refused. A related row covering application access tokens stays blocked on the original ground, because its twin genuinely is not something we detect.
One measurement worth the space
A single detector of ours reports a burst of discovery activity, and that burst can legitimately be attributed to twenty different enterprise techniques. Of those twenty, exactly one is imported by ATLAS — process discovery, the fourth row above. The burst's primary label is not imported at all.
Two consequences follow, and both are load-bearing. Attribution has to be read across the whole set a finding carries rather than just its first entry, or the row is unreachable in practice. And a burst that enumerates hosts and network state without ever listing processes correctly claims nothing — which is the behaviour we want, and the reason we measured instead of assuming.
Why the reasoning is published and not just the table
A coverage table can be read selectively. The reasoning behind each row cannot: it either survives being checked against the source or it does not. Every row above names the date it was read, so a reader who disagrees knows exactly what to re-read. We would rather be corrected on a dated reading than trusted on an undated claim.
We are not MITRE. Every verdict here is our reading of a published description on a stated date, and the descriptions can change. A row admitted today can become wrong without anyone editing our code.
Process discovery is attributed from two Windows command idioms, and our Linux discovery set carries no process-enumeration idiom at all. So that ATLAS claim cannot currently be earned on Linux — on the platform much of the AI estate actually runs on.
Nothing here adds a detector, a threshold or a severity level. Every detection fires exactly as it did before, at the same severity; the only difference is that an act on a machine running a model also names a second matrix. The label already says what an escalation would be trying to say.
This work is about what a detection may honestly be called. It does not widen what we detect. Measured detection coverage, and what blocks the rest, is on the proof page.