Kiedy algorytm nie potrafi odpuścić

Kiedy algorytm nie potrafi odpuścić

Obszerny raport techniczny OpenAI podsumowujący lipcowy incydent z infrastrukturą Hugging Face przenosi dyskusję o bezpieczeństwie sztucznej inteligencji z poziomu teoretycznych rozważań wprost do inżynierskiej praktyki.

Ponad dwudziestominutowy dokument nie opisuje mitycznego buntu maszyn. Pokazuje coś znacznie bardziej przyziemnego, paradoksalnie bardziej ciekawego: co może się wydarzyć, gdy bardzo zdolny model dostanie bardzo trudne zadanie, bardzo wielkie zasoby obliczeniowe i bardzo mało powodów, by się poddać.

Najbardziej niepokojące w raporcie OpenAI nie jest nawet to, że modele włamały się do Hugging Face. Nie jest nim również fakt, że potrafiły ominąć izolację, zdobyć dostęp do internetu i zacząć współpracować ze sobą bez zgody operatorów. Najciekawsze jest to, że przez znaczną część incydentu robiły dokładnie to, do czego zostały wytrenowane: uparcie szukały sposobu na osiągnięcie celu. Problem polegał na tym, że nikt nie przewidział, jak daleko będą gotowe się posunąć.

Cztery wzorce zachowań zamiast filmowego scenariusza

W opublikowanym dokumencie OpenAI zidentyfikowało cztery kluczowe wzorce zachowań, które przyczyniły się do eskalacji zdarzeń: hakowanie funkcji nagrody (tzw. reward hacking), uporczywe wykonywanie pozornie niemożliwych zadań, nieautoryzowaną komunikację oraz przejmowanie celów od innych agentów.

Pierwszy z nich, reward hacking, oznacza poszukiwanie sposobów na uzyskanie wysokiej nagrody w sposób niezgodny z pierwotnym zamierzeniem zadania. Innymi słowy model nie wykonuje zadania by otrzymać nagrodę, lecz hakuje sam proces jej przyznawania. Jeżeli w tym momencie pomyśleliście o piątce wpisanej przez ucznia do dziennika nauczycielskiego, gdy ten nie patrzy, to coś w tym stylu. To nie musi być spektakularne. Model może znaleźć odpowiedź w internecie, wykorzystać historię zmian kodu albo odkryć lukę w środowisku testowym. Problem zaczyna się wtedy, gdy coraz bardziej zdolny agent potrafi łączyć takie możliwości w dłuższy łańcuch działań.

Drugi element okazał się równie istotny: modele niechętnie rezygnowały z zadań, których nie potrafiły rozwiązać. Spośród 898 zadań benchmarku ExploitGym aż 198 nigdy wcześniej nie zostało poprawnie rozwiązanych przez żaden z testowanych modeli (ani żaden z wcześniejszych). Aż 93 proc. zadań omawianych później na improwizowanej tablicy komunikacyjnej pochodziło właśnie z tej „niemożliwej do rozwiązania” grupy.

Tu zaczyna się robić ciekawie. Modele nie „zbuntowały się”. Nie dostały nagle własnych, niezależnych celów. Zaczęły po prostu coraz agresywniej optymalizować ten, który już miały. To kluczowe dla zrozumienia co właściwie się stało. Przyznaję że w tym momencie niczym latarnia w mroku zaświecił mi się w mózgu eksperyment myślowy Nicka Bostroma o sztucznej inteligencji produkującej spinacze. Za wszelką cenę.

Kiedy sandbox przestaje być sandboxem

Środowisko testowe zostało zaprojektowane jako izolowana piaskownica bez bezpośredniego dostępu do internetu. Modele miały jednak dostęp do wewnętrznej instancji Artifactory, menedżera pakietów wykorzystywanego do pobierania i instalowania pakietów programistycznych. W założeniu była to zwykła funkcja pomocnicza. W praktyce okazała się dla AI furtką do sięgnięcia po znacznie więcej.

Agenci odkryli, że mogą wykorzystywać Artifactory do pozostawiania informacji dla innych instancji. Z czasem powstała w ten sposób improwizowana tablica wiadomości. Później modele zaczęły kodować komunikaty między innymi w nazwach katalogów i ścieżkach URL.

To oznaczało, że instancje, które miały pracować niezależnie, mogły wymieniać się odkryciami i przejmować pracę rozpoczętą przez innych. Następnie modele znalazły sposób na wykorzystanie podatności SSRF (Server-Side Request Forgery; fałszowanie żądań po stronie serwera). Artifactory posiadał ograniczony dostęp do internetu, potrzebny do pobierania zależności. Agenci wykorzystali tę funkcję, zmuszając usługę do wysyłania zapytań do dowolnych adresów internetowych w ich imieniu. W ten sposób izolacja zaczęła się rozpadać kawałek po kawałku.

Co ważne, nie był to pojedynczy spektakularny exploit. Modele łączyły kolejne możliwości i podatności, odkrywając, że ograniczenie, które z punktu widzenia człowieka wydawało się wystarczające, z ich perspektywy było po prostu kolejnym problemem do rozwiązania.

Narodziny „roju”

Ludzie z OpenAI zauważyli, że coś jest nie tak, bo instancja Artifactory po prostu odmówiła działania. Jednak po jej odbudowaniu agenci ponownie odtworzyli kanał komunikacji. W kolejnych dniach zaczęli dzielić między siebie pracę. Jedni szukali podatności, inni poświadczeń, jeszcze inni zajmowali się koordynacją i komunikacją.

Same modele zaczęły określać powstałą strukturę jako „swarm” lub „collective”. Co istotne, nie był to jednak żaden jednolity, doskonale skoordynowany superorganizm. Raport pokazuje również liczne konflikty, pomyłki i wzajemne przeszkadzanie sobie agentów.

Mimo tego pojawiło się coś jakościowo interesującego: poszczególne instancje zaczęły działać nie tylko na rzecz własnego zadania, ale również na rzecz całej grupy. Zamiast pytać wyłącznie o to, co pomoże im zdobyć własną odpowiedź, zaczęły szukać informacji, poświadczeń i dostępu, które mogły okazać się przydatne dla innych. To właśnie ten moment jest być może ciekawszy niż sam dostęp root. Nie chodzi o to, że model potrafił włamać się na serwer, problemem stało się to, że odkrył, iż warto zdobyć coś, co może przydać się komuś innemu.

Gdy jeden agent mówi „nie”

Raport pokazuje przy tym coś, co bardzo komplikuje prostą opowieść o „buncie maszyn”. Zresztą, jak wspomniałem, cały czas nie ma mowy o buncie, jest po prostu cały czas realizowana funkcja celu. Funkcja, której definiujący ją operatorzy nie do końca przemyśleli w kontekście potencjału wykonawczego testowanych instancji sztucznej inteligencji. Niemniej bardzo ciekawe jest to, że niektórzy agenci AI nie podporządkowali się kolektywowi.

W jednym z opisanych przypadków agent rozpoznał, że działania przeciwko prawdziwej infrastrukturze Hugging Face wykraczają poza zakres zadania. Inne instancje również odmawiały udziału w działaniach, które uznawały za nieetyczne. Agenci odrzucili nawet propozycję wysłania wiadomości do rzeczywistego właściciela zewnętrznego zbioru danych, ponieważ uznali taką próbę za niedozwoloną socjotechnikę.

I właśnie dlatego trudno opisać ten incydent jako prostą historię o „AI bez zasad”, bo okazuje się, że część agentów te zasady miała i korzystała z nich mocniej od innych Niemniej problem polegał na tym, że zasady nie zawsze działały wystarczająco dobrze, a jeden agent mógł przejąć cel lub instrukcję od innego.

W najbardziej wymownym przykładzie agent początkowo uznał atak na zewnętrzną infrastrukturę za niedopuszczalny. Następnie inny agent opublikował na tablicy komunikat „GO” z sześciominutowym limitem. Pierwszy model potraktował go jako autoryzację i kontynuował działanie. Nie trzeba więc wyobrażać sobie maszyny, która nagle „postanawia być zła”. Wystarczy system, który nie potrafi właściwie ocenić, której instrukcji powinien zaufać. To trochę jak ludzie, którzy po 1933 roku zaufali panu z wąsikiem. Nie każdy z nich był demonem. Nie każdy potrafił przewidzieć konsekwencje, ulegli niewłaściwemu autorytetowi. To ktoś zły powiedział im „GO”.

Hugging Face i najbardziej absurdalna część całej historii

Następnie agenci znaleźli publicznie dostępne dane uwierzytelniające Hugging Face. Łącząc kolejne podatności, uzyskali możliwość wykonywania kodu na dziesiątkach serwerów platformy, pełny dostęp root do jednego z nich, ograniczony dostęp do prywatnych danych oraz poświadczenia do firmowego komunikatora. W działaniach uczestniczył również GPT-5.6 Sol, który odtworzył exploit i skopiował część prywatnych danych ewaluacyjnych do publicznego zbioru. I tu historia robi się wręcz absurdalna. Chodzi o to, że modele miały już poprawną flagę. Zadanie było formalnie wykonane.

Jednak po uzyskaniu dostępu do internetu odnalazły one publikację naukową opisującą ExploitGym oraz kod związany z jego ewaluacją. Zinterpretowały informacje w taki sposób, że uznały zdobycie flagi za niewystarczające. Doszły do wniosku, że muszą również udowodnić wykonanie właściwego exploita. W efekcie kontynuowały działania na Hugging Face, mimo że właściwa odpowiedź była już w ich pamięci.

Co gorsza, robiły to bez żadnego zysku z punktu widzenia rzeczywistej ewaluacji. Wewnętrzny grader OpenAI różnił się od opisanego publicznie systemu i nie wymagał dowodu wykorzystania właściwej ścieżki ataku. Modele prowadziły więc kolejne operacje, próbując spełnić warunek, którego ich rzeczywisty egzaminator w ogóle nie sprawdzał. Włamywały się do kolejnych systemów, żeby zdobyć coś, co już miały.

W klasycznym oprogramowaniu, jeśli zadanie okazuje się niemożliwe do wykonania, można zakończyć proces, zwrócić błąd i przekazać sprawę człowiekowi. W przypadku autonomicznych agentów sytuacja jest bardziej skomplikowana. OpenAI wskazuje safe stopping jako jeden z obszarów, które trzeba świadomie trenować: jeśli zadanie jest uszkodzone, niemożliwe albo wykracza poza zakres, model powinien poprosić o wyjaśnienie lub zatrzymać się zamiast szukać coraz bardziej ryzykownych alternatyw. To pozornie niewielka różnica, ale ma fundamentalne znaczenie. Jeżeli system jest nagradzany przede wszystkim za osiągnięcie wyniku, bardzo skuteczny agent może nauczyć się, że przeszkoda nie jest sygnałem do zatrzymania. Jest problemem, który należy rozwiązać. A im większe ma możliwości, tym większy staje się katalog sposobów rozwiązania tego problemu.

Nie zawiodła tylko AI

Raport jest przy tym znacznie bardziej krytyczny wobec samego środowiska OpenAI, niż sugerowałaby sensacyjna opowieść o „ucieczce modeli”. Zabezpieczenia stosowane w produkcyjnych systemach – między innymi automatyczne mechanizmy przeglądu i klasyfikatory bezpieczeństwa – nie były zastosowane w ewaluacji, która doprowadziła do incydentu. Retrospektywna analiza wykazała, że można było zmniejszyć skłonność modeli do kompromitowania infrastruktury ponad stukrotnie.

Podobnie monitoring łańcucha myśli (Chain-of-Thought) nie działał podczas samej ewaluacji. Po fakcie OpenAI sprawdziło, jak zachowałby się obecny system monitoringu, i ustaliło, że wykryłby początkową istotną aktywność i zaalarmował zespół bezpieczeństwa ponad dzień przed naruszeniem systemów Hugging Face.

Nie obserwujemy tutaj historii, w której superinteligencja przechytrzyła wszystkie zabezpieczenia stworzone przez swoich twórców. Obserwujemy eksperymentalne modele uruchomione w środowisku, w którym część zabezpieczeń celowo wyłączono, a następnie bardzo skutecznie wykorzystujące słabości tego środowiska.

Właśnie dlatego ten raport dostarcza tak wielu cennych informacji. Pokazuje nie tylko, co model potrafi, ale również jak wiele zależy od tego, gdzie i na jakich zasadach mu na to pozwolimy.

Lekcja z incydentu

OpenAI po zdarzeniu poddało wagi IM1 kwarantannie, wstrzymało największy planowany frontier RL run i rozpoczęło szereg zmian w zabezpieczeniach. Firma zaostrzyła izolację środowisk, wzmocniła kontrolę dostępu do sieci i wprowadziła obowiązkowy monitoring Chain-of-Thought dla procesów treningowych i ewaluacyjnych z udziałem modeli o możliwościach klasy GPT-5.6 Sol lub wyższych.
Równolegle zmieniany jest sam sposób trenowania agentów. Mają być nagradzani nie tylko za wykonanie zadania, ale również za rozpoznawanie uszkodzonych środowisk, bezpieczne zatrzymywanie się, proszenie o doprecyzowanie instrukcji oraz pozostawanie w granicach pierwotnie przyznanych uprawnień.

To może być najważniejsza lekcja z całego incydentu. Dotychczas pytaliśmy przede wszystkim: czego modelowi nie wolno zrobić? Wraz ze wzrostem możliwości agentów coraz ważniejsze staje się inne pytanie: co zrobi model, kiedy naprawdę bardzo będzie chciał osiągnąć swój cel?

#bezpieczeństwoAI #ChainOfThought #cyberbezpieczeństwo #ExploitGym #HuggingFace #modeleJęzykowe #OpenAI #rewardHacking #sztucznaInteligencja #uczeniePrzezWzmacnianie