McKinsey Lilli offentliggjordes den 9 mars. Protokollet visar ingen skada.

Den 9 mars 2026 publicerade säkerhetsstartupen CodeWall sin redogörelse för hur en autonom agent som företaget hade byggt fick full läs- och skrivåtkomst till produktionsdatabasen bakom Lilli, McKinsey & Companys företagsövergripande AI-assistent, på ungefär två timmar och utan en enda autentiseringsuppgift. Själva intrånget skedde den 28 februari; det som den här posten i AI-incidentarkivet dokumenterar är dagen då det blev offentligt. Enligt CodeWall innehöll databasen som agenten nådde 46,5 miljoner chattmeddelanden i klartext, 728 000 filer, 57 000 användarkonton och de 95 systemprompter som styr hur Lilli svarar – och dessa promptar låg i samma databas som agenten kunde skriva till. Personerna i datan var McKinseys egna anställda: företaget uppger att 72 procent av dess anställda, över 40 000 personer, använder Lilli, som hanterar fler än 500 000 promptar i månaden. Den fullständiga posten, med sina allvarlighets- och konfidensgrader och de närliggande poster som den ingår bland, finns i Orca AI Incident Archive.

Den där inledningen är en sammanpressning av två mycket olika slags påståenden, och arkivposten är noggrann med skillnaden. Den klassar posten som en incident, konfidens A, inte omtvistad, allvarlighetsgrad hög, region USA, typ INFRA – infrastruktur, inte ett modellfel. Den registrerar också att ingen verklig skada föreligger. Det sista fältet är det som är värt att läsa två gånger, eftersom det inte betyder att exponeringen var ofarlig. Det betyder att ingen skada fastställdes i posten, och artikeln nedan skiljer mellan vad två parter är överens om och vad som vilar på ett företags redogörelse för sin egen forskning.

Varför offentliggörandet är en egen daterad händelse

Arkivets sammanfattning för den här posten pekar tillbaka på 28 februari 2026, dagen då CodeWalls agent hittade felet, och arkivet har det tidigare datumet som en separat post. Uppdelningen är inte byråkratisk. Före den 9 mars var de enda parter som visste vad som hade hänt inne i Lilli McKinsey och den forskare som hade berättat det för företaget. Efter den 9 mars fanns felets karaktär, företagets svar och påståendet om vad som fanns i databasen allt i den offentliga dokumentationen, där andra säkerhetsforskare kunde argumentera emot dem.

Lilli är inte ett sidoprojekt. The Register daterade utrullningen till juli 2023, med chatt, dokumentanalys och informationssökning i företagets interna forskning. CodeWalls artikel, som också anger var namnet kommer ifrån – den första professionella kvinnan som företaget anställde, 1945 – beskriver mer än 100 000 interna dokument bakom det. The Register rapporterade om avslöjandet samma dag och angav att 72 procent av de anställda hade anammat det och att volymen översteg 500 000 prompter i månaden – siffror som McKinsey själva har publicerat i en offentlig fallstudie om plattformen.

Hur agenten tog sig in

CodeWalls redogörelse börjar med dokumentation, inte exploatering. Dess agent hittade Lillis API-dokumentation offentligt exponerad och fullständigt dokumenterad: över 200 ändpunkter totalt, de flesta kräver autentisering, och 22 som inte gjorde det. En av dessa oautentiserade ändpunkter skrev användares sökfrågor till databasen. Värdena parametriserades korrekt, men JSON-nycklarna – fältnamnen – sammanfogades direkt i SQL.

Agenten märkte det eftersom databasfelmeddelanden återspeglade dessa JSON-nycklar ordagrant. CodeWall säger att OWASP:s ZAP-scanner inte flaggade problemet, och att agenten sedan körde femton blinda iterationer, där varje felmeddelande lärde den lite mer om frågans utformning, tills levande produktionsrader började komma tillbaka. Därifrån kedjade den ihop injektionen med en behörighetsbrist på objektnivå för att läsa enskilda anställdas sökhistorik. Företaget beskriver hela körningen som helt autonom, från målval till rapport, utan inloggningsuppgifter och utan människa i loopen. Grundaren och vd:n Paul Price sade till The Register att processen var "helt autonom från att undersöka målet, analysera, attackera och rapportera."

Vad CodeWall säger var inuti

Varje siffra i det här avsnittet kommer från CodeWalls rapport från 9 mars. Inga nyttolaster publicerades, så inget av det kan återskapas eller räknas oberoende — en begränsning som nästa avsnitt behandlar.

• 46,5 miljoner chattmeddelanden, lagrade i klartext, som omfattar strategiarbete, kunduppdrag, finansiell information samt fusioner och förvärv.

• 728 000 filer, varav redogörelsen specificerar 192 000 PDF-filer, 93 000 Excel-kalkylblad, 93 000 PowerPoint-presentationer och 58 000 Word-dokument – 436 000 totalt, vilket lämnar de återstående 292 000 oklassificerade i samma mening.

• 57 000 användarkonton, 384 000 AI-assistenter och 94 000 arbetsytor, vilket CodeWall beskriver som den fullständiga organisatoriska strukturen för hur företaget använder AI internt.

• 95 systempromptar och modellkonfigurationer fördelat på 12 modelltyper, som visar hur assistenten instruerades, vilka skyddsräcken som fanns och vilka modeller som låg bakom den.

• 3,68 miljoner dokumentchunkar för hämtningsförstärkt generering, med S3-lagringsvägar och intern filmetadata – kunskapsbasen som förser assistenten.

• 1,1 miljoner filer och 217 000 agentmeddelanden som rör sig genom externa AI-API:er, inklusive mer än 266 000 vektorlager på OpenAI:s plattform.

Det fynd som CodeWall lyfter som huvudnyhet är inte injektionen utan var injektionen landade. Lillis systemprompter var rader i samma databas som agenten kunde skriva till, vilket innebär att en angripare med samma åtkomst kunde ha skrivit om assistentens instruktioner med en enda UPDATE-sats insvept i ett enda HTTP-anrop – ingen utrullning, ingen kodändring, ingen fil på disken att diffa. CodeWall säger att dess egen testning endast var verifiering: den läste, den skrev inte, och enligt företaget stördes ingen produktionstjänst.

Vad McKinsey sa samma dag

En talesperson för McKinsey uppgav för The Register den 9 mars att företaget åtgärdade alla problem som CodeWall hade identifierat inom några timmar efter att ha fått kännedom om dem. "Vår utredning, som stöds av ett ledande tredjepartsforensikföretag, fann inga bevis för att denna forskare eller någon annan obehörig tredje part hade fått åtkomst till klientdata eller konfidentiell klientinformation", sade talespersonen och tillade att "McKinseys cybersäkerhetssystem är robusta."

Silicon UK rapporterade samma ståndpunkt den 13 mars, i Matthew Broersmas redogörelse: McKinsey uppgav att företaget "nyligen hade uppmärksammats på en sårbarhet kopplad till vårt interna AI-verktyg Lilli av en säkerhetsforskare", att det "snabbt bekräftade sårbarheten och åtgärdade problemet inom några timmar" och att inga kunddata eller konfidentiell kundinformation hade nåtts. Rapporten noterar också att Price är CodeWalls enda anställda, en detalj som är värd att ta med eftersom den kan tolkas åt båda hållen – en enmansforskningsverksamhet hittade på två timmar det som företagets egna skannrar inte hittade, och en enmansverksamhet säljer också verktyget som hittade det.

Två redogörelser för åtgärden, med en dags mellanrum

CodeWalls egen tidslinje för avslöjandet ser ut så här: agenten identifierar SQL-injektionen och börjar räkna upp produktionsdatabasen den 28 februari; hela kedjan bekräftas samma dag med 27 dokumenterade fynd; ett e-postmeddelande om ansvarsfull rapportering skickas till McKinseys säkerhetsteam den 1 mars med en övergripande sammanfattning av påverkan; företagets informationssäkerhetschef bekräftar mottagandet och begär detaljerade bevis den 2 mars; och den 2 mars patchas och verifieras alla oautentiserade slutpunkter, utvecklingsmiljön tas offline och den offentliga API-dokumentationen blockeras. Offentligt avslöjande följer den 9 mars.

McKinseys redogörelse är att åtgärden kom inom några timmar efter att de informerats. CodeWalls tidslinje placerar patchen dagen efter deras e-post om avslöjandet. Båda finns dokumenterade. Ingen av parterna har fått dem att stämma överens, och den här artikeln försöker inte göra det: skillnaden är mellan en åtgärd samma dag och en dagen därpå, och själva ordningen som spelar roll – informerad, sedan patchad, sedan publicerad – är inte omtvistad.

Etablerade, enkälliga och gapet mellan dem

Fastställt, överenskommet av båda parter: det fanns en oautentiserad svaghet i Lillis offentliga API-yta; den upptäcktes av en utomstående säkerhetsforskare snarare än av en intern aktör; McKinsey bekräftade och patchade den; de oautentiserade ändpunkterna stängdes, utvecklingsmiljön togs offline och den offentliga API-dokumentationen blockerades.

Från en enda källa, CodeWall:varje siffra ovan, den två timmar långa tidslinjen, de femton blinda iterationerna, de 27 dokumenterade fynden och påståendet att prompterna kunde skrivas genom samma injektion. Inget av det är motbevisat. Inget av det har heller verifierats oberoende, eftersom de payloads som skulle låta någon kontrollera inte publicerades, och Price vägrade ge The Register de exakta prompterna hans team använde.

Promptfoo, säkerhetsföretaget inom AI, publicerade den 10 mars en bedömning som anger gränsen exakt: det offentliga materialet "bevisar inte självständigt varje rapporterat radantal eller varje steg i utnyttjandet", även om det stöder bilden av incidenten. Det är den korrekta tolkningen av det tillgängliga materialet. Feltypen går att rekonstruera; omfattningen är vittnesmål.

Den skada som journalen inte förmedlar

Det är här arkivets gradering gör verklig nytta. En två timmar lång väg till läs- och skrivåtkomst inne i produktionsdatabasen för en företagsövergripande assistent låter som en skadepost, och arkivet registrerar ingen sådan. Fältet vilar på tre saker: McKinseys uttalande att en tredjeparts forensiska undersökning inte fann några bevis för att klientdata hade åtkommits; CodeWalls uttalande att dess testning endast var verifiering och inte störde något; och avsaknaden, i den rapportering som granskats för den här artikeln, av något motstridigt fynd.

Det vilar inte på en oberoende teknisk granskning, ett beslut från en tillsynsmyndighet eller en anmälan om incident. Ingen CVE-identifierare tilldelades i någon av de granskade rapporteringarna — Lilli är intern programvara snarare än en distribuerad produkt, och ingen säkerhetsbulletin namnger en sådan — och ingen tillsynsmyndighet tycks ha inlett ett ärende. Inga offentliga bevis framkom, i den rapportering som granskats för den här artikeln, för att uppgifterna användes, såldes eller exponerades ytterligare. Det är vad "inga dokumenterade skador" betyder här: ett påstående om vad som finns dokumenterat, inte ett konstaterande att exponeringen var säker.

Skillnaden spelar roll eftersom den intressanta risken var framåtblickande. Läsbehörighet blottlägger det som fanns där. Skrivbehörighet till promptlagret blottlägger vad assistenten skulle säga härnäst – förgiftade råd, borttagning av skyddsräcken, konfidentiellt material invävt i ett svar som en konsult sedan klistrar in i ett kunddokument. CodeWall beskrev dessa konsekvenser som tillgängliga för alla med samma behörighet. Ingen har visat att de utnyttjades. Båda påståendena kan vara sanna samtidigt: förmågan var verklig, och skadan inträffade inte enligt den bevisning någon har publicerat.

Varför det registreras som infrastruktur och inte som ett modellfel

Arkivet taggar den här posten som INFRA, och det tekniska underlaget stöder taggen. Inget i CodeWalls redogörelse krävde att man lurar modellen. Det fanns ingen jailbreak, ingen promptinjektion från ett dokument, ingen adversariell indata som assistenten ombads svälja. Ingångspunkten var exponerad dokumentation, en saknad autentiseringskontroll och osäker SQL-konstruktion; modellen var helt enkelt det mest värdefulla bakom dörren.

Promptfoos analys från 10 mars gör samma åtskillnad från försvarssidan: Lilli "ser, enligt offentliga uppgifter, ut som en applikationssäkerhetsincident som nådde ett AI-system, inte en modelljailbreak", och mycket av det som kallas AI-säkerhet är fortfarande mjukvarusäkerhet, datasäkerhet och konfigurationsstyrning. Den AI-specifika delen var skadeomfånget, inte intrånget – eftersom promptar, routningsregler och hämtningsinställningar var föränderliga applikationsdata blev skrivbehörighet till databasen förmågan att ändra assistentens beteende utan att röra kod.

Vad förändrades efteråt?

De konkreta förändringarna är de som båda parter beskriver: de oautentiserade slutpunkterna stängdes och verifierades, utvecklingsmiljön togs offline och den offentliga API-dokumentationen blockerades. McKinsey har uppgett att man hittade sårbarheten, bekräftade den och åtgärdade den, och deras offentliga hållning är att inga klientdata har åtkommits.

Det som inte förändrades är den bredare exponering som denna incident beskrev. CodeWalls skriftliga genomgång avslutas med argumentet att promptar lagras i databaser, skickas genom API:er och cachas i konfigurationsfiler, och att de sällan får åtkomstkontroller, versionshistorik eller integritetsövervakning – vilket är ett påstående om en bransch, inte en slutsats om McKinsey, och bör läsas som argumentet från ett företag som säljer kontinuerlig automatiserad testning. Företaget är i tidig förhandsversion och söker designpartner; avslöjandet fungerar samtidigt som en demonstration.

Det som framgår av akten är snävare och mer användbart än argumentet. En företagsövergripande assistent, en produktionsdatabas, två timmar, inga inloggningsuppgifter och en skaderad som framstår som falsk eftersom de två parter som har tillgång till fakta båda säger att data inte användes. Siffrorna tillhör en av dessa parter. Sårbarheten tillhör båda.