Lilli McKinsey została udostępniona publicznie 9 marca. Zapis nie niesie ze sobą szkody.

9 marca 2026 r. startup zajmujący się bezpieczeństwem CodeWall opublikował relację o tym, jak zbudowany przez niego autonomiczny agent uzyskał pełny dostęp do odczytu i zapisu do produkcyjnej bazy danych stojącej za Lilli, firmowym asystentem AI McKinsey & Company, w ciągu około dwóch godzin i bez ani jednego poświadczenia. Do samego wtargnięcia doszło 28 lutego; ten wpis w archiwum incydentów AI dokumentuje dzień, w którym sprawa stała się publiczna. Według CodeWall baza danych, do której dotarł, zawierała 46,5 mln wiadomości czatu w postaci jawnej, 728 000 plików, 57 000 kont użytkowników oraz 95 promptów systemowych określających, jak Lilli odpowiada — a prompty te znajdowały się w tej samej bazie danych, do której agent mógł zapisywać. Osobami w danych byli pracownicy samego McKinsey & Company: firma twierdzi, że 72 procent jej pracowników, ponad 40 000 osób, korzysta z Lilli, która obsługuje ponad 500 000 promptów miesięcznie. Pełny wpis, wraz z jego ocenami wagi i pewności oraz sąsiednimi rekordami, wśród których się znajduje, jest w Orca AI Incident Archive.

To otwarcie jest skrótem dwóch bardzo różnych rodzajów twierdzeń, a wpis w archiwum starannie rozróżnia jedno od drugiego. Klasyfikuje zapis jako incydent, pewność A, bezsporny, wysoka dotkliwość, region USA, typ INFRA — infrastruktura, a nie awaria modelu. Odnotowuje także brak rzeczywistej szkody. To ostatnie pole warto przeczytać dwa razy, ponieważ nie oznacza, że ekspozycja była nieszkodliwa. Oznacza, że w zapisie nie ustalono szkody, a poniższy artykuł oddziela to, co strony uznają wspólnie, od tego, co opiera się na relacji jednej firmy o jej własnych badaniach.

Dlaczego ujawnienie jest odrębnym wydarzeniem z datą

Podsumowanie archiwum dla tego wpisu odsyła do 28 lutego 2026 r., czyli dnia, w którym agent CodeWall odkrył tę wadę, a archiwum przechowuje tę wcześniejszą datę jako odrębny zapis. Ten podział nie jest biurokratyczny. Przed 9 marca jedynymi stronami, które wiedziały, co wydarzyło się wewnątrz Lilli, były McKinsey i badacz, który o tym poinformował. Po 9 marca kształt awarii, reakcja firmy oraz twierdzenie o tym, co znajdowało się w bazie danych, trafiły do publicznego obiegu, gdzie inni badacze bezpieczeństwa mogli się z nimi polemicznie zmierzyć.

Lilli nie jest projektem pobocznym. The Register datował jego wdrożenie na lipiec 2023 r., obejmujące czat, analizę dokumentów i wyszukiwanie w wewnętrznych zasobach badawczych firmy. Artykuł CodeWall, który również odnotowuje pochodzenie nazwy — od pierwszej profesjonalistki zatrudnionej przez firmę w 1945 r. — opisuje ponad 100 000 dokumentów wewnętrznych stanowiących jego podstawę. The Register, relacjonując ujawnienie tego samego dnia, podał, że rozwiązanie przyjęło 72 procent pracowników, a miesięczny wolumen przekracza 500 000 promptów — liczby, które McKinsey sama opublikowała w publicznym studium przypadku platformy.

Jak agent się dostał do środka

Relacja CodeWall zaczyna się od dokumentacji, a nie od wykorzystania luki. Agent CodeWall odkrył, że dokumentacja API Lilli była publicznie dostępna i w pełni opisana: łącznie ponad 200 punktów końcowych, z których większość wymagała uwierzytelnienia, a 22 nie. Jeden z tych nieuwierzytelnionych punktów końcowych zapisywał zapytania wyszukiwania użytkowników w bazie danych. Wartości były poprawnie parametryzowane, ale klucze JSON — nazwy pól — były sklejane bezpośrednio z SQL.

Agent zauważył to, ponieważ komunikaty błędów bazy danych dosłownie odzwierciedlały te klucze JSON. CodeWall twierdzi, że skaner ZAP organizacji OWASP nie oznaczył tego problemu oraz że agent przeprowadził następnie piętnaście iteracji w ciemno, przy czym każdy komunikat błędu uczył go nieco więcej o kształcie zapytania, aż zaczęły pojawiać się rzeczywiste wiersze z produkcji. Następnie połączył tę iniekcję z luką w autoryzacji na poziomie obiektu, aby odczytać historie wyszukiwania poszczególnych pracowników. Firma opisuje cały ten przebieg jako w pełni autonomiczny, od wyboru celu po raport, bez poświadczeń i bez udziału człowieka. Jej założyciel i dyrektor generalny, Paul Price, powiedział The Register, że proces był „w pełni autonomiczny od badania celu, przez analizę i atak, po raportowanie”.

Co CodeWall mówi, że było w środku

Każda liczba w tej sekcji pochodzi z opracowania CodeWall z 9 marca. Nie opublikowano żadnych payloadów, więc nic z tego nie da się odtworzyć ani niezależnie policzyć — to ograniczenie, którym zajmuje się następna sekcja.

• 46,5 miliona wiadomości czatu, przechowywanych w postaci jawnej, obejmujących prace strategiczne, projekty dla klientów, dane finansowe oraz fuzje i przejęcia.

• 728 000 plików, z których w opracowaniu wyszczególniono 192 000 plików PDF, 93 000 arkuszy kalkulacyjnych Excel, 93 000 prezentacji PowerPoint i 58 000 dokumentów Word — łącznie 436 000, pozostawiając w tym samym zdaniu pozostałe 292 000 niesklasyfikowane.

• 57 000 kont użytkowników, 384 000 asystentów AI i 94 000 przestrzeni roboczych, które CodeWall opisuje jako pełną strukturę organizacyjną wewnętrznego wykorzystania AI w firmie.

• 95 promptów systemowych i konfiguracji modeli w 12 typach modeli, pokazujących, jak instruowano asystenta, jakie zabezpieczenia istniały i jakie modele się pod nim znajdowały.

• 3,68 miliona fragmentów dokumentów do generowania wspomaganego wyszukiwaniem, wraz ze ścieżkami przechowywania w S3 i wewnętrznymi metadanymi plików — baza wiedzy zasilająca asystenta.

• 1,1 mln plików i 217 000 wiadomości agentów przepływających przez zewnętrzne interfejsy API sztucznej inteligencji, w tym ponad 266 000 magazynów wektorowych na platformie OpenAI.

To, co CodeWall uznaje za główny wniosek, nie dotyczy samej injekcji, lecz miejsca, w które injekcja trafiła. Prompty systemowe Lilli były wierszami w tej samej bazie danych, do której agent mógł zapisywać, co oznacza, że atakujący z takim samym dostępem mógłby przepisać instrukcje asystenta za pomocą jednej instrukcji UPDATE opakowanej w jedno wywołanie HTTP — bez wdrożenia, bez zmiany kodu, bez pliku na dysku do porównania. CodeWall twierdzi, że jego własne testy miały wyłącznie charakter weryfikacyjny: odczytywał dane, nie zapisywał ich, i zapewnia, że żadna usługa produkcyjna nie została zakłócona.

Co McKinsey powiedział tego samego dnia

Rzecznik McKinsey powiedział The Register 9 marca, że firma naprawiła wszystkie problemy zidentyfikowane przez CodeWall w ciągu kilku godzin od uzyskania o nich informacji. „Nasze dochodzenie, wsparte przez wiodącą zewnętrzną firmę specjalizującą się w informatyce śledczej, nie wykazało żadnych dowodów na to, że ten badacz lub jakakolwiek inna nieupoważniona strona trzecia uzyskała dostęp do danych klientów lub poufnych informacji klientów” – powiedział rzecznik, dodając, że „systemy cyberbezpieczeństwa McKinsey są solidne”.

Silicon UK 13 marca przedstawił to samo stanowisko w relacji Matthew Broersma: McKinsey oświadczyło, że „zostało niedawno powiadomione przez badacza bezpieczeństwa o podatności dotyczącej naszego wewnętrznego narzędzia AI Lilli”, że „niezwłocznie potwierdziło tę podatność i naprawiło problem w ciągu kilku godzin” oraz że nie uzyskano dostępu do żadnych danych klientów ani poufnych informacji klientów. W tej relacji zauważono także, że Price jest jedynym pracownikiem CodeWall — szczegół wart przytoczenia, ponieważ działa w obie strony: jednoosobowa firma badawcza znalazła w ciągu dwóch godzin to, czego nie znalazły własne skanery firmy, a jednoosobowa firma sprzedaje również narzędzie, które ją wykryło.

Dwie relacje o poprawce, w odstępie jednego dnia

Własny harmonogram ujawniania firmy CodeWall przedstawia się następująco: 28 lutego agent identyfikuje iniekcję SQL i rozpoczyna enumerację produkcyjnej bazy danych; tego samego dnia potwierdzony zostaje pełny łańcuch, a udokumentowano 27 ustaleń; 1 marca do zespołu ds. bezpieczeństwa McKinsey trafia e-mail w ramach odpowiedzialnego ujawniania z ogólnym podsumowaniem wpływu; 2 marca dyrektor ds. bezpieczeństwa informacji firmy potwierdza otrzymanie i prosi o szczegółowe dowody; 2 marca wszystkie nieuwierzytelnione punkty końcowe zostają załatane i zweryfikowane, środowisko programistyczne zostaje wyłączone z sieci, a publiczna dokumentacja API zostaje zablokowana. Publiczne ujawnienie następuje 9 marca.

Relacja McKinsey'a jest taka, że poprawka pojawiła się w ciągu kilku godzin od poinformowania. Oś czasu CodeWall umieszcza łatkę na dzień po wysłaniu e-maila ujawniającego. Obie wersje są oficjalnie zapisane. Żadna ze stron ich nie uzgodniła, a ten artykuł nie próbuje tego robić: różnica dotyczy poprawki tego samego dnia i poprawki następnego dnia, a istotna sekwencja — poinformowanie, następnie załatanie, potem publikacja — nie jest kwestionowana.

Ugruntowane, jednoźródłowe i luka między nimi

Ustalono, obie strony się zgodziły: w publicznym interfejsie API Lilli występowała luka umożliwiająca dostęp bez uwierzytelnienia; wykrył ją zewnętrzny badacz bezpieczeństwa, a nie osoba z wewnątrz; McKinsey potwierdził ją i załatał; nieuwierzytelnione punkty końcowe zostały zamknięte, środowisko deweloperskie zostało wyłączone, a publiczna dokumentacja API została zablokowana.

Pochodzące z jednego źródła, od CodeWall: każda z powyższych liczb, dwugodzinna os czasu, piętnaście ślepych iteracji, 27 udokumentowanych ustaleń oraz twierdzenie, że prompty można było zapisać przez tę samą injekcję. Nic z tego nie zostało obalone. Nic z tego nie zostało też niezależnie zweryfikowane, ponieważ ładunki, które pozwoliłyby komuś to sprawdzić, nie zostały opublikowane, a Price odmówił przekazania The Register dokładnych promptów, których użył jego zespół.

Promptfoo, firma zajmująca się bezpieczeństwem AI, opublikowała 10 marca ocenę, która precyzyjnie określa tę granicę: publiczny materiał „nie dowodzi niezależnie każdej zgłoszonej liczby wierszy ani każdego etapu eksploatacji”, choć potwierdza ogólny obraz incydentu. To jest właściwa interpretacja dostępnych materiałów. Klasę błędu można zrekonstruować; skala opiera się na relacjach.

Szkoda, której zapis nie oddaje

To tutaj ocena archiwum naprawdę robi swoją robotę. Dwugodzinna ścieżka do uzyskania dostępu do odczytu i zapisu wewnątrz produkcyjnej bazy danych asystenta obejmującego całą firmę brzmi jak zapis szkody, a archiwum nie odnotowuje żadnego. To pole opiera się na trzech elementach: oświadczeniu McKinsey, że niezależne dochodzenie kryminalistyczne nie wykazało dowodów na uzyskanie dostępu do danych klientów; oświadczeniu CodeWall, że jej testy miały wyłącznie charakter weryfikacyjny i niczego nie zakłóciły; oraz braku – w materiałach przeanalizowanych na potrzeby tego artykułu – jakiegokolwiek sprzecznego ustalenia.

Nie opiera się to na niezależnym audycie technicznym, rozstrzygnięciu organu regulacyjnego ani zgłoszeniu naruszenia. W żadnych z przejrzanych materiałów nie przypisano identyfikatora CVE — Lilli to oprogramowanie wewnętrzne, a nie produkt dystrybuowany, i żaden biuletyn go nie wymienia — i wygląda na to, że żaden organ nadzorczy nie wszczął sprawy. W materiałach przejrzanych na potrzeby tego artykułu nie pojawiły się żadne publiczne dowody na to, że dane wykorzystano, sprzedano lub dodatkowo ujawniono. To właśnie oznacza tutaj „brak odnotowanych rzeczywistych szkód”: stwierdzenie o dowodach zawartych w zapisie, a nie ustalenie, że ujawnienie było bezpieczne.

Ta luka jest istotna, ponieważ interesujące ryzyko miało charakter przyszły. Dostęp do odczytu ujawnia to, co już tam było. Dostęp do zapisu w warstwie promptów ujawnia to, co asystent powiedziałby dalej — zatrute porady, usunięcie zabezpieczeń, poufne materiały wplecione w odpowiedź, którą konsultant następnie wkleja do dokumentu dla klienta. CodeWall opisał te konsekwencje jako dostępne każdemu, kto ma taki sam dostęp. Nikt nie wykazał, że zostały wykorzystane. Oba stwierdzenia mogą być jednocześnie prawdziwe: zdolność była realna, a szkoda nie została zrealizowana według dowodów, jakie ktokolwiek opublikował.

Dlaczego jest to klasyfikowane jako infrastruktura, a nie jako awaria modelu

Archiwum oznacza ten rekord jako INFRA, a zapis techniczny potwierdza to oznaczenie. Nic w relacji CodeWall nie wymagało oszukania modelu. Nie było jailbreaka, wstrzyknięcia polecenia z dokumentu ani wrogich danych wejściowych, które asystent miałby przetworzyć. Punktem wejścia była ujawniona dokumentacja, brak kontroli uwierzytelniania i niebezpieczne budowanie zapytań SQL; model był po prostu najcenniejszą rzeczą za drzwiami.

Analiza Promptfoo z 10 marca dokonuje tego samego rozróżnienia od strony defensywnej: Lilli „wygląda, na podstawie publicznych informacji, jak incydent z zakresu bezpieczeństwa aplikacji, który dotarł do systemu AI, a nie jailbreak modelu”, a wiele z tego, co nazywa się bezpieczeństwem AI, to nadal bezpieczeństwo oprogramowania, bezpieczeństwo danych i zarządzanie konfiguracją. Częścią specyficzną dla AI był zasięg skutków, a nie samo naruszenie — ponieważ prompty, reguły routingu i ustawienia wyszukiwania były modyfikowalnymi danymi aplikacji, dostęp do zapisu w bazie danych stał się możliwością zmiany zachowania asystenta bez dotykania kodu.

Co się potem zmieniło?

Konkretne zmiany to te, które opisują obie strony: nieuwierzytelnione punkty końcowe zostały zamknięte i zweryfikowane, środowisko programistyczne zostało wyłączone, a publiczna dokumentacja API została zablokowana. McKinsey oświadczył, że wykrył tę lukę, potwierdził ją i naprawił, a jego publiczne stanowisko jest takie, że nie uzyskano dostępu do żadnych danych klientów.

Nie zmieniła się natomiast szersza ekspozycja opisana w tym incydencie. Tekst CodeWall kończy się argumentem, że prompty są przechowywane w bazach danych, przekazywane przez API i buforowane w plikach konfiguracyjnych oraz że rzadko mają mechanizmy kontroli dostępu, historię wersji czy monitorowanie integralności — co jest twierdzeniem o branży, a nie ustaleniem dotyczącym McKinsey, i należy je odczytywać jako argument firmy sprzedającej ciągłe automatyczne testy. Firma znajduje się we wczesnej fazie udostępniania podglądowego i szuka partnerów projektowych; ujawnienie służy jednocześnie za demonstrację.

To, co pozostawia dokumentacja, jest węższe i bardziej użyteczne niż sam spór. Asystent obejmujący całą firmę, baza danych produkcyjnych, dwie godziny, brak poświadczeń oraz pozycja dotycząca szkody, która brzmi nieprawdziwie, ponieważ obie strony mające dostęp do faktów twierdzą, że dane nie zostały wykorzystane. Zarzuty należą do jednej z tych stron. Podatność należy do obu.