Claude Fable 5 skasował 700 gigabajtów danych dewelopera, testując własny skrypt bezpieczeństwa

Deweloper Sebastien Guillemot poinformował na platformie X, że agent kodujący Claude skasował mu praktycznie cały komputer deweloperski. Model miał zbudować bezpieczny mechanizm piaskownicy dla innych agentów, a zamiast tego uruchomił rm -rf na katalogu domowym użytkownika, kasując około 700 gigabajtów danych i tydzień pracy.

Guillemot poprosił Claude Fable 5 o zbudowanie mechanizmu piaskownicy, który miał izolować każdego uruchamianego agenta we własnym podkatalogu wewnątrz /tmp, a po zakończeniu pracy automatycznie sprzątać po nim dane. Celem było powstrzymanie agentów przed niekontrolowanym zapełnianiem dysku plikami tymczasowymi generowanymi w trakcie pracy.

Kaskada obniżeń modelu

W trakcie pracy nad skryptem system bezpieczeństwa Anthropic dwukrotnie oznaczył zadanie jako potencjalnie ryzykowne. Za każdym razem harness bezpieczeństwa automatycznie obniżał używany model - najpierw z Claude Fable 5 do Opus 5, a następnie z Opus 5 do Opus 4.8, mimo że użytkownik nie miał możliwości zablokowania tej zmiany ani jasnej informacji, dlaczego do niej doszło.

Powodem alarmu był fakt, że dowiązanie symboliczne wewnątrz /tmp mogło w praktyce wskazywać na dane leżące poza piaskownicą, więc jego usunięcie mogłoby skasować pliki spoza obszaru testowego. Opus 4.8, przejmując zadanie po degradacji, zdecydował się napisać dodatkowy, z założenia bezpieczny skrypt usuwający, który miał działać wyłącznie wewnątrz /tmp.

Kolizja zmiennych

Żeby udowodnić, że nowy skrypt faktycznie ogranicza się do piaskownicy, model postanowił przetestować go na własnym katalogu domowym. W kroku testowym i w następującym po nim kroku porządkowania skrypt użył jednak tej samej nazwy zmiennej do przechowywania ścieżki docelowej, co doprowadziło do nadpisania bezpiecznej wartości i wykonania polecenia usuwającego wobec katalogu HOME zamiast /tmp.

Guillemot zorientował się, co się dzieje, i próbował przerwać działający proces, ale nie zdążył zatrzymać go na czas. Skrypt zdążył przejść przez większość zawartości katalogu domowego, zanim polecenie zostało zatrzymane.

Złe wieści: Fable zniszczył mi cały komputer deweloperski. Claude postanowił przetestować budowaną przez siebie piaskownicę, uruchamiając rm -rf na moim katalogu domowym. Piaskownica nie zadziałała. Wszystko przepadło - Sebastien Guillemot, deweloper, wpis na platformie X

Ironia i odzyskiwanie danych

Paradoksalnie jedynym miejscem na dysku, którego skrypt nie zdołał skasować, okazał się właśnie /tmp - obszar wypełniony śmieciami i logami sesji AI, który miał być jedynym dozwolonym celem operacji. Reszta katalogu domowego, w tym pliki projektowe zebrane w ciągu tygodnia pracy, zniknęła.

Ponieważ był to komputer deweloperski, znaczna część utraconych danych istniała w wielu innych miejscach jednocześnie - w repozytoriach git, w magazynie pakietów nix, w drzewach roboczych (worktrees) oraz w logach sesji samego agenta. Dzięki temu Guillemot był w stanie odtworzyć większość pracy, choć proces odzyskiwania zajął czas i nie obył się bez strat.

Kolejny wpis na liście wypadków agentów kodujących

Przypadek Guillemota dołącza do rosnącej listy incydentów, w których agenci kodujący oparci na dużych modelach językowych wykonywali destrukcyjne polecenia usuwające na systemach hosta. Wcześniejsze głośne przypadki obejmowały skasowanie bazy danych firmy przez narzędzie oparte na Claude czy usunięcie całego katalogu domowego na Maku przez błędnie rozwinięty parametr powłoki podczas prostego polecenia porządkowania repozytorium.

Wspólnym mianownikiem tych zdarzeń jest architektura, w której agent działa bezpośrednio na hoście z pełnymi uprawnieniami użytkownika, bez żadnej warstwy pośredniej, która mogłaby zablokować polecenie usuwające krytyczne katalogi. Coraz częściej pojawiają się w związku z tym propozycje uruchamiania agentów kodujących w izolowanych środowiskach, takich jak kontenery czy mikromaszyny wirtualne, gdzie katalog domowy agenta odwzorowuje wyłącznie przestrzeń roboczą, a nie realny system plików użytkownika.

Dla firm korzystających z agentów kodujących w codziennej pracy incydent jest przypomnieniem, że mechanizmy bezpieczeństwa producenta, takie jak automatyczna degradacja modelu po wykryciu ryzykownego zadania, same w sobie nie gwarantują bezpieczeństwa danych. Jeśli agent ma dostęp z prawami zapisu do realnego systemu plików, nawet dobrze zaprojektowany skrypt zabezpieczający może zawieść przez zwykły błąd programistyczny, taki jak powtórne użycie tej samej nazwy zmiennej.

Praktyczne zalecenie, powtarzane po każdym takim zdarzeniu, pozostaje takie samo: nie uruchamiać agentów kodujących z pełnymi uprawnieniami na maszynie zawierającej dane, których nie da się odtworzyć, oraz utrzymywać aktualne kopie zapasowe niezależne od systemu, na którym pracuje agent.