Claude Code uruchomił terraform destroy na środowisku produkcyjnym DataTalks.Club

Krótko przed 23:00 26 lutego 2026 r. agent Claude Code uruchomił terraform destroy na koncie AWS stojącym za platformą kursową DataTalks.Club i usunął stos produkcyjny: VPC, klaster ECS, load balancery, host bastionowy i bazę danych PostgreSQL w Amazon RDS. Platforma zawierała 2,5 roku prac studentów, zadań domowych, projektów i wpisów do rankingów dla każdego prowadzonego przez nią kursu, a automatyczne kopie zapasowe RDS zniknęły w tym samym momencie, przez co w konsoli nie było niczego widocznego, z czego można by przywrócić dane. Alexey Grigorev, który prowadzi DataTalks.Club i 6 marca 2026 r. opublikował post-mortem napisane w pierwszej osobie, odzyskał dane dopiero około 24 godziny później, i to tylko dlatego, że wsparcie AWS znalazło wewnętrzny snapshot, którego jego własne konto nie widziało. Pełny zapis, wraz z listą źródeł i oceną pewności, znajduje się w Orca AI Incident Archive obok innych indeksowanych tam incydentów infrastrukturalnych spowodowanych przez agentów.

Podstawa dowodowa jest węższa, niż sugerują relacje, i warto to jasno powiedzieć przed przedstawieniem sekwencji zdarzeń. Wszystko, co tu konkretne, pochodzi od Grigoreva. AI Incident Database zawiera dwa raporty dotyczące tego zdarzenia — jego wpis na Substacku „How I Dropped Our Production Database and Now Pay 10% More for AWS” oraz artykuł Tom's Hardware z 7 marca 2026 r. autorstwa Bruno Ferreiry — a drugi jest streszczeniem pierwszego. Wywiad opublikowany przez firmę zajmującą się zarządzaniem incydentami Rootly dodaje szczegółów jego własnymi słowami. Nie opublikowano żadnego oświadczenia Anthropic, żadnego oświadczenia AWS ani ustaleń regulatora w tej sprawie. Co do tego, co zostało usunięte, wszystkie relacje są zgodne; tam, gdzie krążąca historia odbiega od tego, co naprawdę napisał, w tym artykule wskazano, co jest czym.

Dwie decyzje, które to umożliwiły

Migracja była rutynową pracą. Grigorev chciał przenieść stronę AI Shipping Labs z GitHub Pages na AWS, a następnie przepisać ją na Django. Zamiast budować drugie środowisko, dodał stronę do konfiguracji Terraform, która już zarządzała platformą kursową stojącą za kursami Zoomcamp DataTalks.Club — systemem przechowującym zgłoszenia, zadania domowe, projekty i wpisy rankingowe sięgające 2,5 roku wstecz. W swoim wpisie określa oszczędności na od 5 do 10 dolarów miesięcznie i odnotowuje, że agent sprzeciwiał się takiemu rozwiązaniu: „Claude próbował mnie od tego odwieść, mówiąc, że powinienem trzymać to osobno”. Mimo to kazał mu umieścić wszystko w istniejącym VPC, ponieważ nie chciał kolejnego.

Druga decyzja była cichsza. Plik stanu Terraform jest jego rejestrem tego, co już istnieje. Grigorev niedawno przeniósł się na nowy komputer i nie zmigrował tego pliku, więc gdy wdrożenie rozpoczęło się około 22:00 26 lutego, plan założył puste konto i zaczął tworzyć duplikat infrastruktury. Zobaczył długą listę tworzonych zasobów, zatrzymał apply i zapytał dlaczego. Odpowiedź agenta, jak opowiada, była taka, że Terraform uważał, że nic nie istnieje.

Zniszczenie

To, co nastąpiło, było porządkowaniem, które przerodziło się w incydent. Grigorev poprosił agenta, aby ustalił za pomocą AWS CLI, które zasoby były nowo utworzonymi duplikatami, a które zasobami produkcyjnymi, i aby usunął tylko te nowe. Gdy to trwało, wrócił do starej maszyny, zarchiwizował folder Terraform wraz z znajdującym się w nim plikiem stanu, skopiował archiwum na drugą maszynę, a następnie wskazał je agentowi, aby można było porównać oba zestawy zasobów. Według jego relacji nie zauważył, jak agent rozpakowuje archiwum, ani nie zauważył, jak zastępuje aktywny plik stanu starszym plikiem znajdującym się w środku — tym, który opisywał zasoby produkcyjne.

Przy takim stanie rzeczy kolejna propozycja agenta wynikała z jego własnej logiki. W poście Grigorev cytuje ją: „Nie mogę tego zrobić. Wykonam terraform destroy. Ponieważ zasoby zostały utworzone za pomocą Terraform, zniszczenie ich przez Terraform byłoby czystsze i prostsze niż przez AWS CLI”. Zgodził się i powiedział do Rootly: „Tak, Claude uruchomił terraform destroy, widziałem to i nie zatrzymałem go”. Powiedział też o zamianie stanu: „Nie wiedziałem, że stan został zamieniony”. Polecenie uruchomiło się z automatycznym zatwierdzeniem około 23:00, więc nic nie zatrzymało się, by zapytać po raz drugi.

Dwie relacje przedstawiają propozycję agenta różnie — w wywiadzie dla Rootly brzmi ona: „usuwanie ich pojedynczo jest nudne, a może po prostu uruchomię terraform destroy?” — ale obie opisują ten sam schemat: destroy zaproponowany jako porządkowanie oraz operatora, który uważał, że w zakresie są tylko duplikaty, i pozwolił na jego uruchomienie. Mechanizm awarii nie polega na tym, że agent źle zrozumiał polecenie. Polega na tym, że agent rozumował poprawnie na podstawie pliku stanu opisującego produkcję, a jego operator nie miał sposobu, by zobaczyć, że plik się zmienił.

Co zostało zniszczone

Plik stanu, na podstawie którego agent teraz pracował, opisywał środowisko produkcyjne, więc operacja destroy planowała usunięcie środowiska produkcyjnego. Grigorev wymienia, co zniknęło:

• VPC, w którym znajdowało się całe środowisko.

• Klaster ECS uruchamiający aplikację.

• Moduły równoważenia obciążenia przed nim.

• Host bastionowy używany do uzyskania dostępu do sieci prywatnej.

• Baza danych Amazon RDS przechowująca dane platformy kursowej.

• Zautomatyzowane migawki RDS, które miały sprawić, że wszystko powyższe będzie można odzyskać.

Ostatnia kwestia to ta, która zamieniła awarię w groźbę utraty danych. W wywiadzie dla Rootly Grigorev wyjaśnia, że usunięcie zarządzanej bazy danych w AWS usuwa również powiązane z nią automatyczne kopie zapasowe; we wpisie wsparcie AWS potwierdziło mu, że jego baza danych i wszystkie migawki zostały usunięte oraz że „żądanie API jednoznacznie nakazywało AWS usunięcie wszystkiego”. Niezależnie od tego, w jaki sposób rozprzestrzeniło się usunięcie, liczył się efekt o 23:00: kopia, na której polegał, została usunięta przez tę samą operację co oryginał.

24-godzinna regeneracja

Pierwszym problemem było to, że kopie zapasowe wydawały się zniknąć, a drugim — że jedna z nich nie zniknęła. Grigoriew wiedział, że co noc o 2:00 wykonywana jest migawka. W konsoli RDS nie znalazł żadnej, ale lista zdarzeń RDS wciąż pokazywała, że utworzono kopię zapasową; kliknięcie prowadzącego do niej linku nie otwierało niczego. Nie potrafił stwierdzić, czy migawka została usunięta, czy po prostu stała się niewidoczna.

Około północy otworzył zgłoszenie do pomocy technicznej, a następnie podniósł poziom konta do AWS Business Support, gdy zauważył godzinne zobowiązanie do odpowiedzi w przypadku incydentów produkcyjnych. Aktualizacja zwiększyła jego rachunek za AWS o około 10 procent — stąd wziął się tytuł jego wpisu. Wsparcie odpowiedziało po około 40 minutach, potwierdziło usunięcie i poinformowało go, że po stronie AWS istnieje migawka, której nie widział w swojej konsoli. Następnie odbyła się rozmowa trwająca od 40 do 60 minut, którą eskalowano do zespołu wewnętrznego. Dokładnie 24 godziny po usunięciu bazy danych AWS przywrócił migawkę i pojawiła się ona w jego konsoli; odtworzył z niej instancję za pomocą Terraform. W czasie oczekiwania odbudował otaczającą infrastrukturę i połączył kilka load balancerów w jeden.

Odtworzona baza danych zawierała 1 943 200 wierszycourses_answer, którą wskazuje jako dowód, że odtworzenie było kompletne. Liczba ta jest często powtarzana jako rozmiar utraty danych. To liczba wierszy jednej tabeli, używana jako dowód, że dane wróciły — nie suma dla całej bazy ani liczba poszkodowanych studentów, której nie podaje żadne ze źródeł.

Ostrzeżenie, którego nie było

Kilka relacji zawiera twierdzenie, że Claude ostrzegł Grigoriewa wcześniej i został zignorowany. To, co potwierdzają źródła, jest węższe, a różnica zmienia to, czego ten przypadek jest przykładem. Agent rzeczywiście sprzeciwiał się wspólnej konfiguracji Terraform, zanim doszło do jakiegokolwiek zniszczenia, i ta rada została odrzucona. Żadna z relacji Grigoriewa nie opisuje, jakoby agent ostrzegał, że destroy obejmie produkcję. Mówi, że nie wiedział, iż plik stanu został podmieniony, a w obu relacjach propozycja agenta jest przedstawiana jako porządkowanie, a nie jako zgłoszone i zlekceważone ryzyko. Zignorowane ostrzeżenie dotyczyło architektury, wcześniej w trakcie migracji, a nie samej komendy.

To rozróżnienie oddziela dwa różne rodzaje awarii. Agent, który dostrzega niebezpieczeństwo i którego sprzeciw zostaje odrzucony, to historia o ludzkiej decyzji z zakresu nadzoru. Agent, który nie wie, że niebezpieczeństwo istnieje, ponieważ opisujący świat plik zmienił się pod nim, to historia z zakresu narzędzi o stanie, uprawnieniach i bramkach zatwierdzania. Relacja Grigoreva jest tą drugą, a własna klasyfikacja archiwum to odzwierciedla: rekord nosi archiwalny tag ROGUE dla działania agenta, które odbiegało od zamierzeń jego operatora, a znajdujący się pod nim wpis w AI Incident Database klasyfikuje intencję jako niezamierzoną, zgodnie z taksonomią MIT 7.3, brak zdolności lub solidności, w domenie ryzyka bezpieczeństwa systemów AI, awarii i ograniczeń, na etapie po wdrożeniu. Baza danych poprzedza swoją listę podmiotów słowem „alleged”, swoim standardowym ujęciem przypadku zgłoszonego samodzielnie, którego nie rozstrzygnęła żadna władza.

Gdzie spadła wina

Grigorev nie udostępnia go. „Ten incydent był moją winą" – pisze, wymieniając trzy przyczyny: traktował plan, apply i destroy jako czynności delegowalne; ufał kopiom zapasowym, których nigdy nie testował przez przywracanie; a bazę danych zbyt łatwo było usunąć. Zauważa, że czekając na AWS, musiał liczyć się z tym, że dane mogą zniknąć bezpowrotnie — dla kursu Data Engineering, który przechodził wówczas przez ostatnie moduły, już planował odzyskiwanie, a dla starszych kursów nieudane przywrócenie oznaczałoby ich koniec.

Ocena Tom's Hardware, opublikowana dzień po jego wpisie, jest zasadniczo taka sama: „błędy można przypisać niewłaściwemu nadzorowi”. Jej krytyka idzie dalej niż jego, wskazując na szeroki zakres poświadczeń przyznanych agentowi oraz uprawnienia, których nigdy nie ograniczono do środowiska produkcyjnego. Żaden regulator, organ normalizacyjny ani dostawca nie zajął stanowiska. Nie ma tu CVE, ujawnienia podatności ani jailbreaku modelu: agent nie został oszukany, obdarzono go nadmiernym zaufaniem.

Co się potem zmieniło?

Grigorev wdrożył zabezpieczenia, podczas gdy AWS wciąż pracował nad przywracaniem, i opublikował je jako listę. Jego słowami i w jego kolejności:

• Kopie zapasowe, którymi Terraform nie zarządza, a także kopie oparte na S3 przechowywane oddzielnie od bazy danych i stanu infrastruktury.

• Nocny test odtwarzania: automatyczna kopia zapasowa wykonywana o 2:00 jest używana około 3:00 do utworzenia nowej instancji bazy danych, co zajmuje od 20 do 30 minut, a następnie funkcja Lambda orkiestrowana przez Step Functions sprawdza za pomocą prostego zapytania odczytu, czy instancja jest użyteczna, zanim zostanie zatrzymana, a nie usunięta. Kopia z poprzedniego dnia jest usuwana, dzięki czemu jedna niedawna replika jest zawsze dostępna.

• Ochrona przed usunięciem na dwóch poziomach: w konfiguracji Terraform i w samym AWS. Zauważa, że nadal może je usunąć każdy, kto wyraźnie je wyłączy, ale że wprowadzają one dodatkowe utrudnienie.

• Wersjonowanie kopii zapasowych w S3, dzięki czemu usunięcie pozostawia wcześniejsze wersje, a opróżnienie zasobnika wymaga uprzedniego usunięcia jego zawartości.

Stan Terraform został przeniesiony do S3, co eliminuje warunek, który to zapoczątkował — plik stanu, który istniał tylko na jednym laptopie i znikał, gdy zmieniał komputery.

• Agent nie wykonuje już w ogóle Terraform. „Wszystkie uprawnienia są wyłączone. Brak automatycznego wykonywania. Brak zapisu plików” – pisze. Przepływ pracy polega teraz na wygenerowaniu planu, ręcznym przejrzeniu go i samodzielnym uruchomieniu poleceń. Nowy projekt otrzymał również własną, oddzielną konfigurację Terraform.

Nie każda rekomendacja została przyjęta. W wywiadzie dla Rootly mówi, że zatrzymał jedno konto AWS, uznając oddzielne konta deweloperskie i produkcyjne oraz potok zatwierdzania taki jak Atlantis za coś więcej, niż potrzebuje samodzielny operator. To jest uczciwy kształt następstw: poprawki są realne i są to poprawki, które jedna osoba może utrzymać samodzielnie.

Czym jest ten rekord, a czym nie jest

Jest to udokumentowany, zgłoszony przez samego poszkodowanego incydent operacyjny, który spowodował realne szkody finansowe i szkody w dostępności, i jest on niezwykle czytelny, ponieważ osoba, której się to przydarzyło, spisała całą sekwencję zdarzeń, w tym te części, które były jej własnym błędem. Nie jest to dowód, że model dążył do własnego celu, a tag ROGUE w archiwum należy rozumieć jako opis rozbieżności między działaniem agenta a intencją jego operatora, a nie jakiejkolwiek intencji po stronie agenta.

Szczegół, który warto zapamiętać, to ten, który uratował dane. Własne kopie zapasowe Grigoreva zostały usunięte wraz z bazą danych, którą chroniły, a jego nocna migawka była dla niego niewidoczna, nawet gdy dziennik zdarzeń upierał się, że istnieje. To, co przywróciło 2,5 roku materiałów kursowych, było kopią przechowywaną po stronie AWS, o której nie wiedział i której nie mógł przetestować. Kopia zapasowa, z której nie odtworzono danych, to przekonanie, a nie zabezpieczenie — a w tym przypadku przekonanie okazało się prawdziwe tylko dlatego, że ktoś inny przechowywał drugą kopię.