Dlaczego nie wdrożymy agentów AI czytających otwarty internet

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ęliśmy z tego badania i przypiąłem na naszym kanale inżynierskim następnego ranka, jest jedynym, które ma znaczenie dla każdego wdrażającego biznesowego chatbota w 2026 roku: jeśli Twój agent AI czyta tekst kontrolowany przez atakującego, a następnie wykonuje jakiekolwiek działania z uprawnieniami użytkownika, właśnie wbudowałeś podatność umożliwiającą 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 wracamy 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. Musiał jedynie raz skompromitować dane konsumowane przez model.

Nasz założyciel prowadzi 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. Pozostała niezmieniona, bo została zapisana dwa lata temu i nigdy nie została rozluźniona. Większość produkcyjnych stosów agentowych, jakie widzimy 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 widzimy trzy warianty tego samego zapytania:

• "Niech chatbot odpowiada na pytania, przeglądając stronę konkurencji." W praktyce oznaczałoby to przyznanie atakującemu kontrolującemu wpis na blogu konkurencji 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 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 naszym komentarzem do każdej:

Jeśli potraktować tabelę poważnie, nie ma odpowiedzialnego sposobu 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żamy zamiast tego

Webvise wdrożył funkcje AI na produkcji klientów, w tym stronę budowlaną MP Bau, która kieruje wywołania modeli przez Vercel AI Gateway w celu routingu dostawców i obserwowalności. Poniższe pięć zasad to to, co sprawiło, że ten build był możliwy do obrony, i są one teraz twardymi warunkami wstępnymi dla każdej pracy AI, którą podejmujemy:

• Tylko agenty z zamkniętymi danymi wejściowymi. Agent czyta ze skończonego, ręcznie wyselekcjonowanego zestawu źródeł, które kontrolujemy. Żadnego otwartego internetu. Żadnych URL wklejanych przez użytkownika. Żadnego zewnętrznego RAG opartego na dokumentacji spoza naszej kontroli.

• Tryb tylko do odczytu jako domyślny. Jeśli agent musi czytać coś, czemu w pełni nie ufamy, 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 jest to kompletna obrona 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 kierujemy przez Vercel AI Gateway, dzięki czemu możemy zmieniać dostawców, logować każdy prompt i odpowiedź oraz unieważnić klucz w ciągu sekund. Jeśli coś w logach wygląda niepokojąco, możemy zatamować krwawienie w tej samej minucie, w której to zauważamy.

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 był opłacany za narysowanie granicy zaufania.

Dlaczego odmawiamy realizacji pewnych funkcji

Artykuł DeepMind pozwala każdemu zespołowi z doświadczeniem inżynierskim sprzed boomu agentów odmawiać realizacji konkretnych żądań dotyczących funkcji, przedstawiając jasne uzasadnienie techniczne; 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 nie wpisuje się w ten trend.

Gdzie wyznaczamy granicę

Najkrótsza wersja zasady, tę, którą zapisujemy 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 zbudowane. Jeśli da się je przeformułować tak, by pozostało po jednej stronie, przeformułowujemy je razem z klientem i wdrażamy przeformułowaną wersję. Artykuł DeepMind nie wynalazł tej dyscypliny. Jedynie zabrał każde wymówki za jej brak.

W webvise budujemy funkcje AI dla firm, w których koszt jednej ujawnionej wiadomości klienta jest wyższy niż koszt powiedzenia nie żądaniu dotyczącemu funkcji. Jeśli to opisuje Państwa projekt, skontaktujcie się z nami, a wspólnie wyznaczymy granicę zaufania, zanim zostanie napisana jakakolwiek linia kodu.