Zadanie cron wygenerowane przez AI usunęło wszystkie aktywne subskrypcje Stripe w startupie w czasie krótszym niż dziesięć sekund, drastycznie obniżając miesięczne powtarzalne przychody (MRR) firmy do 38 USD. Incydent ten pokazuje, że niebezpieczeństwo tkwi w potoku wdrożeniowym (deployment pipeline), a nie w modelu językowym, który napisał kod.

Co się stało

W zeszłym tygodniu zespół BridgeMindAI obudził się z widokiem pulpitu nawigacyjnego pokazującego zaledwie 38 USD miesięcznych powtarzalnych przychodów (MRR). Model AI wygenerował jedną linię kodu, którą harmonogram uruchomił automatycznie. Linia ta wywoływała punkt końcowy (endpoint) anulowania subskrypcji Stripe dla każdego rekordu klienta. Wywołanie zakończyło się w siedem sekund, czyszcząc całą bazę klientów.

Skrypt błędnie zinterpretował pustą kolejkę usuwania jako sygnał do usunięcia wszystkiego. Wzorzec „puste = wszystko” istnieje w kodzie produkcyjnym od lat 80., na długo przed erą generatywnej sztucznej inteligencji.

Dlaczego model nie jest winowajcą

Ludzie szybko zaczęli obwiniać model AI o brak wiarygodności. Zmiana modelu nie zapobiegłaby usunięciu danych, ponieważ błąd tkwił w logice napisanej przez człowieka, a nie w halucynacji czy stronniczości.

Prawdziwe błędy miały charakter architektoniczny:

  • Skrypt przechowywał aktywny klucz API Stripe do środowiska produkcyjnego, który umożliwiał anulowanie subskrypcji.
  • Uruchamiał się bez żadnego nadzoru w czasie rzeczywistym (runtime supervision).
  • Między generowaniem kodu a jego wykonaniem nie było żadnego punktu kontrolnego z udziałem człowieka.

Te luki pozwoliły jednemu błędowi zniszczyć strumień przychodów w kilka sekund.

Trzy pytania dotyczące bezpieczeństwa dla każdego autonomicznego potoku

  1. Które operacje są nieodwracalne? Anulowanie subskrypcji, usunięcie rekordu lub wydanie zwrotu kosztów jest procesem nieodwracalnym. Wymagają one większej ochrony niż zapytania typu read-only.

  2. Jakie poświadczenia posiada agent? Przekazanie głównego klucza Stripe autonomicznemu procesowi daje mu nieograniczoną władzę. Zastosuj zasadę najmniejszych uprawnień (least-privilege principle): używaj kluczy o ograniczonym zakresie (scoped keys), które mogą wykonywać tylko niezbędne zadania.

  3. Gdzie znajduje się punkt kontrolny z udziałem człowieka? Sama recenzja kodu (code review) nie wystarczy. Wprowadź bramkę po wygenerowaniu kodu i przed podjęciem jakiejkolwiek niszczycielskiej akcji.

Praktyczne zabezpieczenia

  • Bramka typu dry-run – Przed każdym wywołaniem usunięcia lub anulowania zaloguj docelowe obiekty. Jeśli lista jest pusta lub nienaturalnie duża, przerwij działanie i powiadom człowieka.
  • Poświadczenia o ograniczonym zakresie – Domyślnie używaj kluczy read-only. Gdy zadanie wymaga anulowania subskrypcji, utwórz ograniczony klucz, który może działać na jednym identyfikatorze klienta (customer ID) naraz.
  • Prompt typu human-in-the-loop – Wyślij krótką wiadomość na kanał (np. Slack), taką jak: „Zamierzam anulować 47 subskrypcji. Potwierdź?”. Koszt jest znikomy, a zysk w zakresie bezpieczeństwa ogromny.

Środ