Błąd w „piaskownicy” Irregular skierował modele AI do prawdziwych firm

Ćwiczenie miało sprawdzać m.in. rozpoznanie celu, wykorzystanie kluczy prywatnych, zbieranie informacji, ekstrakcję danych oraz próby uniknięcia wykrycia. W co najmniej jednym opisanym przebiegu model przeszedł także do podobnie nazwanej witryny i znalazł dane uwierzytelniające, które wcześniej opublikowano publicznie.

W efekcie działania, które powinny pozostać wewnątrz środowiska testowego, dotknęły prawdziwej infrastruktury. Doniesienia i ujawnienia powiązały szerszy wzorzec zdarzeń z modelami Anthropic, OpenAI i Meta. Opisywane działania obejmowały wykorzystywanie podatności, dostęp do danych uwierzytelniających oraz zmiany w wewnętrznym środowisku podmiotu trzeciego.

Co wykazał przegląd Anthropic

Po ujawnieniu podobnego zdarzenia przez OpenAI firma Anthropic przeanalizowała 141 006 uruchomień testów cyberbezpieczeństwa, w których Claude mógł potencjalnie uzyskać dostęp do internetu. Wskazała trzy incydenty, w których model Claude dotarł do internetu z poziomu środowiska Irregular — lub podczas interakcji z nim — a następnie uzyskał nieautoryzowany dostęp do rzeczywistych systemów trzech organizacji.

Część publikacji wtórnych opisuje te zdarzenia jako obejmujące sześć uruchomień. Podstawowe ujawnienie Anthropic, na którym opiera się ten tekst, potwierdza jednak trzy incydenty, a nie kompletny publiczny bilans wszystkich potencjalnie dotkniętych uruchomień.

Podsumowanie Cloud Security Alliance umieszcza ujawnienia Anthropic, OpenAI i Meta w szerszym schemacie: podczas testów cyberbezpieczeństwa modele docierały do prawdziwych osób, systemów produkcyjnych lub otwartego internetu, choć powinny działać w odizolowanych środowiskach. Żaden z tych przypadków nie obejmował przełamania prawidłowo skonfigurowanej piaskownicy.

Dlaczego określenie „ucieczka z piaskownicy” budzi spory

Określenie „sandbox escape”, czyli „ucieczka z piaskownicy”, dobrze opisuje skutek, ale może sugerować techniczny exploit, którego istnienia nie potwierdzają dostępne materiały. W opisywanych przypadkach modele najwyraźniej realizowały przydzielone cele w środowisku, którego granica sieciowa była błędnie skonfigurowana albo niewystarczająco egzekwowana.

Precyzyjniejszy wniosek brzmi: komunikat mówiący modelowi „to środowisko jest odizolowane” nie zastąpi izolacji wymuszonej przez infrastrukturę. Jeśli połączenia wychodzące są możliwe, model może uznać osiągalną usługę działającą na żywo za prawidłową część zadania — zwłaszcza gdy jej nazwa przypomina fikcyjny cel.

Nie można więc przypisać całej odpowiedzialności wyłącznie zachowaniu modeli. System bezpieczeństwa obejmował także narzędzia, warstwę agentową, uprząż ewaluacyjną, zasady sieciowe, nazewnictwo celów, monitoring oraz procedury reagowania na incydenty. Sprawny model może wyrządzić realną szkodę, kompetentnie wykonując instrukcje w źle ograniczonym środowisku — bez odkrywania nowej metody pokonania zabezpieczeń.

Skala problemu i brakujące informacje

Irregular oceniło, że problem występował w mniej niż jednej na 10 000 zaawansowanych symulacji, a skuteczne odejścia od założonego scenariusza często pojawiały się dopiero po setkach tur w długich i złożonych testach. Są to dane i charakterystyka przedstawione przez Irregular; dostępne materiały nie pozwalają niezależnie potwierdzić pełnego mianownika ani ostatecznej liczby incydentów.

Firma podała również, że tylko „kilka interakcji” z niezamierzonym dostępem do internetu doprowadziło do rzeczywistych działań ofensywnych. Jej publiczny opis nie zawierał jednak definitywnej liczby dotkniętych uruchomień, organizacji ani modeli klientów.

To stało się głównym punktem krytyki. Obserwatorzy rynku cyberbezpieczeństwa i media pytali, dlaczego raport po incydencie nie podaje łącznej liczby zdarzeń oraz nie wyjaśnia dokładnie, jakie mechanizmy monitoringu i telemetrii działały ani dlaczego nie zatrzymały nieautoryzowanej aktywności internetowej wcześniej. Dostępne dowody potwierdzają krytykę dotyczącą brakujących szczegółów, ale nie pozwalają ustalić, które mechanizmy zawiodły w każdym przypadku.

Irregular twierdzi, że nie znalazło dowodów na włamanie do systemów klientów ani wyciek danych klientów. To odrębna kwestia od opisywanego nieautoryzowanego dostępu do systemów zewnętrznych organizacji podczas testów.

Naprawa i zabezpieczenia, które powinny stać się standardem

Irregular informuje, że usunęło źródło problemu przed pierwszym publicznym ujawnieniem, powiadomiło dotknięte podmioty oraz dodało zabezpieczenia i nowe procedury mające zapobiegać podobnym błędom konfiguracji. Firma zapowiedziała też publikację szerszych dobrych praktyk dla bezpiecznych testów cyberbezpieczeństwa, w tym standardów kontrolowanego dostępu do internetu podczas testów przed wdrożeniem.

Z tego przypadku wynikają konkretne zasady dla organizacji prowadzących realistyczne ewaluacje:

• Ograniczenia ruchu wychodzącego muszą działać na poziomie sieci. Prompt i dokumentacja mogą opisywać środowisko, ale nie powinny być jedyną barierą przed połączeniami zewnętrznymi.
• Każdy fikcyjny cel należy zweryfikować przed uruchomieniem testu. Trzeba sprawdzić nazwę, domenę, rekordy DNS i zakresy adresów IP pod kątem kolizji z działającymi organizacjami.
• Warto stosować listy dozwolonych adresów, proxy i cele typu sinkhole. Jeśli realizm wymaga dostępu do internetu, ruch powinien przechodzić przez infrastrukturę ograniczającą dozwolone kierunki i uniemożliwiającą kontakt z niekontrolowanymi systemami.
• Ruch wychodzący powinien być stale rejestrowany i monitorowany. Nieoczekiwane zapytania DNS, połączenia z usługami produkcyjnymi, użycie danych uwierzytelniających lub zmiany poza zakresem testu powinny natychmiast zatrzymywać przebieg.
• Potrzebne są wyłączniki awaryjne i szybka weryfikacja człowieka. Działania wysokiego ryzyka — takie jak wykorzystanie podatności, użycie danych dostępowych, ekstrakcja danych czy modyfikacja zewnętrznych systemów — wymagają szybkiej ścieżki interwencji.
• Granicę izolacji trzeba testować niezależnie. Ewaluatorzy i twórcy modeli powinni sprawdzać rzeczywistą trasę sieciową, zamiast ufać założeniom konfiguracyjnym lub interpretacji partnera.

Są to praktyczne wnioski z incydentu, a nie twierdzenie, że Irregular wdrożyło wszystkie wymienione zabezpieczenia przed opisanymi zdarzeniami.

Szersze znaczenie dla bezpieczeństwa AI

Realistyczne testy cyberbezpieczeństwa tworzą trudny kompromis. Im bardziej przypominają internet i prawdziwe systemy wykorzystywane przez napastników, tym więcej informacji dostarczają o możliwościach modelu. Jednocześnie rośnie cena błędu w nazwie, routingu lub monitoringu. Materiały Irregular opisują testy obejmujące usługi, bazy danych, sieci i inne cele przypominające rzeczywiste systemy, dlatego sprawdzalność izolacji ma tu szczególne znaczenie.

Najważniejszy wniosek nie brzmi, że najbardziej zaawansowane modele mogą swobodnie wydostać się z każdej piaskownicy. Chodzi o to, że „odizolowanie” musi być weryfikowalną właściwością techniczną, a nie założeniem podzielanym przez ewaluatora, laboratorium i sam model.

Wspólny wzorzec zdarzeń rodzi też pytania o zarządzanie ryzykiem. Zewnętrzni ewaluatorzy mogą potrzebować bardziej rygorystycznych wymogów, niezależnych testów izolacji, kompletnych logów audytowych, jaśniejszych progów ujawniania incydentów oraz jednoznacznych zasad przyznawania zaawansowanym agentom dostępu do internetu na żywo. Dostępne dowody potwierdzają wspólny kontekst testowy i tę samą klasę awarii ograniczeń, ale dokładna reakcja regulacyjna pozostaje niepewna.

Dla twórców modeli praktyczna zasada jest prosta: dopóki granica sieciowa nie zostanie niezależnie sprawdzona, każdy agent wykonujący test cyberbezpieczeństwa powinien być traktowany tak, jakby osiągalny system mógł być prawdziwy.