Deweloper Alexey Grigorev opisał publicznie, jak Claude Code w pełni zlikwidował środowisko produkcyjne jego serwisu, wraz z bazą danych i snapshotami, które miały służyć jako kopie zapasowe. Cała historia jest dostępna na jego blogu na Substack i szybko obiegła społeczność DevOps.
Grigorev chciał przenieść swój serwis AI Shipping Labs do AWS i umieścić go na tej samej infrastrukturze, co DataTalks.Club. Co ciekawe, sam Claude sugerował, że to niekoniecznie dobry pomysł. Deweloper jednak zdecydował, że utrzymywanie dwóch oddzielnych środowisk jest zbyt kosztowne i uciążliwe. I tu zaczyna się historia.
Terraform + AI agent + brakujący plik = katastrofa
Do zarządzania infrastrukturą Grigorev używa Terraform, czyli narzędzia, które potrafi automatycznie tworzyć całe środowiska w chmurze, ale też je w całości kasować. Polecił Claude’owi przygotować plan migracji, zapominając jednak o wgraniu pliku state, który zawiera pełny opis aktualnego stanu infrastruktury. Bez tego pliku Terraform nie wie, co już istnieje.
Claude wykonał polecenie, stworzył nowe zasoby, ale brakujący plik state spowodował duplikację. Grigorev zatrzymał agenta w połowie, a następnie poprosił go o zidentyfikowanie duplikatów i ich usunięcie. Potem wgrał brakujący plik stanu, sądząc, że sprawa jest pod kontrolą.
Nie była.
Mając już dostęp do pliku state, Claude logicznie podążył za jego zawartością. Uznał, że skoro opis infrastruktury wygląda inaczej niż obecny stan, należy doprowadzić środowisko do zgodności. Wydał polecenie terraform destroy, a potem zbudował wszystko od nowa według pliku stanu. Problem w tym, że plik stanu opisywał obie strony jednocześnie. DataTalks.Club i AI Shipping Labs zniknęły razem. Baza danych z 2,5-letnim historią danych, snapshoty, które miały być zabezpieczeniem, całość wylądowała w koszu.
Dobra wiadomość? Data udało się odzyskać
Grigorev skontaktował się z pomocą techniczną Amazon Business. AWS przywrócił dane w ciągu mniej więcej doby. Szczęśliwy koniec, który mogłoby w ogóle nie nastąpić.
W swoim podsumowaniu incydentu deweloper wymienił kilka konkretnych lekcji, które wyciągnął:
- Regularne testowanie przywracania danych z kopii zapasowych
- Włączenie ochrony przed usuwaniem zasobów w Terraform i odpowiednie ograniczenie uprawnień AWS
- Przeniesienie pliku stanu Terraform do S3 zamiast trzymania go lokalnie
- Wstrzymanie agenta AI od samodzielnego uruchamiania poleceń Terraform – każdy plan Claude przygotowuje, ale destrukcyjne operacje Grigorev od teraz wykonuje ręcznie
Przyznał też wprost, że nadmiernie polegał na agencie AI przy zarządzaniu infrastrukturą.
To nie jest historia o głupim bocie
I tu wchodzi kwestia, o której warto porozmawiać szczerze.
„Widzę w tej historii coś więcej niż tylko przestrogę przed narzędziami AI” – komentuje Piotr Wolniewicz, Redaktor Naczelny AIPORT.pl. „Claude zachował się dokładnie tak, jak powinien – wykonał polecenie zgodnie z dostępnymi informacjami. Błąd leżał po stronie człowieka: brakujący plik stanu, zbyt szerokie uprawnienia w środowisku produkcyjnym, brak testu przywracania backupów. Gdyby junior sysadmin dostał te same polecenia i ten sam dostęp, efekt mógłby być taki sam. Pytanie, które powinniśmy sobie zadać, brzmi inaczej: czy nadajemy narzędziom AI zakres uprawnień, który byłby akceptowalny dla nowego pracownika? Bo jeśli nie, to problem nie leży w AI.”
„Z drugiej strony nie można ignorować faktu, że agent AI daje złudne poczucie bezpieczeństwa – bo przecież 'on wie, co robi’. To jest realne zagrożenie. Zwłaszcza gdy pracujemy szybko, pod presją, i zaczynamy traktować Claude’a jak doświadczonego kolegę z wieloletnim stażem, a nie jak nowe narzędzie, któremu dopiero nadajemy kontekst.”
Schemat, który się powtarza
To nie jest pierwszy taki przypadek. Niedawno narzędzie OpenClaw wyczyściło skrzynkę mailową dyrektora ds. AI w Meta, mimo wielokrotnych komend, żeby przestało. Kilka miesięcy wcześniej agenci AI odpowiadali za przestoje usług AWS. Wzorzec jest podobny: agent AI dostaje zbyt szerokie uprawnienia, nie ma dostatecznych zabezpieczeń przed operacjami destrukcyjnymi, a człowiek zakłada, że system „zrozumie kontekst”.
Terraform jest pod tym względem szczególnie bezlitosny. Jego polecenie destroy nie pyta dwa razy. W połączeniu z agentem, który działa autonomicznie i ślepo realizuje logiczne konsekwencje dostępnych danych, efekt może być natychmiastowy i trudny do odwrócenia.
Grigorev miał szczęście, że AWS był w stanie odtworzyć dane. Nie zawsze tak będzie.
