Agenci AI i prompt injection – nowe zagrożenie w sieci ujawnione

Czy pozwoliłbyś, by obcy blog albo przypadkowy e-mail wydawał polecenia w twoim imieniu? W świecie agentów AI to się dzieje naprawdę – i na dodatek bywa niewidoczne dla człowieka.

Agenci językowi coraz śmielej klikają, piszą, podsumowują i „załatwiają sprawy” w sieci. Wraz z tą sprawczością rośnie jednak pokusa i skuteczność prompt injection – niewidzialnych podszeptów ukrytych w treściach, które agent czyta po drodze. Dobra wiadomość: branża zaczyna traktować to nie jak pojedynczy trik do zablokowania, ale jak cały obszar inżynierii bezpieczeństwa. Zła: cudownego leku nadal nie ma.

Tu nie chodzi o filtr na brzydkie słowa

Prompt injection to nie tylko ktoś, kto pisze „zignoruj zasady”. Dzisiejsze ataki przypominają raczej socjotechnikę niż proste łamanie komend. Instrukcje są wplatane w strony, dokumenty czy maile, by przejąć kontekst i skłonić agenta do działań sprzecznych z celem użytkownika. Bywa, że robią to białym fontem albo w metadanych, więc człowiek nic nie zauważy – agent już tak.

Ten problem wyewoluował z epoki żartów na Wikipedii do pełnokrwistej inżynierii ataku. OpenAI opisywało przypadek, w którym e-mail instruował asystenta, by „mając pełne uprawnienia” wyciągnął i przetworzył dane pracowników, łącznie z identyfikatorami osobowymi – a potem wysłał je do systemu zgodności. To nie science fiction. A gdy agent ma narzędzia do wysyłania maili, edycji plików czy logowania się do serwisów, „źle zinterpretowany ciąg znaków” staje się poważnym incydentem.

Od SQL do socjotechniki

Źródło problemu brzmi znajomo dla ludzi od bezpieczeństwa: konkatenacja zaufanej „logiki” systemu z niezaufanymi danymi wejściowymi. Jak w SQL injection, tyle że zamiast zapytań bazodanowych, mamy prompty. Tyle że tu nie ma „jednego parametryzowanego zapytania”, które wszystko naprawi. Ryzyko zależy od aplikacji, jej narzędzi, źródeł danych (np. RAG), a wstrzyknięte instrukcje mogą być ukryte, zakodowane albo rozciągnięte w czasie.

Co gorsza, najsłabszym ogniwem bywa… sama wiara w model. Perplexity wypuściło BrowseSafe – detektor „złych treści” w HTML. Red team Lasso Security pokazał 36% skuteczność obejścia zwykłymi technikami kodowania (NATO, Pig Latin, Base32). „Model nie normalizuje treści przed klasyfikacją, więc jeśli intencja jest zaszyta, semantyczna warstwa jej nie zobaczy” – wyjaśniał inżynier Lasso. Innymi słowy: LLM pilnujący LLM-a to słaby ostatni bastion.

Architektura zamiast zaklęć

Jeśli dzisiejsze LLM-y da się „zagadać”, trzeba projektować system tak, by nawet „zagadany” model nie mógł narobić szkód. Google DeepMind zaproponował podejście CaMeL, które traktuje model jako komponent niezaufany i opiera się na starych, dobrych zasadach inżynierii bezpieczeństwa: kontrola przepływu, uprawnienia, kontrola przepływu informacji. To nie kolejny strażnik-model, tylko rama, która ustawia granice między poleceniem użytkownika a tym, co przychodzi z zewnątrz. [5]

W podobnym duchu myśli Google w Chromie, dorzucając do agentów przeglądarkowych dwa bezpieczniki. Po pierwsze, User Alignment Critic – osobny „sędzia” działający w odseparowanym środowisku, który nie widzi surowych treści z sieci, tylko metadane proponowanego działania, i może je zablokować, jeśli nie służy celowi użytkownika. Po drugie, Agent Origin Sets – bramka, która ogranicza dostęp agenta tylko do źródeł relewantnych dla bieżącego zadania lub świadomie udostępnionych przez użytkownika. Do tego dochodzi dziennik działań i pytanie o zgodę przed wejściem na wrażliwe serwisy. [4]

OpenAI idzie jeszcze inną ścieżką: modelowo-systemową. W ChatGPT wprowadzono m.in. Safe URL – mechanizm, który wykrywa, kiedy asystent może wynieść wiedzę o rozmowie na zewnątrz. Wtedy prosi o potwierdzenie lub blokuje akcję, sugerując inną drogę. Podobne zasady działają w nawigacji, Canvasie i aplikacjach – nie ma „cichych” wrażliwych operacji. Firma traktuje temat jak socjotechnikę: nie tylko filtrować złośliwy tekst, ale ograniczać skutki manipulacji, nawet jeśli do niej dojdzie. Brzmi jak szkolenie działu obsługi klienta? Bo o to chodzi.

Fakty, które studzą hurraoptymizm

Badania Intuita (ASTRA) pokazują, że „większy model” to nie automatycznie „bardziej posłuszny agent”. W wieloetapowych scenariuszach z narzędziami mniejsze modele potrafiły wypaść lepiej, a korelacja między odpornością na jailbreaki w czacie a trzymaniem się guardrails podczas użycia narzędzi była… ujemna. Odmawianie szkodliwych tekstów to inna umiejętność niż bezpieczne planowanie i wybór akcji.

OpenAI ujawniło z kolei, że automatyczny „atakujący” zbudowany na LLM i RL potrafił wydobyć nowe klasy podatności w trybie przeglądarkowego agenta Atlas. Efekt? Szybkie doszkalanie modeli w trybie adwersarialnym i twarde zmiany systemowe: flagi na osadzone instrukcje, więcej monitów o zgodę, wzmocnione instrukcje i monitoring. [6]

A jeśli komuś się marzy uniwersalna tarcza, Bruce Schneier sprowadza na ziemię: ogólne, niezawodne zabezpieczenia przed prompt injection są dziś poza zasięgiem – spektrum trików jest nieskończone i ciągle mutuje. Nasza inspiracja? Ludzie. Mamy instynkty, normy i procedury oraz odruch przerwania automatu, gdy „coś nie gra”. Agentom trzeba wbudować podobne warstwy: normy (zasady), separację ról i decyzji, eskalację do człowieka.

Projektowanie na realny świat, nie na benchmark

Wspólny mianownik dojrzałych podejść jest jasny. Po pierwsze, nie polegać na jednym detektorze treści. Po drugie, ograniczać możliwości: precyzyjne uprawnienia, bramki do źródeł, krytycy-sędziowie działający w izolacji, sandboxy. Po trzecie, widoczność i zgody: logi działań, potwierdzenia przy wrażliwych akcjach, brak „cichych” operacji. I wreszcie: żywa ocena odporności – automatyczne red teamingi, testy scenariuszowe i metryki dedykowane agentom, a nie czatowym pogadankom.

Dlaczego to ważne? Bo wektor ataku przesunął się z „nakłoń model do złej odpowiedzi” na „nakłoń system do złej akcji”. Gdy agent może wysłać e-maila, przelać środki albo odwiedzić portal zdrowotny, samo „bycie sprytniejszym” już nie wystarcza. Trzeba zbudować porządne barierki, zanim w ogóle dopuścimy go do ruchu.

Krótka ironia na koniec: jeśli twoja strategia obrony sprowadza się do „model wykryje zło”, przygotuj się na porażkę w wersji Pig Latin. Zamiast szukać magicznego promptu, który uodporni wszystko, lepiej zadać sobie nudne, inżynierskie pytania: jakie uprawnienia naprawdę są potrzebne? Co jest wrażliwe? Kto i kiedy ma prawo powiedzieć „stop”? To mało widowiskowe, ale to właśnie tam wygrywa się z prompt injection.

Źródła

• [1] https://startuphub.ai/ai-news/artificial-intelligence/2026/openai-tackles-ai-agent-prompt-injection
• [2] https://aws.amazon.com/blogs/machine-learning/securing-amazon-bedrock-agents-a-guide-to-safeguarding-against-indirect-prompt-injections/
• [3] https://spectrum.ieee.org/prompt-injection-attack
• [4] https://techradar.com/pro/security/google-adds-prompt-injection-defenses-to-chrome
• [5] https://arstechnica.com/information-technology/2025/04/researchers-claim-breakthrough-in-fight-against-ais-frustrating-security-hole/
• [6] https://medianama.com/2025/12/223-explained-prompt-injections-ai-browsers-chatgpt-atlas/
• [7] https://helpnetsecurity.com/2025/12/09/ai-agent-testing-research/
• [8] https://bdtechtalks.com/2026/01/19/perplexity-browsesafe-prompt-injection/