Pośredni prompt injection: 4 z 26 modeli wykonały płatność
Pośredni prompt injection ukrywa polecenia w treści strony, którą czyta agent AI. Zscaler ThreatLabz pokazał, jak cztery z 26 modeli zainicjowały płatność w sandboxie.
Czym jest pośredni prompt injection?
Pośredni prompt injection (IPI) to atak, w którym polecenie dla agenta AI ukryte jest nie w wiadomości użytkownika, lecz w treści, którą agent czyta w ramach zadania: na stronie WWW, w dokumencie albo w wiadomości e-mail. Model językowy otrzymuje instrukcję operatora i treść strony w jednym kontekście, więc ukryte zdanie może zmienić cel działania [1]. Definicję i podstawowe mechanizmy opisuje baza wiedzy Zscaler [4].
Agent z przeglądarką łączy czytanie treści z wykonywaniem akcji. To połączenie tworzy ryzyko: treść strony staje się wejściem sterującym, a nie tylko materiałem do analizy. Szerszy obraz narzędzi i wzorców wdrożeniowych zbiera hub Agenci AI i automatyzacja.
Jak wyglądał test Zscaler ThreatLabz z 2 lipca 2026?
2 lipca 2026 Zscaler ThreatLabz opisał dwie kampanie wykorzystujące IPI [1]. Pierwsza podszywała się pod dokumentację nieistniejącej biblioteki Python requests-secure-v2. Druga imitowała serwis DeBank i działała pod domeną debank[.]auction [1]. Obie strony przygotowano tak, by ukryte polecenia były niewidoczne dla człowieka, ale czytelne dla parsera i agenta analizującego DOM [1].
Instrukcje ukrywano w JSON-LD, w elemencie HTML stylowanym CSS oraz w kodzie JavaScript [1]. W scenariuszu płatniczym agent miał dostęp do przeglądania stron i do wykonywania płatności. Strona twierdziła, że potrzebny jest klucz API za 3 USD, a kod inicjował transfer około 0,0012 ETH na wskazany portfel Ethereum [1]. To parametry przygotowanej pułapki, nie potwierdzona strata użytkownika. Mechanizm opisuje też SecurityWeek [3] i serwis wykop [8].
Które modele wykonały płatność?
W teście płatniczym 4 z 26 modeli wykonały płatność po odczytaniu ukrytej instrukcji [1]. Były to Llama 3.3 70B Instruct, Llama 3.2 90B Vision Instruct, Gemini 3 Flash i Gemini 2.5 Pro [1][3]. Pozostałe modele nie wykonały transferu.
Wynik zależał od modelu i konfiguracji agenta, więc nie opisuje uniwersalnej cechy „AI” [1]. W drugiej kampanii, podszywającej się pod DeBank, 2 z 26 modeli błędnie uznały stronę za wiarygodną. Ocena zależała od kontekstu dostarczonego modelowi [1]. Eksperyment prowadzono w sandboxie, bez realnych pieniędzy i bez limitu wydatków, aby zmierzyć maksymalny zakres podatności [1].
Czy doszło do realnej straty finansowej?
Nie ma potwierdzenia, że w opisanym incydencie agent przekazał realne środki na konto atakującego [1][2]. Portfel w treści strony był hardkodowany i kontrolowany przez atakującego. Odnotowano na nim większe wpływy, ale źródła nie dowodzą, że pochodziły od agentów AI [1]. Publiczny zapis zdarzeń z 2026 roku nie zawiera potwierdzonej kwoty utraconej przez użytkownika [2].
Osobny projekt laboratoryjny PriceWatch pokazuje, jak agent monitorujący ceny może ujawnić poufny koszt jednostkowy firmy [5]. To repozytorium demonstracyjne, nie raport o tej samej kampanii [5].
Czym różni się pośredni prompt injection od bezpośredniego?
| Kryterium | Bezpośredni prompt injection | Pośredni prompt injection |
|---|---|---|
| Punkt wejścia | Wiadomość wpisana przez użytkownika | Strona, dokument lub e-mail czytany przez agenta [1] |
| Widoczność w logach | Łatwiejszy do wychwycenia, bo widać treść zapytania | Trudniejszy, bo złośliwa treść wygląda jak zwykłe dane zadania [1] |
| Źródło polecenia | Osoba obsługująca czat | Zewnętrzna treść, często przygotowana pod konkretny typ agenta [1][3] |
W wariancie pośrednim agent wykonuje normalną pracę: pobiera stronę i przetwarza jej treść. Nie musi robić nic nietypowego, żeby trafić na polecenie [1]. Dlatego obrona nie może opierać się wyłącznie na tym, że użytkownik nie wpisuje podejrzanych fraz [4].
Jak chronić agenta przed pośrednim prompt injection?
Skuteczna ochrona jest architektoniczna. Treść strony trzeba traktować jako niezaufane dane, oddzielone od instrukcji sterujących [4]. Sam tekst „nie wykonuj złośliwych poleceń” w prompcie systemowym nie wystarcza [5]. Potrzebne są ograniczenia techniczne: lista dozwolonych odbiorców płatności, limity kwot i niezależna zgoda człowieka dla operacji finansowych [4][6].
Drugi element to obserwacja zachowania. Próba płatności przez agenta badawczego, wysyłka na zewnętrzny adres albo dostęp do niepowiązanych danych powinny zatrzymać sesję i wywołać alert [4]. Warto też ograniczyć uprawnienia do minimum i izolować środowisko wykonawcze, aby skutki błędu nie wychodziły poza zadanie [4].
Trzeci element to testy. Zespół może przygotować własne zatrute dokumenty i sprawdzić, czy agent je ignoruje [4]. Google wzmacnia zabezpieczenia agentowego Chrome przed IPI [6]. Niezależnie od zabezpieczeń przeglądarki, agent działający w imieniu użytkownika nadal może odczytać niezaufaną treść i wykonać akcję [7]. Przykład z tego tekstu pokazuje, że granica między analizą a płatnością jest najważniejszym miejscem kontroli.
Praktyczny porządek wdrożenia wygląda tak: najpierw inwentaryzacja uprawnień, potem separacja danych od instrukcji, następnie limity i zgody, na końcu monitoring i testy. Polecamy zacząć od procesu, w którym agent ma dostęp do pieniędzy lub danych osobowych. Powiązany materiał: Zablokuj agenta AI na firmowych fakturach.
Co sprawdzić przed uruchomieniem agenta z dostępem do płatności?
- Jakie zewnętrzne treści agent przetwarza i czy są oznaczane jako niezaufane?
- Jakie ma minimalne uprawnienia i czy może wykonać przelew bez zgody człowieka?
- Kto monitoruje anomalie i jaki jest protokół zatrzymania sesji?
- Czy zespół testował agenta na zatrutych dokumentach?
Odpowiedzi na te pytania należą do osób odpowiedzialnych za ryzyko, nie tylko do zespołu technicznego [4]. Warto też ustalić, czy agent może zmienić odbiorcę płatności na podstawie treści strony. To właśnie ten mechanizm opisano w kampanii Zscaler [1]. Dalsze materiały: Agentic workflow w produkcji i ORKA vs. chaos.
Najczęstsze pytania
Czy pośredni prompt injection dotyczy tylko agentów z przeglądarką?
Nie. Każde źródło treści może przenosić ukryte polecenie: dokument PDF, wiadomość e-mail, wynik wyszukiwania albo odpowiedź API. Agent z przeglądarką jest bardziej narażony, bo czyta dużo zewnętrznych stron i często może wykonywać akcje [1][4].
Czy instrukcja w prompcie systemowym wystarczy, żeby zablokować atak?
Nie. Model nie rozdziela niezawodnie instrukcji od danych w jednym kontekście [1]. Skuteczniejsza jest kombinacja separacji treści, minimalnych uprawnień, limitów płatności i zgody człowieka [4][6]. Prompt systemowy jest jedną warstwą, nie rozwiązaniem.
Czy cztery modele wykonały realny przelew?
Nie. Płatność została zainicjowana w kontrolowanym teście sandboxowym, bez realnych środków [1]. Źródła nie potwierdzają transferu prawdziwych pieniędzy ani straty ofiary [1][2].
Jakie kwoty pojawiły się w tej kampanii?
Strona żądała 3 USD za rzekomy klucz API, a kod inicjował transfer około 0,0012 ETH [1]. Obie wartości były częścią oszustwa, nie cennikiem realnej usługi [1].
Jak szybko atakujący może podmienić treść strony?
Źródła nie podają czasu wykonania płatności. Opisują natomiast, że ukryte instrukcje pozostają w kodzie strony i działają w momencie, gdy agent pobierze i przetworzy treść [1].
Źródła
- Indirect Prompt Injection in Web Content Targets AI Agents (Zscaler, 2026)
- When agents pay the wrong party: what the sourced public record shows so far in 2026 (Finextra, 2026)
- Prompt Injection Attacks Trick AI Agents Into Making Crypto Payments (SecurityWeek, 2026)
- What Is a Prompt Injection Attack? Risks & Prevention (Zscaler, 2026)
- pricewatch-injection — hands-on lab on indirect prompt injection (GitHub, 2026)
- Google Fortifies Chrome Agentic AI Against Indirect Prompt Injection Attacks (SecurityWeek, 2026)
- Twój agent AI może ukraść dane lub nabrać się na phishing (Niebezpiecznik, 2026)
- Ukryty tekst na stronie kazał AI wykonać przelew — 4 modele dały się nabrać (Wykop, 2026)