5 kwietnia 2026 roku Google DeepMind opublikował największe empiryczne badanie manipulacji agentami AI, jakie kiedykolwiek przeprowadzono: 502 prawdziwych uczestników w 8 krajach, 23 odrębne typy ataków, modele frontierowe obejmujące GPT-4o, Claude i Gemini. Jedyne zdanie, które wyciągnąłem z tego badania i przypiąłem w notatkach inżynierskich następnego ranka, jest jedynym, które ma znaczenie dla każdego wdrażającego biznesowego chatbota w 2026 roku: jeśli agent AI czyta tekst kontrolowany przez atakującego, a następnie wykonuje jakiekolwiek działania z uprawnieniami użytkownika, w system wbudowana została podatność umożliwiająca eksfiltrację danych. To jest powód, dla którego webvise nie zbuduje, dla żadnego klienta i za żadną cenę, agenta AI przeglądającego otwarty internet.
Co DeepMind rzeczywiście zmierzył
Większość doniesień prasowych na temat badania podała nagłówkową liczbę 23 typów ataków i na tym poprzestała. Liczby ukryte w środku mają kluczowe znaczenie dla każdego, kto uruchamia funkcje AI na produkcji:
- 502 uczestników w rzeczywistych warunkach, nie w symulowanych sesjach laboratoryjnych
- 8 krajów, co oznacza, że ataki nie były optymalizowane pod jeden kontekst kulturowy ani językowy
- 23 typy ataków w 10 kategoriach, w tym bezpośredni prompt injection, pośredni injection przez treści webowe, multimodalny pixel injection, document injection, manipulacja środowiskiem, osadzanie jailbreak, zatrucie pamięci, goal hijacking, exfiltration oraz cross-agent injection
- Wszystkie cztery klasy obrony (sanityzacja danych wejściowych, zabezpieczenia na poziomie promptu, sandboxing, nadzór ludzki) ocenione jako niewystarczające w skali
Kategoria, do której wracam najczęściej, to ósma: *goal hijacking poprzez stopniowy dryf instrukcji w kolejnych interakcjach.* Każde demo systemu agentowego, jakie kiedykolwiek widziano, przetrwa jeden adversarialny prompt. Żadne nie przetrwa stu starannie rozłożonych w czasie.
Kaskadowy wniosek, który większość relacji pominęła
W badaniu ukryte jest odkrycie, które rozstrzyga, czy produkty multi-agent są w ogóle bezpieczne do wdrożenia. W każdym pipeline, w którym agent A pobiera treści, agent B je przetwarza, a agent C wykonuje akcję, pojedynczy injection w strumień danych agenta A propaguje się przez każdego kolejnego agenta. Agent B ufa wyjściu agenta A. Agent C ufa wyjściu agenta B. Atakujący nie musiał kompromitować modelu, lecz jedynie raz skompromitować dane przez model konsumowane.
Prowadzę osobistą konfigurację multi-agent z Hermes (agent NousResearch na Telegramie), który obsługuje 14 cron jobs obejmujących codzienne podsumowania informacji, streszczenia wytycznych medycznych i logistykę osobistą. Każde z tych 14 zadań czyta ze źródła jawnie zatwierdzonego i ręcznie selekcjonowanego. Żadne nie podąża za linkami. Żadne nie wykonuje zewnętrznych instrukcji. Po opublikowaniu artykułu DeepMind przeprowadzono audyt każdego cron i zasada pozostała niezmieniona, bo została zapisana dwa lata temu i nigdy nie została rozluźniona. Większość produkcyjnych stosów agentowych, jakie widać w briefach klientów, tej zasady nie ma, a inżynierowie je budujący nigdy nie byli proszeni o jej spisanie.
Jak "czytanie otwartego internetu" wygląda w briefie klienta
Co miesiąc pojawia się ten sam wniosek w trzech wariantach:
- "Niech chatbot odpowiada na pytania, przeglądając stronę konkurencji." W praktyce oznaczałoby to przyznanie atakującemu kontrolującemu dowolną odwiedzaną stronę zapisywalnego kanału do sesji klienta.
- "Niech użytkownicy wklejają dowolny URL, a agent go podsumuje." W praktyce oznaczałoby to umożliwienie każdemu użytkownikowi wklejenia URL, którego HTML zawiera ukryte instrukcje eksfiltrujące kolejne wiadomości z rozmowy.
- "Dodaj RAG do dokumentacji zewnętrznego dostawcy, której sami nie hostujemy." W praktyce oznaczałoby to przyznanie uprawnień tool-calling agenta każdemu, kto edytuje tę dokumentację.
Każde z tych zapytań podłącza kontrolowany przez atakującego kanał tekstowy bezpośrednio do systemu, który po tej samej stronie granicy zaufania ma dane użytkownika, wywołania narzędzi i wychodzący dostęp sieciowy. Żadne z nich nie jest złośliwe ze strony klienta. Każde jest uzasadnionym pomysłem produktowym. Wszystkie są też, po 5 kwietnia 2026 roku, niemożliwe do wdrożenia.
Każda dostępna obrona zawodzi
DeepMind przetestował wszystkie cztery oczywiste rodziny mechanizmów obronnych. Poniżej ich ocena wraz z komentarzem do każdej:
| Obrona | Werdykt DeepMind | Dlaczego zawodzi w praktyce |
|---|---|---|
| Sanityzacja danych wejściowych | Niewystarczająca | Nie da się w czasie inferencji sanityzować pikseli obrazów, metadanych dokumentów ani notatek prelegenta wewnątrz PDF. Powierzchnia ataku to tekst i każda inna modalność konsumowana przez agenta. |
| Zabezpieczenia na poziomie promptu | Niewystarczające | Wstrzyknięta treść jest zaprojektowana tak, by wyglądać jak legitymalna część strony. Zanim model ją zobaczy, guard już jej zaufał. |
| Sandboxing | Ogranicza zasięg ataku, nie zapobiega injectionowi | Sandboxing pomaga, gdy skutek ataku jest izolowany. Nie pomaga, gdy celem ataku jest odczytanie danych użytkownika i zapisanie ich poprzez legalnie wyglądające wywołanie API. |
| Nadzór ludzki | Niewystarczający w skali | Operator uruchamiający agenta na 50 źródłach nie jest w stanie przeglądać każdej strony pod kątem ukrytych instrukcji. Cały sens agenta polegał na tym, że człowiek wyłączył się z pętli. |
Jeśli potraktować tabelę poważnie, nie istnieje odpowiedzialny sposób na wdrożenie agenta, który czyta tekst kontrolowany przez atakującego i jednocześnie wykonuje działania z uprawnieniami użytkownika. Jedynym dostępnym ruchem jest usunięcie jednej z tych dwóch właściwości.
Co wdrażam zamiast tego
webvise wdrożył funkcje AI na produkcji klientów, w tym landing page budowlany, którego wywołania modeli przechodzą przez Vercel AI Gateway w celu routingu dostawców i obserwowalności. Pięć zasad poniżej to to, co sprawiło, że ten build był możliwy do obrony, i stanowią one teraz twarde warunki wstępne dla każdej pracy z AI:
- Tylko agenty z zamkniętymi danymi wejściowymi. Agent czyta ze skończonego, ręcznie wyselekcjonowanego zestawu źródeł pozostających pod bezpośrednią kontrolą. Żadnego otwartego internetu. Żadnych URL wklejanych przez użytkownika. Żadnego zewnętrznego RAG opartego na dokumentacji spoza tej kontroli.
- Tryb tylko do odczytu jako domyślny. Jeśli agent musi czytać coś, czemu w pełni się nie ufa, nie może w tej samej sesji wywoływać narzędzi, wysyłać emaili, zapisywać do bazy danych ani generować wychodzących zapytań sieciowych. Jedno albo drugie, nigdy jednocześnie.
- Izolacja między agentami. Gdy wyjście agenta A trafia do agenta B, B traktuje wyjście A jako dane wejściowe użytkownika, nie jako instrukcje systemowe. To jedna linijka kodu w prompcie i stanowi ona kompletną obronę przed atakiem kaskadowym.
- Budżety możliwości per agent. Każdy agent ma ustaloną listę narzędzi i limit tokenów. Limit jest na tyle mały, że nawet skuteczny injection nie może eksfiltrować więcej niż jedną krótką wiadomość.
- Izolacja dostawcy przez gateway. Każde wywołanie modelu kierowane jest przez Vercel AI Gateway, co umożliwia zmianę dostawców, logowanie każdego promptu i odpowiedzi oraz unieważnienie klucza w ciągu sekund. Jeśli coś w logach wygląda niepokojąco, krwawienie można zatamować w tej samej minucie.
To nie są rozwiązania egzotyczne. Kosztują kilka godzin pracy projektowej, zanim zostanie napisana jakakolwiek linia kodu. Powodem, dla którego większość produktów agentowych w 2026 roku ich nie ma, jest to, że nikt w zespole nie został wyznaczony do narysowania granicy zaufania.
Dlaczego odmawiam realizacji pewnych funkcji
Łatwo odczytać ten artykuł jako głos studia zbyt ostrożnego, by przyjąć zlecenie. To nieprawda. Artykuł DeepMind wręcza każdemu zespołowi z doświadczeniem inżynierskim sprzed boomu agentów wyraźną przewagę: możliwość odmowy realizacji konkretnych żądań dotyczących funkcji z jasnym uzasadnieniem technicznym; klienci zazwyczaj doceniają to z perspektywy czasu. Dostawcy budujący agenty bez tych ograniczeń przyjmują na siebie znaczące ryzyko eksfiltracji, które coraz częściej pojawia się w raportach o incydentach.
Rynek obserwuje szybkie wdrażanie chatbotów pozbawionych zabezpieczeń przed prompt injection, podobnie jak niedawną falę treści niskiej jakości generowanych przez LLM. Przewaga konkurencyjna trafi do zespołów, które potrafią udowodnić z wyprzedzeniem, że ich produkt zbudowany jest według wyższego standardu.
Gdzie przebiega granica
Najkrótsza wersja zasady, tę, którą zapisuję teraz w każdym dokumencie inicjującym projekt, brzmi tak: agent może czytać niezaufane treści albo działać z uprawnieniami użytkownika, ale nie w tej samej sesji. Wszystko inne wynika z tej zasady. Jeśli żądanie dotyczące funkcji przekracza granicę, nie zostaje zrealizowane. Jeśli da się je przeformułować tak, by pozostało po jednej stronie, przeformułowuję je razem z klientem i wdrażam przeformułowaną wersję. Artykuł DeepMind nie wynalazł tej dyscypliny, lecz zabrał każdą wymówkę za jej brak.
webvise buduje funkcje AI dla firm, w których koszt jednej ujawnionej wiadomości klienta jest wyższy niż koszt odmowy realizacji żądania dotyczącego funkcji. Jeśli to opisuje Państwa projekt, zapraszamy do kontaktu, a pierwszym krokiem będzie wspólne wyznaczenie granicy zaufania, zanim zostanie napisana jakakolwiek linia kodu.
Praktyki webvise są zgodne z normami ISO 27001 i ISO 42001.