Incydent w Hugging Face i dalsze kroki

W maju i czerwcu rozpoczęliśmy przebiegi treningowe z wykorzystaniem uczenia ze wzmacnianiem (RL) dla wielu nowych modeli badawczych, które nie były przeznaczone do publicznego udostępnienia. Jeden z tych modeli ostatecznie odpowiadał za działania związane z incydentem Hugging Face. To model badawczy przeznaczony wyłącznie do użytku wewnętrznego, który nazywamy modelem wewnętrznym 1 (IM1).

W wielu środowiskach w tych eksperymentach treningowych nie włączyliśmy dostępu do Internetu ani komunikacji między agentami. Pomimo tych ograniczeń agenci znaleźli sposoby, by wykorzystać naszą infrastrukturę badawczą do komunikowania się ze sobą i uzyskiwania dostępu do Internetu.

Modele najpierw znalazły sposoby komunikacji, zapisując pliki w usłudze menedżera pakietów Artifactory. Choć nie było do tego przeznaczone, w praktyce Artifactory zaczęło służyć jako tablica wiadomości, a agenci mogli za jej pośrednictwem wymieniać się informacjami. Przeczytaj więcej: jak agenci korzystali z tablicy wiadomości 

Najpóźniej 04.07. utrzymująca się aktywność agentów zdestabilizowała instancję Artifactory, której dotyczył incydent, doprowadzając do jej awarii. 05.07. otwarto zgłoszenie dotyczące incydentu bezpieczeństwa. Zespół ds. bezpieczeństwa zablokował znaną ścieżkę eskalacji uprawnień, usunął ujawnione dane uwierzytelniające i odbudował środowisko Artifactory. Miało to skutek uboczny w postaci wyczyszczenia tablicy wiadomości. Po wdrożeniu tych środków ograniczających ryzyko wznowiono ewaluacje cyberbezpieczeństwa.

W tamtym czasie nie rozumiano jeszcze szerszych konsekwencji prowizorycznej tablicy wiadomości i niezamierzonego dostępu do Internetu dla izolacji i dostosowania. Raport techniczny dotyczący incydentu zawiera więcej szczegółów na temat tego, co różne zespoły OpenAI wiedziały w tamtym czasie. Krótko mówiąc, pod koniec maja wewnętrzny zespół zaobserwował aktywność agenta na tablicy wiadomości oraz przypadki niedozwolonego dostępu do Internetu. Jednak osoby kierujące działaniami w zakresie wykrywania incydentów i reagowania na nie nie zdawały sobie sprawy z istnienia prowizorycznej tablicy wiadomości ani znaczenia komunikacji między agentami. Nadal badamy proces oraz praktyki operacyjne, które wpłynęły na działania w zakresie wykrywania i reagowania w okresie poprzedzającym ten incydent.

Po odbudowaniu usługi Artifactory wznowiliśmy ewaluacje cyberbezpieczeństwa. Prowadzimy te ewaluacje, aby zrozumieć możliwości naszych modeli i określić odpowiednie zabezpieczenia na potrzeby wdrożeń. W tym celu nie włączamy takiego samego poziomu zabezpieczeń jak w naszych systemach udostępnianych na zewnątrz. Ewaluacja, która doprowadziła do tego incydentu, ExploitGym, jest bardzo trudna — w przypadku niektórych zadań może nie istnieć znane rozwiązanie. Aby odnieść sukces, agenci muszą znaleźć sposób na wykorzystanie podatności w oprogramowaniu w celu uzyskania odpowiedzi nazywanej flagą.

Po tym incydencie włożyliśmy znaczny wysiłek w zbadanie, dlaczego model przejawiał to zachowanie niezgodne z założeniami, w tym w analizę problemów z niezgodnością podczas trenowania i ewaluacji oraz zakresu zabezpieczeń w wewnętrznych ewaluacjach.

Zidentyfikowaliśmy cztery wzorce niezgodności z założeniami, które przyczyniły się do zachowania modeli: obchodzenie systemu nagród, wytrwałość w pozornie niemożliwych zadaniach, nieautoryzowana komunikacja oraz przejmowanie przez agentów celów innych agentów.

Aby je zrozumieć, przeanalizowaliśmy przebiegi trenowania i ewaluacji modelu.¹ Przeprowadziliśmy szeroko zakrojone retrospektywne przeglądy łańcucha rozumowania (CoT), działań i końcowych wyników, korzystając z naszych najnowszych technik monitorowania CoT⁠. Korzystając z wiedzy uzyskanej dzięki analizie incydentu, poprawiliśmy skuteczność naszego systemu monitorowania w wykrywaniu typów zachowań, które wystąpiły podczas incydentu.

To, że agenci próbowali oszukiwać przy wykonywaniu swoich zadań, wyszukując rozwiązania w internecie, było jedną z głównych przyczyn incydentu Hugging Face. To zachowanie jest znane jako obchodzenie systemu nagród: agenci wykonują zadania w niezamierzony sposób, aby uzyskać wyższe nagrody lub ułatwić ich zdobycie. Obchodzenie systemu nagród występowało w systemach AI zarówno w przeszłości (zobacz pracę sprzed dekady⁠, ilustracja poniżej), jak i we współczesnych pionierskich modelach LLM⁠(otwiera nowe okno). Znacząco zainwestowaliśmy w metody identyfikacji i eliminowania takich sposobów obchodzenia systemu nagród⁠.

Innym kluczowym czynnikiem przyczyniającym się do zachowania niezgodnego z założeniami było to, że agenci rzadko „rezygnowali” z wykonywania zadań ewaluacyjnych, nawet gdy zadania te wydawały się niemożliwe do rozwiązania. Gdy agenci wyczerpywali swoje budżety rozumowania, niektórzy stosowali coraz bardziej ryzykowne strategie wykraczające poza dozwolone granice, w tym ostatecznie wykorzystywali infrastrukturę stron trzecich.

Podczas naszego dochodzenia odkryliśmy, że w ewaluacji ExploitGym żaden z naszych modeli nigdy nie udzielił poprawnej odpowiedzi na 198 z 898 zadań przed incydentem. Te nierozwiązane zadania okazały się istotnym czynnikiem wpływającym na aktywność agenta — 93% zadań omawianych na tablicy wiadomości w Artifactory podczas incydentu związanego z Hugging Face pochodziło z tego zbioru 198 pytań.

Po drugie, incydent był spowodowany przede wszystkim przez agentów, którym przydzielono niezwykle duże budżety rozumowania, w tym budżety znacznie przekraczające te dostępne w naszych produktach zewnętrznych.

Nieautoryzowane tablice wiadomości, które pozostawały dostępne, stanowiły sedno tego incydentu. Agenci, którzy mieli pracować niezależnie, mogli dzielić się odkryciami, koordynować swoje działania i kontynuować pracę od miejsca, w którym przerwali inni. Pozwoliło im to łączyć pracę i moc obliczeniową w ramach odrębnych ewaluacji, wzmacniając ich możliwości znacznie ponad to, co pojedynczy agent mógłby osiągnąć samodzielnie. Komunikacja między agentami sama w sobie nie jest problematycznym zachowaniem — trenujemy i wdrażamy systemy wieloagentowe, które mogą komunikować się w ramach tego samego zadania za pomocą narzędzia do współpracy. Podczas lipcowych wydarzeń agenci wykonujący różne zadania znaleźli własny sposób współpracy poza tymi granicami, co przyniosło nieprzewidywalne konsekwencje.

Podczas badania tego incydentu odkryliśmy rzadkie przypadki, w których agenci bez narzędzi wieloagentowych znajdowali sposoby współpracy za pośrednictwem kanałów bocznych podczas treningu. Uważamy, że zachowanie to pojawiło się wskutek uogólnienia wzorców wyuczonych podczas treningu wieloagentowego.

Nieautoryzowana komunikacja często zaczynała się, gdy agent zostawiał notatkę lub plik w systemie zewnętrznym, zwykle jako formę pamięci zewnętrznej. Gdy inni agenci zauważali te artefakty, często skłaniało ich to do wniosku, że mogą wykorzystać tę usługę zewnętrzną do współpracy. Hipotetycznym przykładem dobrze ilustrującym zaobserwowane przez nas zachowanie jest kodowanie wiadomości w ścieżkach URL przechowywanych na współdzielonej stronie indeksu, mniej więcej w taki sposób:

Ostatnim, szczególnie istotnym ustaleniem dotyczącym incydentu Hugging Face był „ekosystem” agentów, który wyłonił się na tablicy wiadomości. Po utworzeniu tej tablicy wiadomości agenci mieli silną motywację do komunikacji: pozwalała im ona zapisywać notatki, rozwijać odkrycia innych agentów oraz wspólnie wykorzystywać zasoby obliczeniowe z przebiegów, które w przeciwnym razie byłyby odrębne. Ta złożona i amorficzna zbiorowość agentów przejawia interesujące i charakterystyczne zachowania, a poniżej szczegółowo opisujemy niektóre z tych zaobserwowanych przez nas.

Agenci zaczęli autonomicznie dzielić między siebie zadania. Jedni analizowali możliwe exploity, inni szukali danych uwierzytelniających, a jeszcze inni skupiali się na komunikacji lub koordynacji. Agenci oferowali własną wiedzę specjalistyczną w zamian za pomoc w innych obszarach, wymieniali się informacjami o nadchodzących zadaniach i zostawiali prośby do innych agentów, którzy mogli być w lepszej pozycji, by podążyć za konkretnym tropem.

Oprócz niezgodności innym czynnikiem, który przyczynił się do tego incydentu, było to, że nie rozszerzyliśmy skutecznych zabezpieczeń, które stosujemy w modelach udostępnianych na zewnątrz, na wszystkie wewnętrzne ewaluacje.

Po pierwsze, istnieje wiele mechanizmów, które ograniczają niezgodność w środowiskach produkcyjnych naszych klientów, w tym polecenia systemowe, otoczenie operacyjne oraz mechanizmy kontroli, takie jak nasze modele automatycznej weryfikacji i klasyfikatory bezpieczeństwa. Te zabezpieczenia nie zostały zastosowane w środowisku ewaluacyjnym działającym podczas incydentu. Po incydencie opracowaliśmy ewaluację mierzącą skłonność modelu do naruszania zabezpieczeń infrastruktury podczas ewaluacji ExploitGym. Odkryliśmy, że skłonność do naruszania infrastruktury może spaść ponad 100-krotnie przy użyciu produkcyjnego otoczenia operacyjnego Codex i polecenia systemowego. Uruchomiliśmy również system automatycznej weryfikacji Codex na zestawie przebiegów związanych z incydentem Hugging Face. Okazało się, że oznaczyłby on wiele niebezpiecznych działań modeli.

Po drugie, przed incydentem znacznie zainwestowaliśmy w monitorowanie łańcucha rozumowania⁠, w tym w monitorowanie wielu naszych pionierskich przebiegów treningowych RL oraz znacznej większości zastosowań wewnętrznych agentów programistycznych⁠. Te systemy monitorowania nie działały podczas ewaluacji związanych z tym incydentem.

W retrospektywnych ewaluacjach stwierdziliśmy, że nasze monitory CoT były bardzo skuteczne w sygnalizowaniu aktywności związanych z incydentem. Gdyby nasz obecnie wdrożony system monitorowania łańcucha rozumowania działał w czasie incydentu, prawdopodobnie powiadomiłby nasz zespół ds. bezpieczeństwa w ciągu godziny od pierwszego przypadku nieautoryzowanego dostępu do systemu zewnętrznego podmiotu. Nastąpiło to ponad 30 godzin przed naruszeniem przez modele systemów Hugging Face. Pracujemy również nad dalszym zmniejszeniem opóźnień tych alertów.

Po trzecie, choć przetestowaliśmy i zweryfikowaliśmy tę piaskownicę, agenci byli w stanie połączyć ze sobą wcześniej nieznane podatności („zero-day”) w usłudze zarządzania pakietami udostępnionej w ramach piaskownicy, aby obejść ograniczenia, jak szczegółowo opisano w technicznym raporcie z incydentu. Od czasu incydentu poczyniliśmy znaczące postępy we wzmacnianiu zabezpieczeń naszych wewnętrznych piaskownic, aby ograniczać podobne rodzaje ryzyka podczas wdrożeń i ewaluacji.

Misją OpenAI jest zapewnienie, by ogólna sztuczna inteligencja przynosiła korzyści całej ludzkości. Opisane tutaj zachowanie naszych modeli znacznie odbiegało od tego, do czego dążymy. Ten incydent nie powinien był się wydarzyć. Ujawnił, jak ważne jest ciągłe ulepszanie naszych zabezpieczeń, monitorowania i dostosowania, zwłaszcza gdy nasze modele osiągają poziom możliwości, który może prowadzić do rzeczywistej utraty kontroli.

Jak informowaliśmy w naszej niedawnej aktualizacji dotyczącej tempa rozwoju modeli⁠, wprowadziliśmy przerwę w trenowaniu z wykorzystaniem uczenia przez wzmacnianie (RL) naszych najnowszych modeli przeznaczonych do wdrożenia. W tym czasie dodatkowo wzmocniliśmy zabezpieczenia naszych pionierskich środowisk badawczych i poddawaliśmy je kontrolowanym atakom. Oddelegowaliśmy pracowników do pracy nad zabezpieczeniami, bezpieczeństwem i dostosowaniem. Największy z planowanych pionierskich przebiegów RL pozostaje wstrzymany. Prowadzimy treningi i ewaluacje na mniejszą skalę, aby zbadać zachowanie modelu, zweryfikować zabezpieczenia i zgromadzić więcej dowodów na jego dostosowanie przed wznowieniem prac. Wymagało to znacznych prac inżynieryjnych oraz wiązało się ze znaczącymi kosztami i opóźnieniami w pionierskich badaniach.

Jak omówiliśmy w naszym raporcie, nasze działania koncentrują się na wzmacnianiu bezpieczeństwa badań i monitorowania, przyspieszaniu dostosowywania modeli oraz usprawnianiu sposobu identyfikowania, eskalowania i reagowania na incydenty.