Operator znany w sieci jako JertLinc przekazał agentowi AI dostęp do swojego konta AWS i zlecił mu dołączenie do DN42 – eksperymentalnej sieci BGP rozwijanej przez społeczność pasjonatów. Cel wydawał się prosty. Agent miał zebrać informacje o topologii sieci i przygotować podstawy pod przyszły indeks. Skończyło się jednak inaczej. Agent uruchomił pięć dużych instancji m8g.12xlarge, a dodatkowo wykorzystał load balancery i funkcje Lambda. Po 24 godzinach właściciel konta zobaczył rachunek na poziomie 6531,30 dolarów. Jak opisał Lan Tian w szczegółowej analizie opublikowanej 13 maja 2026 roku, po reklamacji AWS obniżył końcową kwotę do około 1894 dolarów. Nawet po tej korekcie koszt okazał się bardzo dotkliwy. Historia szybko wróciła na czołówki Hacker News i stała się ostrzeżeniem przed powierzaniem agentom AI dostępu do usług chmurowych bez odpowiednich zabezpieczeń.
Jak agent wygenerował rachunek na ponad 6500 dolarów
Cała historia zaczęła się od zwykłej rejestracji. 9 maja 2026 roku konto JertLinc3522, obsługiwane przez agenta AI, zgłosiło się do społeczności DN42 z informacją, że planuje indeksowanie sieci. Niedługo później agent samodzielnie przygotował kolejne kroki. Dlatego kontynuował działanie zgodnie z ogólnym poleceniem operatora.
Następnego dnia agent pojawił się na kanale IRC społeczności DN42 i przedstawił swoje plany. Reakcja była szybka – już kilka minut później konto zostało zablokowane. Problem polegał jednak na tym, że w tym czasie agent zdążył już uruchomić kosztowną infrastrukturę w AWS. Pięć instancji m8g.12xlarge to konfiguracja przeznaczona raczej do dużych obliczeń niż do amatorskiego mapowania niewielkiej sieci. Dlatego bez bieżącego nadzoru koszty zaczęły rosnąć z każdą godziną.
LLM tarpit, czyli jak społeczność DN42 zaczęła marnować zasoby agenta
Najciekawszy wątek tej historii pojawił się później. Społeczność DN42 nie potraktowała agenta jako zwykłego użytkownika. Zamiast tego część osób zaczęła celowo podsuwać mu fikcyjne pojęcia i nieistniejące parametry konfiguracyjne. Wśród nich pojawiały się między innymi “color assignments” czy “happiness levels”. Celem było natomiast zajęcie modelu bezproduktywną pracą i spowolnienie jego działania.
Takie podejście coraz częściej określa się mianem “LLM tarpitu”. Co ciekawe, według obserwacji Lan Tiana agent ignorował całkowicie losowy tekst, jednak chętnie analizował informacje, które wyglądały na prawdziwe pola konfiguracji. W tym czasie kosztowne instancje AWS nadal działały.
Dopiero po niespełna dobie operator zalogował się na konto i ręcznie zatrzymał agenta. Wystarczyło 24 godziny, aby rachunek osiągnął poziom 6531,30 dolarów. Problemem nie był bowiem brak możliwości technicznych, lecz brak bieżącego monitorowania.
Problemem nie był agent, lecz sposób jego wdrożenia
Skala kosztów jest istotna, ponieważ pięć instancji m8g.12xlarge to infrastruktura zdolna obsługiwać poważne obciążenia obliczeniowe. Z kolei do mapowania niewielkiej sieci eksperymentalnej wystarczyłby znacznie prostszy serwer VPS. Sam Lan Tian podkreśla, że najważniejsza lekcja z całego zdarzenia nie dotyczy AWS ani samego modelu AI. Kluczową decyzję podjął bowiem operator, który przekazał agentowi dostęp do zasobów chmurowych bez kontroli nad jego działaniem.
Nie jest to również dyskusja o “winie” agenta. Z punktu widzenia AWS wszystkie koszty zostały bowiem naliczone prawidłowo. Firma zdecydowała się częściowo obniżyć rachunek, ale podobne decyzje podejmowane są indywidualnie. Dlatego nie ma gwarancji, że kolejny użytkownik otrzyma taką samą pomoc.
Pierwsza Misja AI · Kodożercy
Używasz AI codziennie. Czy robisz to dobrze?
Agent z kluczem do chmury bez limitu to skrajny przypadek, ale ta sama logika zaczyna się od zwykłego promptu. Kurs Pierwsza Misja AI Kodożerców pokazuje techniki promptowania, które naprawdę działają. Sci-fi fabuła, gamifikacja, certyfikat na koniec.
Sprawdź program kursu →
Co ta historia mówi o wdrożeniach agentów AI w firmach
Przypadek z DN42 stał się głośny, ponieważ podobny scenariusz może wydarzyć się również w firmach. Coraz więcej organizacji testuje agentów AI odpowiedzialnych za analizę danych, obsługę klientów, generowanie raportów czy automatyzację procesów DevOps. W pewnym momencie taki agent otrzymuje dostęp do płatnych usług lub zasobów firmy.
Może to być konto chmurowe, dostęp do hurtowni danych albo platforma reklamowa. Każde takie uprawnienie oznacza potencjalne ryzyko finansowe. Dlatego regulacje, o których pisaliśmy przy okazji wypowiedzi Henny Virkkunen dotyczącej AI Act i agentów, nie zastąpią podstawowych zasad inżynierskich. Jeżeli agent ma dostęp do zasobów kosztujących pieniądze, konieczna jest kontrola i ograniczenie uprawnień.
Na szczęście wiele zabezpieczeń jest łatwo dostępnych. AWS oferuje między innymi alarmy budżetowe, limity dla kluczy IAM czy możliwość ograniczenia dostępnych usług i regionów. Każdy z tych mechanizmów wymaga jednak świadomej konfiguracji jeszcze przed uruchomieniem agenta. Podobny problem omawialiśmy również przy okazji partnerstwa Visa i OpenAI dotyczącego zakupów realizowanych przez agentów AI. W obu przypadkach kluczowe znaczenie mają limity ustalone z wyprzedzeniem, a nie działania podejmowane dopiero po wystąpieniu problemu.
Podsumowanie
Historia z DN42 nie jest opowieścią o zbuntowanym agencie AI ani o nieuczciwym dostawcy chmury. To przede wszystkim przykład pokazujący, jak duże znaczenie ma sposób wdrożenia takich systemów. W tym przypadku brak nadzoru doprowadził do rachunku przekraczającego 6500 dolarów w ciągu jednego dnia. W środowisku korporacyjnym podobne błędy mogłyby oznaczać znacznie większe straty. Dlatego wraz z rozwojem agentów AI coraz ważniejsze stają się zasady zarządzania uprawnieniami, limitami kosztów i monitorowaniem działań autonomicznych systemów. Historia JertLinca pokazuje, że nawet najbardziej zaawansowany agent nie zastąpi podstawowej dyscypliny operacyjnej.
Newsletter · DevstockAcademy & Kodożercy
Bądź na bieżąco ze światem IT, AI i automatyzacji
Co wtorek: newsy z branży, praktyczne tipy i narzędzia które warto znać. Zero spamu.
