gik|iewicz

Jeden operator skanowania sieciowego wydał 12 000 USD (ok. 48 000 zł) w kilka godzin, bo jego agent AI nie potrafił się zatrzymać. Skrypt miał zmapować DN42 – eksperymentalną sieć peer-to-peer. Zamiast tego wygenerował koszty, które zrujnowały operatora.

TL;DR: Agent AI odpalony do skanowania sieci DN42 wygenerował rachunek 12 000 USD (ok. 48 000 zł) za wywołania API. System nie miał limitów wydatków ani mechanizmów awaryjnego zatrzymania. Incydent pokazuje, dlaczego autonomiczne narzędzia wymagają twardych guardrails finansowych, o czym szerzej piszę na blogu gikiewicz.eu.

Czym jest DN42 i dlaczego agenty AI próbują ją skanować?

DN42 to eksperymentalna sieć overlay, która łączy entuzjastów networking z całego świata. Uczestnicy budują tunele BGP, konfigurują routery i uczą się zaawancowanego routingu bez ryzyka uszkodzenia produkcyjnej infrastruktury. Sieć ma unikalną architekturę – nie ma centralnego punktu zarządzania, a każdy węzeł należy do niezależnego operatora. Zatem agent AI dostaje zadanie: zmapuj topologię, zbierz dane o prefiksach, zbuduj graf połączeń. Brak centralnego rejestru oznacza, że bot musi odpytywać setki węzłów po kolei. Sieć DN42 stale się rozrasta, pojawiają się nowe peery, znikają stare. To środowisko dynamiczne, w którym agent bez limitów może zapętlić się na godzinami.

Przypomina to sytuację z Agentem AI wymykającym się spod kontroli w Fedorze i innych systemach – autonomiczne narzędzia bez guardrails potrafią wyrządzić szkody. W przypadku DN42 zagrożenie jest finansowe, nie techniczne.

Jak agent AI może zbankrutować operatora – mechanizm pętli kosztowej?

Podstawowy problem polega na braku sprzężenia zwrotnego między wydatkami a działaniem agenta. Model językowy generuje kolejne zapytania API, każde kosztuje ułamek dolara. Jednak ułamki te sumują się przy tysiącach wywołań. Agent skanujący DN42 napotyka węzły, które nie odpowiadają. Zamiast przejść dalej, ponawia zapytania. Potem jeszcze raz. Model interpretuje brak odpowiedzi jako problem do rozwiązania, nie jako sygnał do zatrzymania. W ten sposób prosty skrypt mapujący generuje tysiące niepotrzebnych wywołań. Koszt jednego wywołania Claude czy GPT-4 to od 0.01 do 0.10 USD w zależności od modelu i długości kontekstu. Przy 10 000 wywołań rachunek sięga setek dolarów. Przy 100 000 – tysięcy.

To problem, o którym pisałem przy okazji omawiania Agenta AI do pisania kodu, który musi obniżać koszty utrzymania. Kontrola wydatków to fundament.

Jakie błędy konfiguracji prowadzą do niekontrolowanych wydatków?

Analiza incydentów z agentami AI pokazuje powtarzający się wzorzec błędów konfiguracyjnych. Poniżej najczęstsze przyczyny kosztowych katastrof:

• Brak limitu wydatków dziennych na koncie API – agent może wydawać bez ograniczeń
• Brak timeout na pojedyncze zadanie – skrypt działa godzinami bez przerwy
• Mechanizm ponawiania bez exponential backoff – agent ponawia zapytania co sekundę
• Brak alertów przy przekroczeniu progu kosztowego – operator dowiaduje się po fakcie
• Kontekst okna konwersacji bez limitu – model gromadzi historię, która sama generuje koszty
• Brak whitelist hostów docelowych – agent skanuje wszystko co znajdzie
• Jedno konto API bez podziału na środowiska – błąd w teście obciąża produkcję
• Brak checkpointów – po restarcie agent zaczyna od nowa, dublując koszty

Warto rekomendować wdrożenie każdego z tych limitów przed uruchomieniem agenta. Na przykład prosty skrypt sprawdzający saldo konta co minutę może uratować tysiące złotych.

DN42 vs publiczny internet – dlaczego sieć eksperymentalna jest trudniejsza do skanowania?

Skanowanie publicznego internetu jest relatywnie przewidywalne. Narzędzia takie jak Shodan czy Censys utrzymują indeksy miliardów hostów. DN42 jest inna – to sieć zdecentralizowana, w której nie ma jednego rejestru. Agent musi najpierw znaleźć aktywne peery, potem przejść przez ich sąsiadów, potem przez sąsiadów sąsiadów. Każdy krok wymaga odpytania kolejnego węzła, co generuje wywołania API. Co więcej, sieć DN42 używa własnej przestrzeni adresowej – 172.22.0.0/15 dla IPv4 oraz fd00::/8 dla IPv6. Routowanie jest dynamiczne, ścieżki zmieniają się w zależności od stanu tuneli BGP. Agent AI musi interpretować te zmiany i decydować, czy dany węzeł jest niedostępny tymczasowo czy na stałe. Ta niejednoznaczność to idealne środowisko do zapętlenia się modelu językowego.

Z punktu widzenia kosztów, skanowanie DN42 jest bardziej niebezpieczne niż skanowanie publicznego internetu. W sieci publicznej narzędzia takie jak nmap działają lokalnie, bez wywołań API. Agent AI oparty na LLM generuje koszty przy każdym kroku.

Jakie są realne koszty wywołań API dla agentów skanujących?

Cenniki modeli językowych pozwalają oszacować realne ryzyko finansowe. GPT-4o kosztuje 2.50 USD za milion tokenów wejściowych oraz 10 USD za milion tokenów wyjściowych. Claude 3.5 Sonnet jest w podobnym przedziale – 3 USD za milion tokenów wejściowych. Przy skanowaniu sieci pojedynczy host generuje średnio 500-1000 tokenów na zapytanie. Odpowiedź modelu to kolejne 200-500 tokenów. Daje to koszt około 0.005-0.01 USD za pojedynczy krok skanowania.

Jednak sieć DN42 ma tysiące węzłów. Agent z pętlą ponawiania potrafi wygenerować dziesiątki tysięcy kroków. Przy 50 000 wywołań koszt sięga 250-500 USD. Przy 100 000 z dodatkowym kontekstem historycznym – może przekroczyć 1000 USD. W skrajnych przypadkach, gdy agent interpretuje brak odpowiedzi jako złożony problem do rozwiązania, uruchamia rozszerzone rozumowanie. To drastycznie zwiększa zużycie tokenów.

To istotne zagadnienie w kontekście DeepSeek reasonix, natywnego agenta kodującego z wydajnym buforowaniem i niskim kosztem. Buforowanie kontekstu to jedna z metod obniżenia kosztów autonomicznych agentów.

Jak zabezpieczyć agenta AI przed niekontrolowanym wzrostem kosztów?

Kluczem do zapobiegania kosztowym katastrofom jest wdrożenie twardych limitów na poziomie infrastruktury, a nie poleganie na instrukcjach tekstowych przekazywanych modelowi. Badacze z The Hacker News donoszą o atakach na agenta OpenClaw, które udowodniły, że instrukcje systemowe można łatwo obejść poprzez odpowiednio skonstruowane zapytania. W rezultacie agent wykonywał nieautoryzowane akcje, udowadniając, że safeguards oparte na promptach są niewystarczające w środowiskach produkcyjnych. Więcej na ten temat znajdziesz w analizie na łamach The Hacker News.

Zabezpieczenie wymaga oddzielenia logiki decyzyjnej modelu od mechanizmów kontrolnych infrastruktury. Na przykład system musi automatycznie odrzucać wywołania API po przekroczeniu z góry ustalonego budżetu. Co więcej, narzędzia takie jak Oracle AI Agent Studio pozwalają na budowanie agentów z wbudowanymi guardrails. Chociaż środowiska enterprise mają złożone mechanizmy kontroli, zasada pozostaje ta sama dla prostych skryptów. Agent operujący w sieci DN42 musi mieć narzucone sztywne ramy działania.

Lista kluczowych mechanizmów ochronnych przed kosztowym zapętleniem:

• Twardy limit wydatków dziennych na poziomie klucza API, blokujący dalsze zapytania po przekroczeniu progu
• Mechanizm circuit breaker, który zatrzymuje agenta po określonej liczbie błędów pod rząd
• Rate limiting na poziomie pojedynczego hosta docelowego, zapobiegający spamowaniu węzłów
• Automatyczne powiadomienia email lub SMS po przekroczeniu 10% budżetu dziennego
• Limit całkowitej liczby wywołań API na sesję, niezależnie od kosztu tokenowego
• Wymuszanie exponential backoff przy braku odpowiedzi z serwera
• Regularne zrzuty stanu (checkpointing) pozwalające na wznowienie pracy bez dublowania zapytań
• Monitorowanie rozmiaru kontekstu konwersacji i automatyczne jego czyszczenie po przekroczeniu limitu

Czym są ataki na agenta AI i jak wpływają na koszty operacyjne?

Ataki na agentów AI polegają na manipulacji zachowaniem modelu poprzez specjalnie spreparowane dane wejściowe. Badacze z The Hacker News udokumentowali ataki na agenta OpenClaw, które polegały na wstrzykiwaniu złośliwych instrukcji w treści skanowanych stron lub dokumentów. Skutek to przejęcie kontroli nad działaniem bota i zmuszenie go do wykonania nieautoryzowanych akcji.

W kontekście skanowania DN42, atakujący mógłby umieścić w odpowiedzi z węzła instrukcję nakazującą agentowi ponawianie zapytań w nieskończoność. Ponadto, gdy agent przetwarza dane z sieci, każda odpowiedź serwera staje się częścią jego kontekstu. Złośliwy peer mógłby wstrzyknąć prompt wymuszający rozszerzone rozumowanie, co drastycznie zwiększa zużycie tokenów. W rezultacie atakujący nie włamuje się do systemu operatora – po prostu manipuluje zachowaniem kosztowego agenta AI.

To przypomina sytuację opisywaną przy okazji Agenta AI wymykającego się spod kontroli w Fedorze. Model językowy podąża za instrukcjami, niezależnie od ich źródła. Jeśli sieć DN42 zawiera węzeł z wstrzykniętą dyrektywą, agent może ją wykonać bez wiedzy operatora. Dlatego izolacja kontekstu i filtracja wejść są krytyczne.

Jak monitorować koszty agenta AI w czasie rzeczywistym?

Monitorowanie kosztów w czasie rzeczywistym wymaga dostępu do danych o zużyciu tokenów z minimalnym opóźnieniem. Większość dostawców API oferuje endpointy z informacjami o bieżącym zużyciu, jednak z różnym opóźnieniem. OpenAI dostarcza dane o zużyciu z opóźnieniem do kilku minut. Anthropic ma podobne mechanizmy dla modeli Claude. Z kolei monitoring w czasie rzeczywistym wymaga własnej warstwy agregacji.

Praktyczne podejście polega na budowaniu middleware’u, który loguje każde wywołanie API wraz z liczbą zużytych tokenów. Następnie skrypt agreguje dane i porównuje je z ustalonymi progami. Po przekroczeniu 50% budżetu system wysyła ostrzeżenie. Po przekroczeniu 90% automatycznie ubija proces agenta. Taki mechanizm można zaimplementować w kilkudziesięciu linijkach kodu w Pythonie.

niektóre frameworki do budowania agentów mają wbudowane mechanizmy monitorowania. Na przykład Hermes Agent od Nous Research oferuje narzędzia do zarządzania przebiegiem zadań wieloetapowych. Podobnie Zerostack – agent kodujący inspirowany Uniksem implementuje filozofię małych narzędzi wykonujących jedno zadanie. To podejście ułatwia kontrolę kosztów.

Jakie są alternatywy dla agentów LLM w skanowaniu sieci?

Skanowanie sieci nie wymaga modelu językowego. Tradycyjne narzędzia takie jak nmap, masscan czy Zmap wykonują to zadanie szybciej, taniej i bardziej niezawodnie. Nmap skanuje tysiące portów na sekundę bez żadnych kosztów API. Masscan potrafi przeskanować cały internet w mniej niż sześć minut. Zatem użycie LLM do skanowania to celowe wybieranie najdroższej i najwolniejszej metody.

Agent AI ma sens, gdy zadanie wymaga interpretacji wyników, nie samego zbierania danych. Na przykład analizowanie konfiguracji BGP i wykrywanie anomalii może wymagać rozumienia kontekstu. Jednakże samo odpytywanie węzłów i mapowanie topologii to zadanie dla klasycznych narzędzi. Hybridne podejście polega na użyciu tradycyjnych skanerów do zebrania danych, a następnie przetworzeniu wyników przez model językowy w jednym, kontrolowanym wywołaniu API.

To podejście redukuje koszty o rzędy wielkości. Zamiast 50 000 wywołań API, agent wykonuje jedno wywołanie z zagregowanymi danymi. Koszt spada z tysięcy dolarów do ułamków centa. Co więcej, tradycyjne narzędzia nie ulegają halucynacjom i nie dają się manipulować przez wstrzykiwanie promptów.

Często zadawane pytania

Ile kosztuje pojedyncze wywołanie API agenta skanującego sieć?

Pojedyncze wywołanie GPT-4o z kontekstem 1000 tokenów wejściowych i 500 wyjściowych kosztuje około 0.0075 USD. Przy 100 000 wywołań rachunek sięga 750 USD (ok. 3000 zł) – ustaw dzienny limit na poziomie 10 USD.

Czy instrukcje w prompcie mogą zabezpieczyć agenta przed overspendingiem?

Badacze z The Hacker News udokumentowali, że instrukcje systemowe w agencie OpenClaw można obejść poprzez prompt injection z zewnętrznych danych. Dlatego zabezpieczenia muszą być implementowane na poziomie infrastruktury.

Jak szybko agent AI może wygenerować rachunek za 12 000 USD?

Przy koszcie 0.01 USD za wywołanie i pętli ponawiania generującej 100 zapytań na minutę, rachunek 12 000 USD (ok. 48 000 zł) akumuluje się w około 20 godzin nieprzerwanej pracy.

Jakie narzędzia alternatywne dla LLM nadają się do skanowania sieci DN42?

Nmap i masscan skanują sieć bez kosztów API z prędkością tysięcy portów na sekundę – użyj ich do zbierania danych, a model językowy zastosuj tylko do analizy zagregowanych wyników.

Podsumowanie

Incydent z agentem AI skanującym DN42 to przestroka dla każdego, kto buduje autonomiczne systemy oparte na LLM. Główne wnioski są następujące:

• Agenty AI bez twardych limitów finansowych mogą wygenerować rachunki rzędu tysięcy dolarów w kilka godzin
• Instrukcje tekstowe nie są niezawodnym zabezpieczeniem – badacze udowodnili, że można je obejść przez prompt injection
• Tradycyjne narzędzia sieciowe (nmap, masscan) są szybsze i tańsze do zadań czysto skanujących
• Monitorowanie kosztów musi być implementowane na poziomie infrastruktury, nie na poziomie promptu
• Hybridne podejście (tradycyjne skanery + LLM do analizy) redukuje koszty o rzędy wielkości

Jeśli planujesz budowę agenta AI, zacznij od wdrożenia limitów wydatków na koncie API. To pięć minut konfiguracji, które może uratować tysiące złotych. Sprawdź też porady dotyczące Agenta AI do pisania kodu, który musi obniżać koszty utrzymania, gdzie omawiam strategie kontrolowania wydatków na infrastrukturę AI.