Cztery niepowodzenia. Cztery warstwy. Architektura sama w sobie jest podatnością.

Odcinek z 10 kwietnia 2026 r. podcastu Hard Fork z New York Times Hard Fork podcast badał implikacje bezpieczeństwa cybernetycznego zaawansowanych systemów AI i postawił pytanie, które branża unikała: co jeśli bezpieczeństwo nie jest niewydajne, ale fundamentalnie źle sformułowane?

Odcinek został wyemitowany kilka tygodni po serii incydentów, które uczyniły odpowiedź trudną do zignorowania. W ciągu jednego miesiąca autonomiczny agent AI naruszył wewnętrzną platformę AI McKinsey w ciągu dwóch godzin. Atak łańcucha dostaw na powszechnie używaną bibliotekę open-source AI przerzucił się do przedsiębiorstw w dół strumienia. Naukowcy udowodnili, że sprzęt, który miał być ostatnią linią obrony, może być złamany przy użyciu części z półki za mniej niż tysiąc dolarów. A Anthropic ujawnił, że model pionierski samodzielnie odkrył tysiące podatności zero-day w kodzie, który branża uważała za stabilny.

Cztery incydenty. Cztery warstwy stosu AI: aplikacja, orkiestracja, sprzęt i system operacyjny. Każdy ujawnił znaczące ograniczenia w kontrolach zaprojektowanych do ich ochrony.

Koniec myślenia o obwodzie

Tradycyjne bezpieczeństwo opiera się na jednej podstawie: z wystarczającymi kontrolami, monitorowaniem i inwestycjami, systemy mogą być zabezpieczone. Ta podstawa ukształtowała dziesięciolecia architektury, w tym firewalle, zarządzanie tożsamością, zabezpieczenia punktów końcowych i platformy SIEM, wszystkie zbudowane na idei, że widoczność i ścisłe zarządzanie równają się bezpieczeństwu.

Branża przesunęła się w kierunku Zero Trust Architecture, co odzwierciedla rosnące uznanie, że tradycyjne granice sieciowe nie mogą być już ufałe. Jednak nawet gdy modele zaufania ewoluują, systemy AI wprowadzają inne wyzwanie: wrażliwe dane są rutynowo agregowane, przetwarzane i udostępniane na różnych warstwach infrastruktury.

Ten podejście miało sens, gdy systemy były stosunkowo scentralizowane, a dane pozostawały wewnątrz wyraźnie określonych granic. Staje się znacznie mniej skuteczne, gdy dane są przesyłane nieustannie przez chmury, API, dostawców zewnętrznych i potoki AI, a użytkownicy i zasoby obliczeniowe są rozproszone na całym świecie. Obwód nie jest już granicą. Jest to stale zmieniająca się powierzchnia, a my nadal stosujemy myślenie oparte na kontrolach do systemów, które nie mogą być realistycznie kontrolowane.

Niepowodzenie warstwy aplikacji: Lilli McKinsey

9 marca 2026 r. startup z branży bezpieczeństwa CodeWall opublikował ujawnienie, które podkreśliło ryzyko, na które narażone są organizacje wdrażające AI wewnętrznie. .

Autonomiczny agent ofensywny CodeWall, bez poświadczeń, wiedzy insiderów i ludzkiej pomocy, uzyskał dostęp do odczytu i zapisu do bazy danych produkcyjnej za Lilli, wewnętrzną platformą AI McKinsey, w ciągu moins niż dwóch godzin. Lilli jest używana przez ponad 40 000 pracowników do pracy strategicznej, badań klientów i analizy dokumentów, generując setki tysięcy sugestii miesięcznie.

Punkt wejścia nie był zaawansowany. Agent znalazł publicznie dostępną dokumentację API z listą ponad 200 punktów końcowych, z których 22 nie wymagało uwierzytelnienia. Podatności zaangażowane odzwierciedlają ryzyka podkreślone w OWASP Top 10 for LLM Applications, szczególnie wokół narażonych interfejsów, niebezpiecznych integracji i nadmiernego zaufania do połączonych systemów.

Jeden z tych punktów końcowych zawierał podatność na wstrzyknięcie SQL ukrytą w nazwach pól JSON, a nie w wartościach wejściowych, gdzie większość skanerów automatycznych szuka. Stamtąd agent iterował przez wstrzyknięcie SQL, aż dane produkcyjne stały się dostępne.

To, do czego uzyskał dostęp: dziesiątki milionów wiadomości czatu w postaci zwykłego tekstu, setki tysięcy plików, dziesiątki tysięcy kont użytkowników i miliony fragmentów dokumentów RAG reprezentujących lata badań własnych. Zidentyfikował również sugestie systemowe, które rządziły zachowaniem Lilli dla każdego użytkownika.

Najbardziej niepokojące odkrycie nie było objętością. Było to, że sugestie systemowe były dostępne do zapisu. Atakujący mogli cicho przepisać instrukcje rządzące wyjściami Lilli, zatruwając porady strategiczne, wstawiając dane poufne do odpowiedzi lub usuwając barierki całkowicie, z jedną aktualizacją bazy danych. Żadnego wdrożenia. Żadnej zmiany kodu. Żadnego śladu w logach aplikacji.

W oświadczeniu publicznym McKinsey powiedział, że usunął problem w ciągu kilku godzin i po śledztwie przeprowadzonym przez firmę forensyczną nie znaleziono dowodów na to, że dane poufne klienta zostały uzyskane. Ta odpowiedź ma znaczenie. Ale nie zmienia ona strukturalnej lekcji: klasa podatności, która istnieje od dziesięcioleci, ujawniła pamięć operacyjną nowoczesnego systemu AI, ponieważ dane za nim istniały w postaci zwykłego tekstu.

Niepowodzenie warstwy orkiestracji: Atak LiteLLM

Trzy tygodnie później ten sam wzorzec pojawił się z innego kąta i przez inną warstwę.

LiteLLM to open-source bramka AI używana przez tysiące firm do kierowania żądaniami przez dostawców AI. Jego pozycja w stosie jest krytyczna: siedzi na warstwie orkiestracji, trzymając klucze API dla każdego dostawcy, do którego łączy się. Jakakolwiek kompromisja na tej warstwie naraża poświadczenia na każdą zintegrowaną usługę.

Zgodnie z raportem incydentu PyPI, grupa aktorów zagrożeń TeamPCP wykorzystała poświadczenia związane z zależnością w potoku CI/CD LiteLLM i użyła dostępu do opiekuna do opublikowania dwóch wersji LiteLLM z tylnymi drzwiami bezpośrednio na PyPI. . Zanieczyszczone wersje były dostępne przez mniej niż godzinę, zanim zostały usunięte. Operacja została odkryta tylko dlatego, że złośliwe oprogramowanie zawierało błąd, który wyłączył maszynę badacza.

Łańcuch dostaw był wektorem. Warstwa orkiestracji była celem. Poprzez kompromis jednej zależności w górę, atakujący dotarli do warstwy, na której żyły klucze dostawców każdej firmy w dół strumienia.

Zespół LiteLLM później opisał incydent i wysiłki w celu złagodzenia go w publicznym ujawnieniu na GitHub.

Promień wybuchu stał się widoczny prawie natychmiast. TechCrunch, Fortune i The Register poinformowały, że Mercor, startup rekrutacji AI o wartości 10 miliardów dolarów, pracujący z firmami, w tym OpenAI, Anthropic, Meta i Google, był jedną z dotkniętych organizacji. Atakujący twierdzili, że uzyskali duże ilości danych, w tym profile kandydatów, dane osobowe, wywiady wideo z kontrahentami, kod źródłowy i klucze API. Meta wstrzymała pracę z Mercor w oczekiwaniu na dochodzenie. Późniejsze raporty wskazywały na podobne wzorce złośliwego oprogramowania w innych narzędziach programistycznych i pakietach, co sugeruje, że operacja mogła sięgać poza jeden projekt.

Incydent LiteLLM nie był anomalią. Był to system zachowujący się zgodnie z projektem. Każdy komponent w potoku AI wymaga dostępu do użytecznych danych, aby działać, co oznacza, że każdy komponent jest również potencjalnym punktem ekstrakcji. Przypinanie zależności i rotacja poświadczeń są koniecznymi odpowiedziami, ale dotyczą one incydentu, a nie architektury.

Niepowodzenie warstwy sprzętowej: TEE.fail

Jeśli naruszenie McKinsey udowodniło, że warstwa aplikacji nie może być zaufana, a atak LiteLLM udowodnił, że łańcuch dostaw nie może być zaufany, badanie TEE.fail udowodniło, że sprzęt, który miał być ostatnią linią obrony, również nie może być w pełni zaufany.

28 października 2025 r. badacze z Georgia Tech, Purdue University i Synkhronix opublikowali TEE.fail, atak bocznego kanału, który wyodrębnia klucze kryptograficzne z Trusted Execution Environments przy użyciu interpozycji fizycznego magistralu pamięci na serwerach DDR5. Atak dotyczy Intel SGX, Intel TDX i AMD SEV-SNP, w tym na w pełni poprawionych systemach z włączonym AMD Ciphertext Hiding. Są to technologie powszechnie promowane jako podstawa obliczeń poufnych.

Badacze wyodrębnili klucze poświadczające: materiał kryptograficzny używany do weryfikacji, że obciążenia są uruchamiane wewnątrz bezpiecznych środowisk. Z tymi kluczami skompromitowany system może przedstawić się jako zaufany, działając całkowicie poza oczekiwanymi ochronami. Badacze zademonstrowali to bezpośrednio: sfabrykowali poświadczania TDX na BuilderNet Ethereum, aby uzyskać dostęp do poufnych danych transakcji, i sfabrykowali poświadczania Intel i NVIDIA, aby uruchomić obciążenia poza TEE, pozornie uzasadniając.

Implikacja NVIDIA jest istotna dla AI w szczególności. Ponieważ poświadczanie GPU zależy od poświadczania CPU, skompromitowana wiązka zaufania CPU może podważyć gwarancje zapewniane przez środowiska inferencji AI poufnej. Podstawą sprzętową środowiska inferencji AI poufnej jest, w tym modelu zagrożenia, warunkowa na CPU TEE, który został wyraźnie złamany.

Dostawcy sprzętu odpowiedzieli formalnymi zaleceniami. AMD stwierdziło, że ataki fizyczne znajdują się poza ich standardowym modelem zagrożenia i wskazało, że nie wydadzą aktualizacji oprogramowania układowego. Intel i NVIDIA potwierdziły ustalenia i wskazały na trwające prace łagodzące. Te odpowiedzi są rozsądne w ramach ich modeli zagrożenia. Podkreślają one również ważną granicę: gwarancje bezpieczeństwa opartego na sprzęcie zależą od założeń, w tym kontroli fizycznej, które wdrożenia suwerenne, regulowane i zorientowane na wroga nie zawsze mogą spełnić.

TEE.fail nie czyni izolacji sprzętowej nieistotną. Udowadnia, że jest warunkowa.

Niepowodzenie warstwy systemu operacyjnego: Objawienie Mythos

Jeśli pierwsze trzy incydenty podważyły warstwę aplikacji, warstwę orkiestracji i warstwę sprzętową, czwarte ujawnienie w kwietniu 2026 r. podważyło warstwę pod spodem wszystkich z nich: systemy operacyjne i biblioteki podstawowe, na których działa każda inna warstwa.

7 kwietnia 2026 r. Anthropic ogłosił Claude Mythos Preview, model pionierski, którego odmówił udostępnienia publicznie z powodu jego zdolności do bezpieczeństwa ofensywnego, i jednocześnie uruchomił Project Glasswing, konsorcjum z AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorgan Chase, Linux Foundation, Microsoft, NVIDIA i Palo Alto Networks. Anthropic poinformował, że w ciągu kilku tygodni Mythos samodzielnie zidentyfikował tysiące wcześniej nieznanych podatności w głównych systemach operacyjnych i przeglądarkach internetowych oraz był w stanie wyprodukować działające eksploity dla wielu z nich.

Konkretna ustalenia są trudniejsze do zignorowania niż jakikolwiek podsumowanie. 27-letnia podatność w OpenBSD. 17-letnia podatność na zdalne wykonanie kodu w serwerze NFS FreeBSD, teraz śledzona jako CVE-2026-4747, która zapewnia dostęp root do nieuwierzytelnionego atakującego. 16-letnia podatność w FFmpeg, jednej z najczęściej wdrożonych bibliotek multimedialnych w Internecie. W jednym przypadku inżynier Anthropic bez formalnego przeszkolenia w zakresie bezpieczeństwa poprosił model o poszukiwanie podatności na zdalne wykonanie kodu i obudził się z kompletnym działającym eksploitem.

Są to ustalenia na poziomie systemu operacyjnego. OpenBSD i FreeBSD to jądra. NFS to podsystem sieciowy jądra. FFmpeg to biblioteka systemowa, która jest dostarczana z większością dystrybucji Linux i podstawą potoków multimedialnych w Internecie. Warstwa systemu operacyjnego była uważana za bezpieczną nie dlatego, że została udowodniona jako bezpieczna, ale dlatego, że znajdowanie głębokich podatności w niej wymagało rzadkiego i drogiego doświadczenia ludzkiego. To założenie było najlepszą dostępną heurystyką. Nigdy nie było gwarancją.

To ograniczenie zostało teraz poluzowane. Sam Anthropic scharakteryzował to jako dual-use shift: te same możliwości, które pozwalają modelowi pionierskiemu na znalezienie i naprawienie podatności w skali, pozwalają mu również, w niewłaściwych rękach, znaleźć i wykorzystać je w skali. Decyzja Anthropic o ograniczeniu dostępu do Project Glasswing odzwierciedla tę rzeczywistość. Nie rozwiązuje jej. Podobne możliwości, według oceny samej firmy, będą się rozprzestrzeniać. Koszt audytu kodu legacy spadł, a wraz z nim niejawna obrona, że taki kod był zbyt niejasny, zbyt stary lub zbyt szeroko przeglądany, aby nadal zawierać krytyczne podatności.

To jest również miejsce, w którym cztery incydenty się nakładają. Warstwa sprzętowa chroni poufne środowiska obliczeniowe, które nie działają w izolacji. Działają jako kod jądra. Intel TDX działa w jądrze. Sterowniki GPU NVIDIA działają jako moduły jądra. Wiązka zaufania CPU TEE zależy od godnego zaufania systemu operacyjnego, aby wiernie zgłaszał, co robi. Jeśli warstwa systemu operacyjnego pod Twoim TEE ma dziesiątki lat ukrytych podatności, a model pionierski może je znaleźć z prędkością maszyny, wtedy warunkowe bezpieczeństwo warstwy sprzętowej zależy od warstwy systemu operacyjnego, której gwarancje bezpieczeństwa zostały właśnie osłabione przez ten sam cykl ujawnienia.

Trzy pierwsze incydenty opisują, w jaki sposób systemy AI są naruszane dzisiaj. Mythos opisuje tempo, w jakim wszystko pod nimi, w tym systemy operacyjne, moduły jądra i biblioteki systemowe, zostanie ponownie zbadane przez maszyny. Naruszenie McKinsey wykorzystało klasę podatności na wstrzyknięcie SQL, która istnieje od ponad dwóch dekad. Podatności tego rodzaju są właśnie tym, co modele klasy Mythos są w stanie znaleźć w skali przemysłowej.

Wzorzec

W każdym przypadku dane były w postaci zwykłego tekstu w momencie, gdy to się liczyło.

Warstwa aplikacji przetwarzała ją w sposób jawny. Warstwa orkiestracji kierowała nią w sposób jawny. Warstwa sprzętowa, pomimo swoich ochron, ostatecznie wymagała odszyfrowania w punkcie wykonywania. Warstwa systemu operacyjnego pod spodem wszystkich działała na niej w sposób jawny z definicji. Cztery warstwy, cztery niepowodzenia, i na każdej warstwie ten sam warunek obowiązywał: gdy nastąpiło naruszenie, dane były czytelne.

To nie jest zbiór izolowanych niepowodzeń. To jest architektura sama w sobie.

Współczesne systemy AI są zaprojektowane do pracy na czytelnych danych. Każda warstwa, w tym pobieranie, routing, inferencja i wykonanie narzędzi, wymaga dostępu do zwykłego tekstu, aby działać. To wybór projektu oznacza, że każde naruszenie na każdej warstwie ujawnia dane za nim.

Pytanie nie brzmi, czy warstwa zostanie skompromitowana. To, co znajdzie atakujący, gdy zostanie skompromitowana.

Od założonego naruszenia do zerowego narażenia

Branża już zaczęła przechodzić od „zapobiegaj naruszeniu” do „załóż naruszenie.” Ale większość architektur nie wdrożyła jeszcze implikacji.

Jeśli naruszenie jest nieuniknione, to prawdziwe pytanie nie brzmi, jak utrzymać atakujących na zewnątrz. To, co się dzieje, gdy się dostają. Obecnie odpowiedź jest prosta: dostają dane. Ponieważ pomimo wszystkich inwestycji w infrastrukturę bezpieczeństwa, dane nadal są narażone w momencie, gdy stają się wartościowe, gdy są używane.

Odpowiedź branży była przewidywalna: więcej monitorowania, szybsze wykrywanie, dodatkowe warstwy obliczeń poufnych. To są ulepszenia. Ale nie rozwiązują one podstawowego problemu. Nadal zakładają, że jakaś warstwa — czy to oprogramowanie, sprzęt czy operacyjna — może być zaufana do utrzymania zwykłego tekstu w bezpieczeństwie.

Alternatywą jest usunięcie zwykłego tekstu całkowicie. Nie chronić warstw wokół danych, ale uczynić same dane niedostępnymi dla każdego, kto do nich dotrze. Obliczenia na zaszyfrowanych danych, gdzie sugestie, wagi modelu i dane wyjściowe pozostają zaszyfrowane na całej długości potoku, rozwiązują narażenie, które każdy z tych incydentów wykorzystał.

Postępy w pełnym szyfrowaniu homomorficznym i innych technikach obliczeń zachowujących prywatność sprawiają, że architektury, które minimalizują lub eliminują narażenie na zwykły tekst, stają się coraz bardziej praktyczne dla rzeczywistych obciążeń AI. Chociaż pozostają znaczące wyzwania dotyczące wydajności, skalowalności i wdrożenia, cel jest fundamentalnie inny niż tradycyjne kontrolki bezpieczeństwa: redukowanie wartości udanego naruszenia, a nie tylko czynienie naruszenia mniej prawdopodobnym.

Przesunięcie nie jest z jednego narzędzia bezpieczeństwa do innego. To przesunięcie od zabezpieczania systemów do redukowania narażenia. Od infrastruktury zaufanej do danych zero-trust. Od zarządzania ryzykiem do minimalizowania samej powierzchni ataku.

Co dalej

Dyskusja Hard Fork podniosła pytanie, czy bezpieczeństwo cybernetyczne jest fundamentalnie źle sformułowane. Dowody z ostatnich kilku tygodni sugerują, że odpowiedź jest tak, przynajmniej dla AI.

Stary model zakładał, że systemy mogą być zabezpieczone, naruszenia mogą być ograniczone, a narażenie może być zarządzane. Pojawiająca się rzeczywistość jest taka, że naruszenia muszą być założone, a narażenie minimalizowane. Incydenty opisane tutaj sugerują, że zabezpieczenie systemów AI może coraz bardziej zależeć od redukowania ilości wrażliwych danych dostępnych, gdy kontrolki zawodzą.

Podatności ujawnione w tych czterech incydentach nie są ograniczone do jednej warstwy. Są one systemowe. Ich rozwiązanie będzie wymagać więcej niż stopniowych ulepszeń. Będzie wymagać przesunięcia od zabezpieczania systemów do redukowania narażenia, od obrony obwodu wokół danych do usunięcia zwykłego tekstu, który obwód został zbudowany, aby chronić.

Bezpieczeństwo AI nie jest już o tym, aby trzymać atakujących na zewnątrz. To o tym, aby upewnić się, że gdy się dostają, i dostają, nie ma dla nich nic do znalezienia.