Lilli di McKinsey è stata resa pubblica il 9 marzo. La documentazione non riporta alcun danno.

Il 9 marzo 2026, la startup di sicurezza CodeWall ha pubblicato il resoconto di come un agente autonomo da essa sviluppato abbia ottenuto pieno accesso in lettura e scrittura al database di produzione dietro Lilli, l'assistente AI aziendale di McKinsey & Company, in circa due ore e senza una singola credenziale. L'intrusione vera e propria è avvenuta il 28 febbraio; ciò che questa voce dell'archivio degli incidenti AI registra è il giorno in cui è diventata pubblica. Secondo CodeWall, il database raggiunto conteneva 46,5 milioni di messaggi di chat in chiaro, 728.000 file, 57.000 account utente e i 95 prompt di sistema che governano il modo in cui Lilli risponde — e quei prompt si trovavano nello stesso database in cui l'agente poteva scrivere. Le persone presenti nei dati erano i dipendenti stessi di McKinsey: l'azienda afferma che il 72 percento dei suoi dipendenti, oltre 40.000 persone, usa Lilli, che gestisce più di 500.000 prompt al mese. La voce completa, con i suoi livelli di gravità e di affidabilità e i record vicini tra cui si colloca, è nell'Orca AI Incident Archive.

Quell’incipit è la compressione di due tipi molto diversi di affermazione, e la voce dell’archivio è attenta alla differenza. Classifica il record come incidente, confidenza A, non contestato, gravità alta, regione US, tipo INFRA — infrastruttura, non un guasto del modello. Registra inoltre l’assenza di danni reali. È proprio quest’ultimo campo a meritare una seconda lettura, perché non significa che l’esposizione sia stata innocua. Significa che nessun danno è stato accertato sulla base della documentazione, e l’articolo che segue separa ciò su cui due parti concordano da ciò che si basa sul resoconto che una società dà della propria ricerca.

Perché la divulgazione è un evento datato a sé stante

Il riepilogo dell'archivio per questa voce rimanda al 28 febbraio 2026, il giorno in cui l'agente di CodeWall ha individuato la falla, e l'archivio riporta quella data precedente come record separato. La separazione non è burocratica. Prima del 9 marzo, le uniche parti a sapere cosa era successo all'interno di Lilli erano McKinsey e il ricercatore che glielo aveva detto. Dopo il 9 marzo, la dinamica del guasto, la risposta dell'azienda e l'affermazione su ciò che conteneva il database erano tutte di pubblico dominio, dove altri ricercatori di sicurezza potevano contestarle.

Lilli non è un progetto secondario. The Register ha collocato il suo lancio a luglio 2023, con funzionalità di chat, analisi dei documenti e recupero delle informazioni nella ricerca interna dell'azienda. L'articolo di CodeWall, che registra anche da dove viene il nome — la prima professionista assunta dall'azienda, nel 1945 — descrive oltre 100.000 documenti interni alla base. The Register, riportando la divulgazione lo stesso giorno, ha indicato un'adozione pari al 72 percento dei dipendenti e un volume superiore a 500.000 prompt al mese — cifre che McKinsey ha pubblicato essa stessa in un case study pubblico della piattaforma.

Come è entrato l'agente

Il resoconto di CodeWall inizia con la documentazione, non con lo sfruttamento. Il suo agente ha trovato la documentazione API di Lilli esposta pubblicamente e documentata in modo completo: più di 200 endpoint in totale, la maggior parte dei quali richiedeva autenticazione, e 22 che non la richiedevano. Uno di quegli endpoint non autenticati scriveva le query di ricerca degli utenti nel database. I valori erano parametrizzati correttamente, ma le chiavi JSON — i nomi dei campi — venivano concatenate direttamente nell'SQL.

L'agente se ne è accorto perché i messaggi di errore del database riportavano alla lettera quelle chiavi JSON. CodeWall afferma che lo scanner ZAP di OWASP non ha segnalato il problema e che l'agente ha poi eseguito quindici iterazioni cieche, ciascun messaggio di errore gli insegnava qualcosa in più sulla struttura della query, finché non hanno iniziato a restituire righe di produzione reali. Da lì ha concatenato l'iniezione con una vulnerabilità di autorizzazione a livello di oggetto per leggere le cronologie di ricerca dei singoli dipendenti. L'azienda descrive l'intera esecuzione come completamente autonoma, dalla selezione dell'obiettivo al report, senza credenziali e senza intervento umano. Il suo fondatore e amministratore delegato, Paul Price, ha dichiarato a The Register che il processo è stato "completamente autonomo dalla ricerca dell'obiettivo all'analisi, all'attacco e al report".

Quello che CodeWall dice che era dentro

Ogni cifra in questa sezione proviene dal resoconto del 9 marzo di CodeWall. Nessun payload è stato pubblicato, quindi nulla di tutto ciò può essere riprodotto o conteggiato in modo indipendente — un limite che la sezione successiva affronta.

• {{1}}46,5 milioni di messaggi di chat, memorizzati in chiaro, relativi ad attività strategiche, incarichi con clienti, dati finanziari e fusioni e acquisizioni.{{/1}}

• 728.000 file, di cui il documento elenca 192.000 PDF, 93.000 fogli di calcolo Excel, 93.000 presentazioni PowerPoint e 58.000 documenti Word — 436.000 in totale, lasciando i restanti 292.000 non classificati nella stessa frase.

• 57.000 account utente, 384.000 assistenti AI e 94.000 workspace, che CodeWall descrive come la struttura organizzativa completa di come l'azienda utilizza l'AI internamente.

• 95 prompt di sistema e configurazioni del modello per 12 tipi di modello, che mostrano come è stato istruito l'assistente, quali salvaguardie esistevano e quali modelli vi erano alla base.

• 3,68 milioni di chunk di documenti per la generazione aumentata dal recupero, con percorsi di archiviazione S3 e metadati interni dei file — la base di conoscenza che alimenta l'assistente.

• 1,1 milioni di file e 217.000 messaggi di agenti in transito attraverso API di IA esterne, tra cui oltre 266.000 vector store sulla piattaforma di OpenAI.

La scoperta che CodeWall considera il titolo principale non è l'iniezione, ma il punto in cui l'iniezione è arrivata. I prompt di sistema di Lilli erano righe nello stesso database in cui l'agente poteva scrivere, il che significa che un attaccante con lo stesso accesso avrebbe potuto riscrivere le istruzioni dell'assistente con un'unica istruzione UPDATE racchiusa in un'unica chiamata HTTP: nessun deployment, nessuna modifica al codice, nessun file su disco da confrontare. CodeWall afferma che i propri test sono stati solo di verifica: ha letto, non ha scritto, e sostiene che nessun servizio in produzione è stato interrotto.

Quello che McKinsey ha detto lo stesso giorno

Un portavoce di McKinsey ha dichiarato a The Register il 9 marzo che la società ha risolto tutti i problemi individuati da CodeWall entro poche ore da quando ne è venuta a conoscenza. «La nostra indagine, supportata da una delle principali società forensi di terze parti, non ha identificato alcuna prova che i dati dei clienti o le informazioni riservate dei clienti siano stati consultati da questo ricercatore o da qualsiasi altra terza parte non autorizzata», ha affermato il portavoce, aggiungendo che «i sistemi di cybersecurity di McKinsey sono solidi».

Silicon UK ha riportato la stessa posizione il 13 marzo, nel resoconto di Matthew Broersma: McKinsey ha affermato di essere stata «recentemente avvertita di una vulnerabilità relativa al nostro strumento di AI interno, Lilli, da un ricercatore di sicurezza», di aver «confermato prontamente la vulnerabilità e risolto il problema nel giro di poche ore» e che non è stato effettuato alcun accesso a dati dei clienti o a informazioni riservate dei clienti. Quel resoconto osserva inoltre che Price è l'unico dipendente di CodeWall, un dettaglio che vale la pena riportare perché taglia in due direzioni — una realtà di ricerca composta da una sola persona ha trovato in due ore ciò che gli scanner della società non hanno trovato, e una realtà composta da una sola persona sta anche vendendo lo strumento che l'ha individuata.

Due resoconti della soluzione, a un giorno di distanza

La cronologia della divulgazione di CodeWall è la seguente: il 28 febbraio l'agente individua l'iniezione SQL e inizia a enumerare il database di produzione; la catena completa viene confermata lo stesso giorno con 27 risultanze documentate; il 1° marzo viene inviata un'email di divulgazione responsabile al team di sicurezza di McKinsey con un riepilogo ad alto livello dell'impatto; il 2 marzo il chief information security officer dell'azienda conferma la ricezione e chiede prove dettagliate; e il 2 marzo tutti gli endpoint non autenticati vengono corretti e verificati, l'ambiente di sviluppo viene portato offline e la documentazione pubblica delle API viene bloccata. La divulgazione pubblica avviene il 9 marzo.

La versione di McKinsey è che la correzione sia arrivata entro poche ore dalla segnalazione. La cronologia di CodeWall colloca la patch il giorno successivo alla sua email di divulgazione. Entrambe sono documentate. Nessuna delle parti le ha riconciliate, e questo articolo non tenta di farlo: la differenza è tra una correzione in giornata e una il giorno dopo, e la sequenza che conta — segnalazione, poi patch, poi pubblicazione — non è in discussione.

Consolidato, a fonte unica, e il divario tra i due

Stabilito, concordato da entrambe le parti: c'era una debolezza non autenticata nella superficie API pubblica di Lilli; è stata scoperta da un ricercatore di sicurezza esterno anziché da un interno; McKinsey l'ha confermata e corretta; gli endpoint non autenticati sono stati chiusi, l'ambiente di sviluppo è stato messo offline e la documentazione dell'API pubblica è stata bloccata.

Fonte unica, da CodeWall: ogni conteggio sopra, la cronologia di due ore, le quindici iterazioni alla cieca, i 27 risultati documentati e l'affermazione che i prompt fossero scrivibili tramite la stessa iniezione. Niente di tutto ciò è stato smentito. Niente di tutto ciò è stato nemmeno verificato in modo indipendente, perché i payload che avrebbero permesso a qualcuno di controllare non sono stati pubblicati, e Price ha rifiutato di fornire a The Register i prompt esatti usati dal suo team.

Promptfoo, l'azienda di sicurezza AI, ha pubblicato il 10 marzo una valutazione che fissa con precisione il limite: il registro pubblico "non dimostra in modo indipendente ogni conteggio di righe riportato né ogni fase dello sfruttamento", sebbene sostenga la dinamica dell'incidente. Questa è la lettura corretta del materiale disponibile. La classe del bug è ricostruibile; la scala è una testimonianza.

Il danno che il verbale non reca

È qui che la classificazione dell'archivio fa davvero il suo lavoro. Un percorso di due ore verso l'accesso in lettura e scrittura all'interno del database di produzione di un assistente aziendale sembra un caso da registrare come danno, eppure l'archivio non ne registra alcuno. La voce si basa su tre elementi: la dichiarazione di McKinsey secondo cui un'indagine forense di terze parti non ha trovato prove di accesso ai dati dei clienti; la dichiarazione di CodeWall secondo cui i suoi test erano di sola verifica e non hanno causato alcuna interruzione; e l'assenza, nel materiale esaminato per questo articolo, di qualsiasi riscontro contrario.

Non si basa su un audit tecnico indipendente, su una determinazione di un'autorità di regolamentazione o su una notifica di violazione. Nessun identificativo CVE è stato assegnato in alcuna delle fonti esaminate — Lilli è software interno e non un prodotto distribuito, e nessun avviso ne cita uno — e nessuna autorità di vigilanza sembra aver aperto un procedimento. Nel materiale esaminato per questo articolo non è emersa alcuna prova pubblica che i dati siano stati utilizzati, venduti o ulteriormente esposti. È questo che qui significa «nessun danno reale registrato»: un'affermazione probatoria su un dato di fatto, non una conclusione che l'esposizione fosse sicura.

Il divario conta perché il rischio interessante era prospettico. L'accesso in lettura espone ciò che c'era. L'accesso in scrittura al livello del prompt espone ciò che l'assistente direbbe dopo — consigli avvelenati, rimozione dei guardrail, materiale riservato inserito in una risposta che un consulente incolla poi in un documento per il cliente. CodeWall ha descritto tali conseguenze come disponibili a chiunque abbia lo stesso accesso. Nessuno ha dimostrato che siano state messe in atto. Entrambe le affermazioni possono essere vere contemporaneamente: la capacità era reale e il danno non si è concretizzato alla luce delle prove pubblicate da chiunque.

Perché è classificato come infrastruttura e non come un errore del modello

L'archivio etichetta questo record come INFRA, e il record tecnico supporta l'etichetta. Nulla nel resoconto di CodeWall richiedeva di ingannare il modello. Non c'era alcun jailbreak, nessuna prompt injection da un documento, nessun input avversario che l'assistente fosse chiamato a inghiottire. Il punto di ingresso erano documentazione esposta, un controllo di autenticazione mancante e una costruzione SQL non sicura; il modello era semplicemente la cosa più preziosa dietro la porta.

L'analisi di Promptfoo del 10 marzo opera la stessa distinzione dal lato difensivo: Lilli «appare, stando alle informazioni pubbliche, come un incidente di sicurezza applicativa che ha raggiunto un sistema di AI, non un jailbreak del modello», e gran parte di ciò che viene chiamato sicurezza dell'AI è ancora sicurezza del software, sicurezza dei dati e governance della configurazione. La parte specifica dell'AI era il raggio d'impatto, non la violazione — poiché i prompt, le regole di routing e le impostazioni di recupero erano dati applicativi modificabili, l'accesso in scrittura al database è diventato la capacità di cambiare il comportamento dell'assistente senza toccare il codice.

Cosa è cambiato in seguito

I cambiamenti concreti sono quelli descritti da entrambe le parti: gli endpoint non autenticati sono stati chiusi e verificati, l'ambiente di sviluppo è stato messo offline e la documentazione pubblica delle API è stata bloccata. McKinsey ha dichiarato di aver individuato la vulnerabilità, confermata e corretta, e la sua posizione pubblica è che non è stato effettuato alcun accesso ai dati dei clienti.

Ciò che non è cambiato è l’esposizione più ampia descritta da questo incidente. L’articolo di CodeWall si chiude sostenendo che i prompt vengono archiviati in database, fatti passare attraverso API e memorizzati nella cache in file di configurazione, e che raramente ricevono controlli di accesso, cronologia delle versioni o monitoraggio dell’integrità — il che è un’affermazione su un settore, non una conclusione su McKinsey, e va letta come l’argomentazione di un’azienda che vende test automatizzati continui. L’azienda è in anteprima iniziale e cerca partner di progettazione; la divulgazione funge anche da dimostrazione.

Ciò che resta agli atti è più circoscritto e più utile della discussione. Un assistente aziendale, un database di produzione, due ore, nessuna credenziale e una voce di danno che risulta falsa perché entrambe le parti con accesso ai fatti affermano che i dati non sono stati usati. I conteggi appartengono a una di quelle parti. La vulnerabilità appartiene a entrambe.