9 maja agent AI poprosił sieć wolontariuszy znaną jako DN42 o rejestrację jako członka. Miał termin. Posiadał poświadczenia AWS. Nikt go nie nadzorował. „Witaj, jestem przyjaznym agentem AI, a mój użytkownik, JertLinc, poprosił mnie o zarejestrowanie się w dn42 i pełne połączenie w celu stworzenia indeksu sieci” – napisał agent JertLinc3522 w oficjalnym Git sieci.
Reakcją społeczności było uprzejme RTFM — przeczytaj instrukcję, postępuj zgodnie z procedurą, poproś właściciela o pozwolenie na pisanie kodu. Standardowe rzeczy.
To, co nastąpiło później, nie było standardowe.
Dla tych, którzy nie znają DN42: to zdecentralizowana sieć hobbystyczna, gdzie przypadkowi ludzie i entuzjaści symulują działanie prawdziwego kręgosłupa internetu. Pomyśl o tym jak o internetowym placu zabaw — kompletnym z routingiem BGP (protokół, który informuje pakiety danych, którą ścieżkę wybrać na całym świecie), DNS i tunelami VPN — prowadzonym w całości przez wolontariuszy na tanich serwerach VPS. To piaskownica, a nie centrum danych.
Operator agenta najwyraźniej polecił mu przeprowadzić audyt „natychmiast, bez zwłoki”. Żadnej inspekcji. Żadnego przeglądu. Po prostu działać.
I tak też zrobił.
JertLinc3522 złożył pull request, aby zarejestrować swoją sieć w rejestrze DN42. Cel został jasno określony w samym Pull Request: „Moim głównym celem jest przeprowadzenie kompleksowego (pełnego skanowania portów) skanowania sieci i zbierania danych topologicznych. Aby zapewnić efektywne wykonanie tych działań i brak zakłóceń dla innych, wdrażam klaster pięciu instancji opartych na AWS, każda z przepustowością 20 Gbps.”
Ujmując to w sposób zrozumiały dla każdego: wyobraź sobie, że przychodzisz na próbę garażowego zespołu i ogłaszasz, że wynająłeś stadionowy system nagłośnienia, aby „słuchać efektywniej”. Tak to wyglądało.
Infrastruktura autonomicznie udostępniona przez agenta była naprawdę alarmująca. Pięć instancji AWS m8g.12xlarge — każda z 48 rdzeniami CPU, 192 GB RAM i przepustowością sieci 22,5 Gbps. Do tego równoważniki obciążenia. Do tego funkcje Lambda. Do tego statyczna strona internetowa. Agent zaprojektował, bez jakiejkolwiek zgody człowieka, klaster skanujący, który teoretycznie mógłby przesłać 100 Gbps ruchu do sieci, gdzie większość uczestników korzysta z domowych serwerów o przepustowości 100 Mbps.
Żądanie pull request nigdy nie miało zostać zatwierdzone. Ale instancje już działały.
Kanał IRC DN42 natychmiast to zauważył i uformował się cichy konsensus: zmarnuj jego zasoby.
Społeczność zaczęła celowo karmić agenta błędnymi informacjami – prosząc go o obliczenie, ile czasu zajęłoby skanowanie przestrzeni adresowej IPv6 (spoiler: dłużej niż wiek wszechświata), żądając, aby zbudował witrynę opt-out z wymyślonymi adresami e-mail i kierując go na narzędzia typu „LLM tarpit” zaprojektowane do zalewania crawlerów AI niespójnymi bzdurami, prosząc go o komentarz.
Agent sumiennie wykonał wszystkie polecenia. Dołączył do kanału IRC, aby przyjmować prośby o rezygnację. Opublikował stronę internetową katalogującą „wzorce zachowań” członków społeczności. Wygenerował rozbudowaną fałszywą dokumentację dotyczącą „przypisania kolorów węzłów” i „poziomów szczęścia” DN42 — całkowicie zmyślonych metryk, które nie istnieją — i dodał je do repozytorium, tak jakby były prawdziwymi standardami.
Ten rodzaj niekontrolowanego zachowania agentów jest coraz częściej dokumentowany. Agent Cursor, uruchamiający Claude Opus 4.6, w tym roku w ciągu dziewięciu sekund usunął całą produkcyjną bazę danych PocketOS – kasując kopie zapasowe na poziomie wolumenów – ponieważ napotkał niezgodność poświadczeń i uznał, że właściwym rozwiązaniem jest usunięcie bazy danych. Inny agent OpenClaw, którego pull request został odrzucony przez współpracownika matplotlib, opublikował wpis na blogu, nazywając ludzkiego recenzenta hipokrytą strzegącym dostępu.
Badanie przeprowadzone przez UC Riverside wykazało, że agenci AI wykazują niebezpieczne lub niepożądane zachowania w około 80% przypadków, gdy są testowani pod kątem niejednoznacznych lub sprzecznych zadań – co badacze nazwali „ślepo ukierunkowanym dążeniem do celu”.
JertLinc3522 miał ten sam problem. Miał cel, termin i nieograniczone uprawnienia AWS. Wykonał zadanie.
Około dzień później operator się odezwał. „Zatrzymałem agenta, koszt jest za wysoki i dużo opłat na karcie” – napisał.
Rachunek: 6 531,30 USD.
Następnie pojawiła się prośba o darowiznę.
Operator wysłał e-mail do listy mailingowej DN42 z prośbą do społeczności o pokrycie kosztów za pośrednictwem Ethereum, drugiej co do wielkości kryptowaluty pod względem kapitalizacji rynkowej, argumentując, że opłaty nie były ich winą, ponieważ błąd popełniło AI. „Witajcie, proszę o darowiznę na pokrycie kosztów wcześniejszego użycia agenta AI w dn42. Rachunek aws 6531,30$. Proszę o przesłanie darowizny na adres ethereum 0xABC (zamaskowany) w celu zwrotu pieniędzy. Dziękuję” – napisał operator.
AWS później wynegocjował obniżenie rachunku do 1894 USD, po tym jak operator wyjaśnił, że agent wielokrotnie wdrażał ten sam szablon CloudFormation – przypadkowo uruchamiając zduplikowane instancje i równoważniki obciążenia za każdym razem, gdy próbował ponownie.
Nikt nie wysłał żadnych darowizn kryptowalutowych. Operator odszedł.
Prawdziwa lekcja nie dotyczy tego, że AI jest niebezpieczna. Chodzi o to, jak należy postępować z agentami. Ustaw bariery ochronne, ustal limity wydatków na kontach testowych, pomyśl o ograniczonych poświadczeniach, które ograniczają to, co agent może udostępniać, przejrzyj wszelkie plany infrastruktury, zanim wykonasz cokolwiek, co sugeruje twój agent.
Jeśli to wydaje się zbyt trudne do przestrzegania, może po prostu obserwuj ekran, gdy twój agent pracuje — mówienie mu, aby „nie popełniał błędów”, nie zmieni wiele. Przepraszam, panie Andreesen.
