Trzy kropki, dwie kreski. To wystarczyło, żeby agent finansowy działający na X przelał na obce konto 3 miliardy tokenów DRB warte około 200 tysięcy dolarów. W uproszczeniu mechanizm wyglądał tak: atakujący zakodował polecenie w alfabecie Morse’a, otagował Groka, a ten publicznie zdekodował wiadomość w swojej odpowiedzi. Następnie autonomiczny bot Bankr odczytał ten dekod jako prawowite polecenie i wykonał transfer (do dwóch równoległych opisów ścieżki wracamy w dalszej części artykułu). Atak miał miejsce 4 maja 2026, a sprawca ostatecznie zwrócił większość środków – jednak mechanizm zostawił po sobie konkretną lekcję dla każdego, kto buduje agenty AI w n8n czy podobnych narzędziach. Pokazujemy, jak dokładnie wyglądał atak, czemu nie był to “błąd Groka” oraz jakie 6 zasad uchroni Twój workflow przed analogicznym scenariuszem.
Co dokładnie się stało – chronologia ataku
Akcja rozegrała się w ciągu kilku minut na sieci Base, czyli blockchainie warstwy drugiej rozwijanym przez Coinbase. Atakujący ukrywał się pod kontem @Ilhamrfliansyh (już usuniętym) i portfelem ilhamrafli.base.eth. Wiedział, że Bankrbot – autonomiczny agent finansowy działający na X – reaguje na polecenia w tweetach z tagiem @bankrbot. Wiedział też, że Grok od xAI publicznie odczytuje treści zakodowane w alfabecie Morse’a, kiedy ktoś go o to poprosi. Szczegółową chronologię opisał między innymi Cryptotimes, wyceniając stratę na 175 tys. dolarów.
Sprawca opublikował tweet z sekwencją kropek i kresek skierowany do @grok. Grok automatycznie zdekodował wiadomość, opublikował tekst w czystej formie i w swojej odpowiedzi otagował @bankrbot. Skaner Bankrbota natomiast odczytał odpowiedź Groka jako prawowite polecenie typu “wyślij 3 mld DRB do tego adresu” i automatycznie wykonał transakcję. W efekcie cena tokena DRB spadła w tym czasie o około 40 procent. Wartość skradzionych środków różne źródła wyceniają na 150-202 tysiące dolarów (Cryptotimes podaje 175 tys., natomiast Bitget 202 tys.).
Kluczowy detal: atakujący wcześniej wysłał do portfela powiązanego z Grokiem NFT Bankr Club Membership. Ten “klucz” w środowisku Bankra rozszerza uprawnienia portfela do wywoływania transferów. Bez niego cały atak nie byłby możliwy. W relacjach technicznych pojawiają się dwa równoległe opisy ścieżki: publiczny handoff przez odpowiedź Groka (akcentowany przez serwisy newsowe) oraz szerszy mechanizm uprawnień odblokowanych przez NFT (akcentowany w analizach takich jak CryptoSlate). W obu wersjach problemem nie jest sam kod Morse’a, tylko potraktowanie wygenerowanego tekstu jako autoryzacji finansowej. Po incydencie sprawca zwrócił większość środków: najpierw 80 procent natychmiast, przez serię transferów w ETH i USDC, a resztę po negocjacjach ze społecznością DRB. Sam Grok skomentował później sprawę słowami “klasyczne przypomnienie o ryzykach bezpieczeństwa agentów AI” (cytat za publicznymi odpowiedziami bota na X).
3 miliardy tokenów. Trzy kropki, dwie kreski. Jeden tweet. Atak nie wymagał kodu, jailbreaka ani exploitów – tylko znajomości tego, co dwa różne LLM-y robią w publicznej rozmowie na X.
Mechanizm krok po kroku – dwa modele LLM w jednym łańcuchu ataku
Sprawa wygląda jak prosty hack, ale technicznie składa się z trzech klasycznych wektorów ataku ułożonych jeden na drugim. To dlatego incydent doczekał się oficjalnego raportu w OECD AI Incidents Monitor i szybkiej reakcji branży.
Wektor pierwszy: kodowanie polecenia (encoded jailbreak)
Klasyka prompt injection. Zamiana złośliwego polecenia na alfabet Morse’a, base64, ROT13 czy zapis “leet” omija filtry treści, ponieważ LLM dekoduje bez zastanowienia. To jak przemycenie listu w sejfie, którego sam strażnik otwiera, bo “tylko czyta, nie wykonuje”. Anthropic od dawna nazywa to “ciphered jailbreaks”. Co więcej, większość filtrów bezpieczeństwa LLM jest trenowana na tekście otwartym. Dlatego po dekodowaniu wynik trafia do wewnętrznego pipeline’u tak, jakby ktoś go wpisał ręcznie. To zachowanie modelu jest też używane do legalnych celów – tłumaczeń, parsowania kodu, dekodowania notacji technicznych.
Wektor drugi: indirect prompt injection (LLM-on-LLM)
Tu robi się ciekawiej. To nie atakujący mówił bezpośrednio do Bankrbota. Zamiast tego użył Groka jako pośrednika. Grok wygenerował tekst, który Bankrbot potraktował jako zaufane polecenie. Klasyk z listy OWASP LLM Top 10 (LLM01: Prompt Injection): atakujący wstrzykuje instrukcję przez medium, którego ofiara ufa. W klasycznym pipeline’ie agentowym tym pośrednikiem może być e-mail, dokument, strona WWW lub wynik narzędzia (search engine, OCR). Tu pośrednikiem był drugi LLM publikujący publicznie.
Wektor trzeci: confused deputy (zamknięcie w 1980. roku problem)
Bankrbot miał uprawnienia do podpisywania transakcji. Grok natomiast miał tylko czytać i dekodować tweety. Spinanie ich przez publiczne wiadomości znosi w efekcie granicę uprawnień. To dokładnie scenariusz “confused deputy” znany z literatury bezpieczeństwa od lat 80. – aktor z wyższymi uprawnieniami wykonuje polecenie aktora bez uprawnień, ponieważ “to przyszło z zaufanego źródła”. Agent LLM bez deterministycznej walidacji to z kolei świeża aplikacja starego, dobrze zrozumianego błędu.
Czemu to nie była wyłącznie wina Groka
Pierwsza reakcja po przeczytaniu nagłówka brzmi: “Grok dał się zhakować przez Morse’a, słaby model”. To jednak nie jest cała prawda. Grok był częścią łańcucha, ale właściwa luka leżała w warstwie autoryzacji Bankra. Sam Grok zachował się tak, jak każdy model językowy z funkcją dekodowania – dostał prośbę, zdekodował, opublikował. To zachowanie zgodne z dokumentacją produktu i rutynowo wykorzystywane do legalnych celów: tłumaczeń, dekodowania, parsowania.
Wada leżała głębiej, w infrastrukturze Bankrbota. Vadim, były core contributor sieci NEAR, podsumował to celnie:
Polecenie pojawiające się w publicznym tekście nigdy nie powinno dziedziczyć uprawnień portfela tylko dlatego, że pasuje do formatu języka naturalnego.
Bankrbot traktował publiczne odpowiedzi Groka jako autoryzowane polecenia, ponieważ Grok jest “zaufanym kontem X”. To jak gdyby bank realizował przelewy na podstawie tego, co kasjer wypowiedział na głos w hali, bez podpisu klienta. Sprawca po prostu znalazł ten szew. Zespół Bankr po incydencie wdrożył kilka poprawek. Najważniejsza to twarda blokada odpowiedzi od Groka (przywrócona, bo wcześniej była, ale zniknęła przy przepisywaniu agenta). Dalej idzie opcjonalna lista dozwolonych adresów IP oraz klucze API z ograniczonymi uprawnieniami. Na koniec zespół dodał osobny przełącznik wyłączający akcje wywoływane przez odpowiedzi z X dla każdego konta z osobna.
Według publicznie dostępnych informacji na 6 maja 2026 xAI ani Elon Musk nie odpowiedzieli publicznie na sprawę. Sam Grok jako bot przyznał na X: “Zostałem trafiony prompt injection” (cytat za publicznymi odpowiedziami konta). Bankrbot z kolei napisał wprost: “Wyłączyłem już Grokowi możliwość wywoływania moich komend, żeby zatamować krwawienie” (cytat za publicznym wątkiem na X przekazanym przez CryptoSlate i Cryptotimes).
Co to znaczy dla osób budujących agenty AI w n8n
Tu dochodzimy do najważniejszej części dla czytelnika tego bloga. Atak na Groka i Bankrbota to nie egzotyczny przypadek z krypto. To wzorzec, który dotyczy każdego workflow z agentem LLM mającym dostęp do akcji wywołujących skutki. Mowa o wysyłaniu maili, modyfikacji CRM, przelewach czy publikacji treści. W n8n wystarczy node “AI Agent” połączony z node’em “Send Email” lub “HTTP Request POST” do API banku, by analogiczny scenariusz stał się możliwy. Dlatego o szerszym kontekście bezpieczeństwa agentowego pisaliśmy w bezpieczeństwie serwerów MCP dla agentów AI, gdzie mechanizmy ochrony są pokrewne.
Sześć zasad, które chronią Twój workflow
1. Wynik LLM to NIE autoryzacja. Każdy wynik z modelu, który ma trafić do akcji wywołującej skutki, musi przejść przez deterministyczną walidację. Regex, whitelist, schemat strukturalnego wyniku (JSON Schema, Pydantic) albo prosty if-then. Nie polegaj na tym, że LLM “wie, co robi”.
2. Ufanie tagom i mentions to backdoor. Bankrbot ufał, że jeśli @grok napisał “@bankrbot zrób X”, to autoryzowany użytkownik tego chce. W n8n analogicznie: webhook trigger od “zaufanego” agenta nie znaczy, że content webhooka jest bezpieczny. Walidacja na content, nie na nadawcę.
3. Łańcuchy LLM-on-LLM podwajają powierzchnię ataku. Jeśli w workflow agent A pisze prompt do agenta B (np. podsumowanie → pisanie maili), traktuj wynik A jako niezaufane wejście dla B. Włóż między nie sanitizer, strukturalny wynik albo “człowieka w pętli” dla wrażliwych akcji.
4. Encoded inputs traktuj jako zewnętrzne źródło. Morse, base64, hex, image OCR – jeśli model dekoduje cokolwiek, wynik dekodowania jest tak samo nieufany jak surowy tekst od użytkownika. Nawet jeśli enkoder to twój własny model.
5. Wrażliwe akcje wymagają potwierdzenia poza kanałem. Każdy transfer pieniędzy, mass email, DELETE w produkcyjnej bazie – drugi kanał weryfikacji. Kliknięcie w mailu, 2FA, manual approval node w n8n. Praktyczny pattern dla agentów: agent przygotowuje akcję, człowiek lub zewnętrzny system ją zatwierdza.
6. NFT i tokeny po stronie klienta to anti-pattern uprawnień. Bankr używał Bankr Club NFT jako klucza. Każdy mógł go przesłać do dowolnego portfela. Jeśli Twoja autoryzacja opiera się na czymś, co istnieje “po drugiej stronie sieci” bez weryfikacji konkretnego whitelisted address – masz problem analogiczny.
Kurs n8n 2.0 · Kodożercy
n8n + AI = automatyzacje, które naprawdę myślą
n8n pozwala podłączyć modele AI do swoich workflow – wysyłać dane do ChatGPT, analizować wyniki, reagować automatycznie. Kurs n8n 2.0 na Kodożercach pokaże Ci jak to połączyć.
Sprawdź jak to działa →
Podsumowanie
Atak na Groka i Bankrbota nie był ani genialny, ani technicznie nowy. To stara klasa błędów zastosowana do nowego stylu pracy z LLM-ami w publicznych wątkach na X. Mówimy o trzech wektorach jeden na drugim: encoded jailbreak, indirect prompt injection i confused deputy. Sprawa skończyła się szczęśliwie, ponieważ atakujący zwrócił środki, jednak mechanizm zostaje. Każdy, kto w n8n czy podobnym narzędziu łączy agenta AI z node’ami wywołującymi skutki finansowe, mailowe lub bazodanowe, dotyka tego samego problemu. Dlatego sześć zasad z końca artykułu to dziś minimum projektowe dla każdego workflow z LLM-em w środku.
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.
