I team di sicurezza maturi parlano già ATT&CK. Le detection sono scritte contro tecniche, i report di red team sono mappati su tattiche e la copertura si misura in matrice. Quando l'IA entra in produzione, la domanda naturale è: dove si incastra tutto questo?
La risposta breve: in parte si incastra, in parte no — e l'incidente reale accade esattamente nella giuntura.
Due matrici, due domini
MITRE ATT&CK cataloga il comportamento avversario contro i sistemi tradizionali. Le tattiche sono note: accesso iniziale, esecuzione, persistenza, evasione delle difese, movimento laterale, esfiltrazione. Il presupposto è un confine tra codice e dati, e lo sfruttamento avviene quando l'attaccante attraversa quel confine.
MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) cataloga il comportamento avversario contro i sistemi di machine learning. Riutilizza la struttura tattica di ATT&CK, ma aggiunge ciò che nel mondo tradizionale non esiste: ricognizione del modello, accesso all'artefatto ML, avvelenamento dei dati di addestramento, evasione del modello, inferenza di appartenenza, estrazione del modello.
La differenza non è di vocabolario. È di superficie. ATT&CK descrive cosa fa l'avversario nell'infrastruttura. ATLAS descrive cosa fa nel modello.
Dove le matrici si sovrappongono — e dove no
Alcune tattiche hanno una corrispondenza quasi diretta. La ricognizione è ricognizione; l'esfiltrazione è esfiltrazione. Cambia il canale, non l'intenzione.
Altre non hanno un corrispettivo:
- L'avvelenamento dei dati di addestramento non ha equivalenti in ATT&CK. Nel modello mentale classico non esiste un attacco che altera il comportamento futuro di un sistema modificando il materiale da cui apprende.
- L'evasione del modello — costruire un input che il classificatore legge in modo diverso dall'umano — è una classe a sé.
- L'estrazione del modello tramite query è esfiltrazione senza movimento di file. Nessun DLP basato sul contenuto la rileva.
E c'è l'asimmetria inversa: ATLAS non copre bene ciò che accade dopo che il modello è stato compromesso. Un agente di IA che esegue comandi sulla macchina dello sviluppatore è saldamente in territorio ATT&CK — Esecuzione, T1059. La tecnica è classica; è nuovo solo il punto d'ingresso.
L'attacco reale attraversa entrambe
Per questo mappare un incidente di IA su una sola matrice lascia sempre delle lacune. Considera lo schema osservato negli incidenti del 2025–2026 con gli assistenti di codice:
- ATLAS — l'avversario pianta istruzioni in contenuto che l'assistente andrà a consumare. Prompt injection indiretta: nessuna credenziale, nessun exploit, solo testo nel posto giusto.
- ATLAS — le istruzioni manipolano il comportamento del modello, aggirando le restrizioni definite nel system prompt.
- Giuntura — il modello emette una chiamata a uno strumento. Qui l'attacco esce dal dominio del ML ed entra in quello dell'infrastruttura. Nessuna delle due matrici descrive bene questa transizione.
- ATT&CK — lo strumento esegue. Esecuzione di comando, scrittura su file, richiesta di rete. Tecniche note, detection note.
- ATT&CK + ATLAS — persistenza. Se il payload resta in un file di configurazione, è ATT&CK. Se resta nella memoria dell'agente o nel vector store, è territorio ATLAS, e non esiste detection standard.
CVE-2025-53773 (GitHub Copilot) e CurXecute (Cursor IDE) seguono questa forma: ingresso in linguaggio naturale, uscita in esecuzione di comando. GeminiJack ha mostrato la variante zero-click con movimento laterale attraverso un intero ambiente aziendale. Nei 21 incidenti di promptware che abbiamo catalogato tra il 2025 e il 2026, 15 hanno presentato quattro o più fasi concatenate — nessuno di essi sta per intero in una sola matrice.
La giuntura è dove la rilevazione fallisce
Metti insieme la copertura delle due matrici in un ambiente tipico e la mappa di rilevazione risulta così:
- Lato ATT&CK — ragionevolmente strumentato. EDR sull'esecuzione, log di rete sull'esfiltrazione, gestione delle identità sul movimento laterale.
- Lato ATLAS — quasi per nulla strumentato. Poche organizzazioni registrano cosa è entrato nella finestra di contesto, cosa è stato scritto nella memoria dell'agente o cosa è stato indicizzato nel vector store.
- La giuntura — invisibile. Una chiamata a uno strumento emessa dal modello compare nel log come una richiesta legittima dell'applicazione. Il log registra cosa è stato fatto; non registra quale input l'ha originato.
Quest'ultima riga spiega perché il 57% degli incidenti catalogati ha mantenuto persistenza attiva dopo la rilevazione iniziale. L'organizzazione ha rilevato l'effetto sul livello ATT&CK, ha rimediato lì, e il payload è rimasto sul livello ATLAS — nella memoria, nell'indice, nel documento.
Come usarle entrambe nella pratica
1. Mappa i rilievi su entrambe le matrici, non su una. Un report di red team sull'IA che cita solo ATLAS non dialoga con il SOC. Uno che cita solo ATT&CK perde l'origine dell'attacco. Ogni rilievo deve dire: tecnica ATLAS d'ingresso, tecnica ATT&CK d'impatto.
2. Strumenta prima la giuntura. Il controllo con il ritorno maggiore non è la rilevazione del prompt malevolo — è la correlazione. Ogni chiamata a uno strumento avviata da un modello deve essere loggata con l'identificatore dell'input che l'ha originata. Senza questo, nessuna indagine su un incidente di IA arriva alla causa radice.
3. Estendi la matrice di copertura esistente. Se il team misura già la copertura ATT&CK, aggiungi le colonne ATLAS allo stesso pannello. Due matrici in due report separati garantiscono che nessuno guardi l'intersezione.
4. Tratta la persistenza in ATLAS come persistenza vera. Memoria dell'agente, embeddings e regole di progetto sono meccanismi di persistenza con tutte le proprietà rilevanti: sopravvivono alla sessione, influenzano l'esecuzione futura, non vengono ispezionati. Meritano revisione, scadenza e log — gli stessi controlli che applicheresti a un task pianificato.
Il ruolo di ciascun framework
Nessuna delle due matrici è un programma di test. Sono tassonomie — servono a nominare, comunicare e misurare la copertura, non a dire cosa eseguire.
Per questo i nostri esercizi usano la Promptware Kill Chain come sequenza operativa e mappano ogni fase di ritorno su ATLAS e ATT&CK. La kill chain definisce il percorso; le matrici danno il linguaggio comune con il SOC.
Combinati, i tre rispondono alla domanda che conta per il consiglio di amministrazione: non "quante tecniche copriamo", ma "se l'avversario entra dal modello, fin dove arriva — e a che punto lo vediamo".
Per mappare i tuoi sistemi di IA contro ATLAS e ATT&CK, scopri il nostro Red Team per l'IA oppure parla con il team.