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 w historii. 502 uczestników, 8 krajów, 23 typy ataków, wszystkie dostępne mechanizmy obrony ocenione jako niewystarczające. Poniżej stanowisko inżynierskie, które Webvise zajął następnego ranka.
Tematy
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 dostarczył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.
Prowadzimy wewnętrzny system multi-agent o nazwie 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, które jawnie zatwierdziliśmy i ręcznie selekcjonowaliśmy. Żadne nie podąża za linkami. Żadne nie wykonuje zewnętrznych instrukcji. Po opublikowaniu artykułu DeepMind przeprowadziliśmy audyt każdego cron i zasada pozostała niezmieniona. Pozostała niezmieniona, bo zapisaliśmy ją dwa lata temu i odmówiliśmy jej rozluźnienia. 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." Przekład: proszę, daj atakującemu kontrolującemu wpis na blogu konkurencji zapisywalny kanał do sesji naszego klienta.
- "Niech użytkownicy wklejają dowolny URL, a agent go podsumuje." Przekład: proszę, pozwól każdemu użytkownikowi, gdziekolwiek jest, wkleić URL, którego HTML zawiera ukryte instrukcje eksfiltrujące kolejne dziesięć wiadomości z rozmowy.
- "Dodaj RAG do dokumentacji zewnętrznego dostawcy, której sami nie hostujemy." Przekład: proszę, przyznaj uprawnienia tool-calling naszego agenta temu pracownikowi marketingu po stronie dostawcy, który edytuje stronę dokumentacji jako następny.
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:
| 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 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.
To jest pozycja sprzedażowa, nie popis pokory
Łatwo byłoby odczytać ten artykuł jako agencję mówiącą *jesteśmy zbyt ostrożni, żeby wziąć Państwa pieniądze.* Prawda jest odwrotna. Artykuł DeepMind daje każdemu zespołowi, który budował wiarygodność inżynierską przed boomem agentów, nieuczciwą przewagę: możemy powiedzieć *nie* konkretnym żądaniom dotyczącym funkcji, na piśmie, z cytatem, i usłyszeć od klienta podziękowanie. Agencje, które nie mówią nie, to te, które pojawią się w wiadomościach pod koniec 2026 roku, gdy pierwszy wyciek danych z biznesowego chatbota dostanie własną nazwę.
Ta sama szansa, która istnieje teraz w content marketingu, istnieje w inżynierii agentów. Rynek zaraz zostanie zalany podatnymi na przejęcie chatbotami, dokładnie tak samo, jak jest zalewany generowanym przez LLM SEO-slopem. Premia trafi do zespołów, które potrafią udowodnić z wyprzedzeniem, że ich produkt do nich nie należy.
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.