MITRE ATT&CK v20 coverage, technique by technique

How a technique is scored

Each of the 80 rules in the agent’s data/threats.json carries an attack field: zero or more ATT&CK v20.0 technique ids, each with a level and a one-line reason.

• full a shipped mechanism addresses the technique as an AI agent MoorAI watches performs it.
• partial a shipped mechanism addresses part of it, and the reason states the bound.
• none the technique corresponds to the threat, but MoorAI ships no runtime mechanism for it.

A technique is covered when any rule credits it full, partial when its best credit is partial, and uncovered when it has only none credits or no rule at all. A rule with no technique states why in an attackNote; 33 rules do.

Lanes: who can see each technique

Every in-scope technique sits in one lane. Only the agent lane passes through a surface MoorAI sees: a hook, a model proxy, the MCP proxy or gateway.

Technique by technique, per tactic

One table per ATT&CK tactic, in matrix order. 8 techniques belong to more than one tactic and are listed under each, as ATT&CK lists them; every count on this page counts a technique once. Technique names link to MITRE’s own page.

• Reconnaissance (1)
• Resource Development (4)
• Initial Access (4)
• Execution (12)
• Persistence (11)
• Privilege Escalation (8)
• Stealth (7)
• Defense Impairment (6)
• Credential Access (11)
• Discovery (1)
• Collection (3)
• Command and Control (1)
• Exfiltration (8)
• Impact (5)

Reconnaissance · 1 technique: 0 covered, 0 partial, 1 uncovered

Resource Development · 4 techniques: 0 covered, 1 partial, 3 uncovered

Initial Access · 4 techniques: 0 covered, 1 partial, 3 uncovered

Execution · 12 techniques: 2 covered, 10 partial, 0 uncovered

Persistence · 11 techniques: 0 covered, 9 partial, 2 uncovered

Privilege Escalation · 8 techniques: 0 covered, 7 partial, 1 uncovered

Stealth · 7 techniques: 0 covered, 4 partial, 3 uncovered

Defense Impairment · 6 techniques: 0 covered, 6 partial, 0 uncovered

Credential Access · 11 techniques: 0 covered, 10 partial, 1 uncovered

Discovery · 1 technique: 0 covered, 1 partial, 0 uncovered

Collection · 3 techniques: 0 covered, 3 partial, 0 uncovered

Command and Control · 1 technique: 0 covered, 1 partial, 0 uncovered

Exfiltration · 8 techniques: 0 covered, 5 partial, 3 uncovered

Impact · 5 techniques: 0 covered, 4 partial, 1 uncovered

The 15 uncovered techniques

3 are in the agent lane and 12 outside it. An uncovered technique has no MoorAI mechanism: either a rule names it and credits it none, or no rule names it.

The 13 techniques outside the agent lane

These techniques are real risks for an organisation that runs AI agents, and they do not pass through any surface MoorAI sees. They belong to identity, email and endpoint tooling, or happen on the adversary’s own infrastructure. 1 of them is partial, 0 covered.

EDR · 1

This lane covers host activity outside any agent's tool calls (endpoint detection territory), which no MoorAI hook, proxy or gateway sees.

• T1176.001 Browser Extensions uncovered #4: MoorAI does not inventory or judge browser extensions it did not ship. #28: MoorAI does not judge third-party browser extensions.

Identity · 3

This lane covers sign-ins, tokens and accounts at an identity provider or SaaS tenant, which no MoorAI hook, proxy or gateway sees.

• T1078.004 Cloud Accounts uncovered #26: MoorAI does not see sign-ins to an AI provider; identity-provider territory.
• T1697 Steal Application Specific Passwords uncovered No MoorAI rule names it.
• T1496.004 Cloud Service Hijacking uncovered #38: LLMjacking runs stolen keys from the adversary's own infrastructure, which no hook sees; the circuit breaker stops a looping agent, not a hijacker.

Email · 4

This lane covers mail, voice and messaging that reach a person, not an agent, which no MoorAI hook, proxy or gateway sees.

• T1566 Phishing uncovered #10: coaching only; MoorAI does not inspect inbound mail.
• T1566.004 Spearphishing Voice uncovered #13: voice and SMS lures reach the person, not an agent.
• T1684.001 Impersonation uncovered #11: the impersonation itself is not detected. #12: impersonation by call or video reaches the person, not an agent.
• T1657 Financial Theft partial #11: bec-payment coaches when payment or bank-detail change wording reaches an AI tool; no sender or identity check.

Adversary infrastructure · 5

This lane covers the adversary's own infrastructure, before anything touches the victim, which no MoorAI hook, proxy or gateway sees.

• T1682 Query Public AI Services uncovered No MoorAI rule names it.
• T1683.001 Written Content uncovered #10: the adversary's own content generation happens off the victim's devices. #30: generated invoices are not inspected and bank details are not verified.
• T1683.002 Audio-Visual Content uncovered #12: synthetic voice and video are not analysed. #31: synthetic personas, photos and voices are not analysed.
• T1588.007 Artificial Intelligence uncovered No MoorAI rule names it.
• T1696 Anti-Automation Evasion uncovered No MoorAI rule names it.

The 33 rules with no ATT&CK technique

ATT&CK describes adversary behaviour. Rules for data classes, governance and model error, such as a person pasting customer data into an AI tool, have no technique to map to, and each says so in its own words.

How to use it in a SIEM

Every MoorAI finding names the rule that fired by its threat id: the #39 in a coaching message, threatId in MoorAI’s alerts. Findings stay content-free: a category, a risk level and a keyed hash, never the prompt or the matched text. That makes the threat id the join key.

1. Build a lookup table from data/threats.json: each rule’s id to its attack credits (id, coverage, reason). Rules with no credit carry an attackNote instead.
2. Enrich alerts at ingest by joining on the threat id. In MoorAI alerts the rule is threatId; in the console’s SIEM export (schema 6) the same value is the CEF header Signature ID and the ECS field rule.id; OpenTelemetry carries it as moorai.threat_id. The SIEM event carries owasp, atlas (CEF cs2, the rule’s primary ATLAS technique) and atlasAll (CEF cs6, every ATLAS id the rule credits), but not ATT&CK, so the join to attack happens on your side. A rule with several credits names several techniques; treat them as candidates, not one verdict.
3. Weight by coverage. A partial credit means the alert fired on the bounded part of the technique that the reason describes. A none credit never fires, so it marks a gap to cover elsewhere.
4. Put the gaps on the detection backlog of the tools that can see them: EDR for the uncovered endpoint actions in the agent lane, identity and mail tooling for the techniques outside it.

The lane split matters more than the totals. ATT&CK v20.0 names what agents do. Whether you can see it depends on whether something sits where the agent acts.

Release, sources and related frameworks

Last updated 14 October 2026, for MoorAI agent v1.17.1. The page is built from that release’s data/threats.json, data/attack.js and data/attack-v20-techniques.json; each new agent release that changes the mapping updates it. The same per-technique table is generated in the agent repository as docs/BENCHMARK.md.

• Announcement and method: What ATT&CK v20 means for AI agents (and where MoorAI maps).
• ATT&CK v20.0: ATT&CK updates, MITRE; attack-stix-data v20.0, MITRE, 13 October 2026. Technique ids, names and tactics come from that STIX bundle.
• The rules: data/threats.json, all 80 rules with their ATT&CK credits and reasons, under the MIT licence.
• Related frameworks: MITRE ATLAS agentic-technique coverage, OWASP LLM Top 10, OWASP Agentic Top 10, the threat rule-base and the compliance crosswalk.