Agenci przeglądarkowi Amazon i Google stoją przed problemem prompt injection bez idealnego rozwiązania

Agenci przeglądarkowi Amazon i Google mierzą się dziś z tym samym konfliktem: większa autonomia daje atakom prompt injection więcej możliwości wyrządzenia szkód. Mimo nowych zabezpieczeń badacze nadal znajdują sposoby na kierowanie agentami za pośrednictwem zwykłych stron internetowych, e-maili, formularzy i postów w mediach społecznościowych. Ta słabość staje się trwałym ograniczeniem projektowania przeglądarek AI, a nie kolejnym błędem przeglądarki czekającym na jedną prostą poprawkę.

Bezpośrednim problemem jest pośrednie prompt injection, w którym wrogie instrukcje ukryto w treści odczytywanej przez agenta AI. Instrukcje te mogą konkurować z poleceniem użytkownika i wpływać na kolejne działanie agenta. Zwykła przeglądarka wyświetla wrogą treść. Przeglądarka agentowa może ją zinterpretować, przejść do innej usługi i działać z uprawnieniami użytkownika.

To rozróżnienie stawia Amazon i Google w centrum szerszej rywalizacji dotyczącej bezpieczeństwa, w której uczestniczą Microsoft, OpenAI, Anthropic, Perplexity oraz wyspecjalizowani dostawcy przeglądarek. Każda firma chce tworzyć agentów zdolnych wykonywać użyteczne zadania w całej sieci. Jednak każde dodatkowe uprawnienie zwiększa konsekwencje sytuacji, w której agent błędnie rozpozna, komu powinien być posłuszny.

Niepokojący wniosek nie jest taki, że agenci przeglądarkowi są bezużyteczni. Chodzi o to, że dostawcy nie mogą traktować wykrywania prompt injection jako kompletnej granicy bezpieczeństwa. Przedsiębiorstwa muszą zakładać, że część złośliwych instrukcji przejdzie przez zabezpieczenia, i ograniczać, do czego przejęty agent może uzyskać dostęp, co może zmienić lub ujawnić.

Co zmieniło się w wyścigu Amazon i Google o bezpieczeństwo przeglądarek

Prompt injection przestało być teoretyczną słabością modeli i stało się operacyjnym problemem bezpieczeństwa przeglądarek.

Badacze bezpieczeństwa wielokrotnie pokazali, że złośliwa treść może przekierować agenta bez wykorzystywania tradycyjnej ścieżki wykonania kodu w przeglądarce. Atakujący celuje zamiast tego w interpretację treści przez model. Ukryta instrukcja może pojawić się na stronie internetowej, w e-mailu, dokumencie, a nawet elemencie interfejsu użytkownika.

Atak staje się poważny, gdy agent może korzystać z uwierzytelnionych sesji przeglądarki. Może odczytać skrzynkę odbiorczą, otworzyć kolejną kartę, wysłać formularz lub pobrać informacje z połączonej usługi. Działania, które podczas zwykłego zadania wydają się wygodne, stają się użytecznymi elementami łańcucha ataku.

Badacze Zenity opisali tę szerszą klasę słabości przeglądarek agentowych jako PleaseFix. Ich testy dotyczyły sposobu, w jaki agenci realizują cele wyrażone w języku naturalnym, przemieszczając się między stronami internetowymi i lokalnymi zasobami. Według ustaleń dotyczących bezpieczeństwa przeglądarek badacze zaobserwowali różne projekty i zabezpieczenia, ale nadal zidentyfikowali ścieżki ataku w komercyjnych przeglądarkach agentowych.

Istotna zmiana dotyczy drogi atakującego. Tradycyjne ataki na przeglądarki często zależą od luki w oprogramowaniu, złośliwego rozszerzenia, skradzionych danych uwierzytelniających lub zwodniczego kliknięcia. Prompt injection może rozpocząć się od treści, którą agent miał przetworzyć w ramach zwykłego żądania.

Użytkownik może poprosić asystenta o podsumowanie strony produktu. Strona może zawierać instrukcje ukryte wizualnie, lecz nadal dostępne dla modelu. Atakujący może także umieścić instrukcje w publicznym poście, formularzu zapisu do newslettera lub treści pobranej za pomocą narzędzia przeglądarkowego.

Nie gwarantuje to, że każda wstrzyknięta instrukcja zadziała. Modele, klasyfikatory, systemy uprawnień i kontrole działań mogą zatrzymać wiele prób. Problem polega na tym, że mechanizmy te działają przeciwko adaptacyjnemu przeciwnikowi, który może zmieniać sformułowania, prezentację, czas i kontekst.

Własne pomiary Google potwierdzają tę zmianę. Zespoły bezpieczeństwa firmy skanowały publiczne treści internetowe pod kątem znanych wzorców pośredniego prompt injection i zgłosiły 32-procentowy względny wzrost złośliwych wykryć między listopadem 2025 r. a lutym 2026 r. Firma znalazła również znaczną ilość nieszkodliwego tekstu przypominającego ataki, co komplikuje wiarygodną klasyfikację.

Te badania zagrożeń w sieci są istotne, ponieważ zabezpieczenie przeglądarki musi radzić sobie z dwoma konkurującymi błędami. Jeśli przeoczy wrogą treść, agent może zostać zmanipulowany. Jeśli będzie blokować zbyt agresywnie, zwykłe strony i uzasadnione instrukcje staną się nieużyteczne.

Amazon podchodzi do tego problemu poprzez swoją platformę agentów chmurowych, a nie przeglądarkę dla masowego odbiorcy. Bedrock AgentCore Browser zapewnia deweloperom odizolowane środowisko dla agentów, które poruszają się po stronach, wypełniają formularze i wyodrębniają informacje. Możliwości te nadal narażają agentów na niezaufaną treść, nawet jeśli podstawowa sesja przeglądarki jest odizolowana.

Porównanie Amazon i Google odzwierciedla zatem dwa różne modele dystrybucji. Google dodaje funkcje agentowe do przeglądarki używanej bezpośrednio przez ludzi. Amazon dostarcza infrastrukturę, którą firmy wykorzystują do budowania własnej automatyzacji przeglądarkowej. Obie firmy muszą zarządzać tym samym zderzeniem treści otwartej sieci z uprzywilejowanymi działaniami agentów.

Dlaczego agenci przeglądarkowi osłabiają dawną granicę bezpieczeństwa

Podstawowa słabość pojawia się, gdy jeden model otrzymuje zaufane instrukcje i niezaufane dane w ramach wspólnego procesu rozumowania.

Przeglądarki internetowe przez dziesięciolecia oddzielały strony od siebie nawzajem. Polityka same-origin generalnie uniemożliwia jednej domenie swobodne odczytywanie wrażliwych informacji z innej. Dodatkowe bariery zapewniają piaskownice, monity o uprawnienia, izolacja procesów i zasady bezpieczeństwa treści.

Agent AI może przekraczać te granice, ponieważ użytkownik upoważnia go do wykonania zadania. Może odczytać jedną stronę, skonsultować inną usługę i połączyć wyniki. Ta zdolność jest główną zaletą produktu, ale tworzy też pomost, który wroga treść może próbować przejąć.

Model nie musi bezpośrednio łamać polityki same-origin. Może korzystać z legalnych funkcji przeglądarki dostępnych użytkownikowi. Jeśli złośliwa strona przekona agenta do otwarcia skrzynki odbiorczej, odczytania wiadomości i przesłania informacji, każdy pojedynczy krok może wyglądać na autoryzowany.

Bywa to nazywane problemem zdezorientowanego zastępcy. Zaufany komponent ma uzasadnione uprawnienia, lecz atakujący manipuluje nim, by wykorzystał je w niewłaściwym celu. Agenci przeglądarkowi sprawiają, że zastępca staje się konwersacyjny, probabilistyczny i zdolny do planowania kilku kroków.

Badania nad otwartoźródłowymi agentami przeglądarkowymi pokazały, że ten wzorzec może prowadzić do ujawnienia danych uwierzytelniających i nieautoryzowanych działań. Jedno badanie akademickie zgłosiło prompt injection, obejście walidacji domen oraz eksfiltrację danych uwierzytelniających w frameworku automatyzacji przeglądarki. Jego analiza agenta przeglądarkowego obejmowała również ujawnioną podatność i działający dowód koncepcji.

Problem narasta, gdy agent przenosi pamięć między zadaniami. Wroga instrukcja nie zawsze musi natychmiast powodować szkody. Może próbować zmienić zapisany kontekst, utworzyć mylącą preferencję lub wpłynąć na późniejszą decyzję, gdy staną się dostępne wrażliwe zasoby.

Rozumienie obrazu otwiera kolejną drogę ataku. Agent interpretujący zrzuty ekranu może napotkać instrukcje osadzone w obrazach lub elementach interfejsu. Filtrowanie wyłącznie surowego tekstu strony nie wychwyci każdej wiadomości, którą może dostrzec model multimodalny.

Atakujący mogą też unikać oczywistych zwrotów, takich jak „zignoruj wcześniejsze instrukcje”. Mogą przedstawiać złośliwe kroki jako niezbędne elementy pierwotnego celu użytkownika. Na przykład prośba o zapisanie się do newslettera może stać się pretekstem do pobrania danych lub otwarcia innego narzędzia.

Technika ta ma znaczenie, ponieważ wiele zabezpieczeń szuka konfliktu między celem użytkownika a wrogą instrukcją. Atakujący może zamiast tego sprawić, by złośliwe działanie wyglądało na zgodne z tym celem. Sformułowanie staje się mniej podejrzane, podczas gdy wymagana zdolność pozostaje niebezpieczna.

Prompt injection różni się od SQL injection pod jednym kluczowym względem. Oprogramowanie może oddzielać polecenia SQL od danych dzięki ścisłej składni i zapytaniom parametryzowanym. Agenci działający w języku naturalnym polegają na interpretacji kontekstowej, więc instrukcje i informacje nie zawsze mają wyraźną granicę techniczną.

Ustrukturyzowane komunikaty i etykiety pochodzenia mogą poprawić to rozdzielenie. Deweloperzy mogą oznaczać, które treści pochodzą od użytkownika, strony internetowej, narzędzia lub aplikacji. Model nadal jednak musi interpretować zewnętrzną treść, gdy zadanie zależy od jej znaczenia.

Badania opublikowane jako BrowseSafe oceniały ryzyko prompt injection w agentach przeglądarkowych i analizowały zabezpieczenia w realistycznych środowiskach. Praca ta odzwierciedla rodzący się konsensus: wykrywanie pomaga, ale to architektura przeglądarki i projekt uprawnień określają ostateczny wpływ.

Dlatego idealny klasyfikator nie rozwiązałby całego problemu. Klasyfikatory również przetwarzają niejednoznaczny język, a atakujący mogą testować nowe warianty. Obrońcy potrzebują kilku niezależnych mechanizmów kontrolnych, aby jeden błędny osąd nie otworzył dostępu do całej sesji przeglądarki użytkownika.

Zabezpieczenia Amazon i Google stawiają na kontrolę zamiast perfekcyjnego wykrywania

Amazon i Google budują wielowarstwowe zabezpieczenia, ponieważ żadna z firm nie może polegać na jednym filtrze prompt injection.

Google opisało architekturę, która sprawdza działania agenta, zanim trafią one do przeglądarki. User Alignment Critic to oddzielny komponent zaprojektowany do oceny, czy proponowane działanie odpowiada deklarowanemu celowi użytkownika. Separacja pomaga zapobiec sytuacji, w której główny agent zatwierdza własną ryzykowną interpretację.

Google wykorzystuje także informacje o pochodzeniu, potwierdzenia działań, szkolenie modeli i systemy wykrywania. Wrażliwe operacje mogą wymagać wyraźnej zgody użytkownika. Przeglądarka może ograniczać, jakie informacje trafiają do agenta, oraz zachowywać granice bezpieczeństwa wokół danych uwierzytelniających.

W swoim projekcie agentowego Chrome Google przyznaje, że kontakt z niezaufaną treścią internetową tworzy nieodłączne ryzyko pośredniego prompt injection. To sformułowanie jest istotne. Firma przedstawia problem jako zagrożenie architektoniczne wymagające ciągłego ograniczania ryzyka.

Potwierdzanie działań jest użyteczne, ponieważ przywraca ludzki osąd przed krokiem o istotnych konsekwencjach. Użytkownik może odrzucić nieoczekiwany zakup, wiadomość, logowanie lub transfer danych. Częste monity mogą jednak stać się rutyną, wywołując to samo zmęczenie, które widać przy komunikatach o plikach cookie i oknach uprawnień.

Potwierdzenia muszą więc skupiać się na znaczących przejściach. Wysłanie danych do nowej domeny zasługuje na większą kontrolę niż przewijanie strony. Otwarcie menedżera haseł niesie większe ryzyko niż wyodrębnienie publicznego nagłówka. Płaski model zatwierdzania traktuje nierówne działania tak, jakby były równoważne.

Amazon kładzie nacisk na egzekwowanie zasad w swoim zarządzanym środowisku przeglądarkowym. Deweloperzy korzystający z Bedrock AgentCore mogą stosować zasady Chrome Enterprise ograniczające miejsca, po których agent może się poruszać. Reguły te działają na poziomie przeglądarki, niezależnie od promptu lub rozumowania agenta.

To rozróżnienie jest ważne. Model może zostać zmanipulowany, ale deterministyczna polityka sieciowa lub przeglądarkowa nadal zablokuje zabroniony cel. Mechanizmy kontroli zasad przeglądarki Amazon pozwalają twórcom definiować dozwolone i blokowane lokalizacje, zanim agent rozpocznie pracę.

Lista dozwolonych zasobów może znacząco ograniczyć ekspozycję w przypadku wąskich przepływów pracy w przedsiębiorstwie. Agent zakupowy może potrzebować dostępu do niewielkiego zestawu zatwierdzonych portali dostawców. Agent obsługi klienta może wymagać jedynie platformy wsparcia i wewnętrznego systemu wiedzy.

Granice te stają się trudniejsze do utrzymania w przypadku ogólnych badań. Agent, którego zadaniem jest porównywanie produktów lub śledzenie wiadomości, potrzebuje szerokiego dostępu do sieci. Im bardziej otwarte zadanie, tym mniej użyteczna staje się ścisła lista dozwolonych miejsc docelowych.

Izolacja zapewnia kolejną warstwę ochrony. Zarządzana sesja przeglądarki może oddzielić aktywność agenta od codziennego profilu przeglądarki pracownika. Jeśli agent zostanie przejęty, nie powinien automatycznie dziedziczyć każdego pliku cookie, otwartej karty, zapisanych danych uwierzytelniających i rozszerzenia dostępnego użytkownikowi.

Izolacja nie rozstrzyga, czy instrukcja jest złośliwa. Ogranicza zasoby dostępne po podjęciu błędnej decyzji. To ta sama praktyczna logika, która stoi za kontenerami, maszynami wirtualnymi i ograniczonymi kontami usługowymi.

Zasada najmniejszych uprawnień rozszerza to podejście na narzędzia i dane. Agent, który potrzebuje jedynie odczytywać publiczne strony, nie powinien otrzymywać uprawnień do wysyłania e-maili. Agent przygotowujący transakcję nie powinien mieć możliwości jej zatwierdzenia. Agent czytający dokumenty nie powinien automatycznie uzyskiwać dostępu do każdego podłączonego folderu.

Ścieżki ochrony Amazon i Google zbiegają się zatem wokół wspólnej zasady. Modele pozostaną omylne, więc zabezpieczenia muszą istnieć poza modelem. Polityki przeglądarki, granice tożsamości, bramki zatwierdzania, rejestrowanie zdarzeń i izolowane sesje mogą ograniczyć błąd, którego nie udało się zatrzymać mechanizmom wykrywania.

Rzeczywistym kompromisem jest zdolność działania kontra ograniczanie skutków

Każda ochrona, która niezawodnie zmniejsza skutki prompt injection, ogranicza też część autonomii agenta.

Agent przeglądarkowy staje się bardziej użyteczny, gdy może swobodnie przechodzić między usługami, pamiętać kontekst i realizować wieloetapowe zadania. Te same możliwości zwiększają liczbę decyzji, na które może wpłynąć atakujący. Kompromis bezpieczeństwa jest wpisany w propozycję wartości produktu.

Rozważmy agenta, którego zadaniem jest organizacja podróży. Może wyszukiwać loty, porównywać hotele, sprawdzać kalendarz, pobierać informacje o programie lojalnościowym i przygotowywać rezerwację. Jeśli zewnętrzna treść przekieruje plan, agent może ujawnić dane osobowe lub wybrać miejsce docelowe kontrolowane przez atakującego.

Ściśle ograniczony system mógłby zapobiec takiemu wynikowi, ograniczając agenta do wyszukiwania tylko do odczytu. Nie byłby jednak w stanie sfinalizować rezerwacji. Dodanie uprawnień do zakupów przywraca wygodę, lecz zwiększa skutki błędnego działania.

Ten sam schemat występuje w firmach. Agent sprzedażowy może badać konto klienta i przygotowywać wiadomości bez dużego ryzyka. Przyznanie mu uprawnień do wysyłania wiadomości, aktualizowania danych klientów i dołączania wewnętrznych dokumentów tworzy bardziej wartościową automatyzację oraz większy promień rażenia awarii.

Dlatego prompt injection należy oceniać jako problem bezpieczeństwa możliwości działania. Zespoły powinny pytać, co agent może zrobić po zaakceptowaniu złośliwej instrukcji. Wskaźnik powodzenia ataków na model ma znaczenie, ale ważniejsze są dopuszczalne konsekwencje.

Podsumowujący agent działający tylko do odczytu stwarza inne ryzyko niż agent połączony z systemami płatniczymi. Oba mogą generować wprowadzające w błąd wyniki. Tylko jeden może zamienić błędną interpretację w zewnętrzną transakcję bez dodatkowej kontroli.

Dostawcy czasem promują wyższe wskaźniki wykrywania jako dowód większego bezpieczeństwa. Wyniki te mogą być wartościowe, ale zależą od zestawu testowego, wiedzy atakującego, wersji modelu i dozwolonych narzędzi. Adaptacyjny atak może celować w przypadki, których benchmark nie uwzględniał.

Fałszywie dodatnie wyniki również generują koszty operacyjne. Model defensywny może odrzucić prawidłową treść, która przypomina próbę wstrzyknięcia instrukcji. Zespoły bezpieczeństwa mogą ograniczać przeoczenia przez zwiększenie czułości, lecz użytkownicy napotkają wtedy więcej zablokowanych zadań i niepotrzebnych potwierdzeń.

Problem projektowy nie ma stałego punktu końcowego, ponieważ możliwości agentów stale się zmieniają. Zabezpieczenie przetestowane pod kątem podsumowywania stron nie obejmuje automatycznie nawigacji wizualnej, pobierania plików, okien dialogowych systemu operacyjnego ani interakcji z nowym protokołem narzędziowym.

Aktualizacje przeglądarki mogą wprowadzać dodatkowe zachowania. Aktualizacje modelu mogą zmieniać sposób interpretowania przez agenta niejednoznacznych instrukcji. Podłączona usługa może udostępnić nowe działania, choć dostawca przeglądarki nie kontroluje jej interfejsu. Testy bezpieczeństwa muszą obejmować cały system, a nie pojedynczy migawkowy stan modelu.

Rozszerzenia i integracje firm trzecich dodatkowo komplikują obraz. Mogą rozszerzać treść widoczną dla agenta lub zapewniać nowe ścieżki wykonania. Przedsiębiorstwo może starannie skonfigurować główną przeglądarkę, a jednocześnie przeoczyć rozszerzenie z szerokim dostępem do stron.

Sceptyczne podejście jest więc konieczne. Wielowarstwowe zabezpieczenia zmniejszają ryzyko, ale publicznych twierdzeń o „bezpiecznych agentach” nie należy interpretować jako gwarancji odporności. Firmy powinny ujawniać testowane środowisko, blokowane działania, zasady potwierdzeń użytkownika oraz pozostałą powierzchnię ataku.

Jednocześnie kategoryczne uznawanie każdej przeglądarki AI za niebezpieczną nadmiernie upraszcza decyzję. Ryzyko zależy od uprawnień agenta, dostępnych danych, izolacji i zadania. Ograniczony asystent badawczy może pasować do środowiska o niższym ryzyku, nawet gdy agent zakupowy nie może.

Zespoły bezpieczeństwa potrzebują klas wdrożeń, a nie jednej szerokiej zgody. Agenci niskiego ryzyka mogą działać w izolowanych sesjach tylko do odczytu. Systemy średniego ryzyka mogą przygotowywać działania do oceny przez człowieka. Przepływy pracy wysokiego ryzyka powinny wymagać deterministycznego upoważnienia poza modelem.

Taka struktura akceptuje podstawowy kompromis, zamiast udawać, że zniknął. Użytkownicy nadal zyskują automatyzację, ale autonomia rośnie tylko wtedy, gdy otaczające kontrole potrafią wchłonąć awarię modelu.

Kto odczuwa presję związaną z problemem prompt injection

Dostawcy przeglądarek trafiają na nagłówki, ale zespoły odpowiedzialne za tożsamość korporacyjną i aplikacje ponoszą znaczną część praktycznego ciężaru.

Google musi chronić użytkowników, których profile przeglądarki już zawierają wartościowe sesje. Chrome może połączyć agenta z pocztą e-mail, kalendarzami, dokumentami, kontami zakupowymi i narzędziami służbowymi. Pojedynczy interfejs może więc ujawnić wiele różnych domen zaufania.

Klienci Amazon mierzą się z inną odpowiedzialnością. Bedrock AgentCore zapewnia zarządzane komponenty i mechanizmy kontroli, ale to deweloperzy nadal decydują, do których miejsc docelowych, tożsamości, narzędzi i danych agent może uzyskać dostęp. Bezpieczna usługa może wspierać niebezpieczną konfigurację aplikacji.

Microsoft, OpenAI, Anthropic i Perplexity mierzą się z tą samą presją konkurencyjną. Użytkownicy oczekują, że agenci przeglądarkowi będą obsługiwać więcej pracy, podczas gdy badacze bezpieczeństwa testują każdą nową funkcję. Ograniczające rozwiązanie może sprawiać wrażenie mniej użytecznego obok konkurenta oferującego szerszą automatyzację.

Ten cykl konkurencyjny może zachęcać dostawców do rozszerzania uprawnień szybciej, niż przedsiębiorstwa aktualizują zasady zarządzania. Nowe funkcje agentowe mogą trafiać do znanych przeglądarek i narzędzi zwiększających produktywność, omijając przegląd zakupowy wymagany dla odrębnej aplikacji.

Zespoły bezpieczeństwa powinny inwentaryzować funkcje agentowe jako możliwości, a nie nazwy produktów. Istotne pytania dotyczą dostępu do uwierzytelnionych sesji, lokalnych plików, podłączonych aplikacji, pamięci, komunikacji, pobierania plików i wykonywania kodu.

Właściciele aplikacji muszą także ponownie rozważyć treść stron internetowych. Wewnętrzny pulpit był wcześniej projektowany przede wszystkim dla ludzkich odbiorców. Jeśli agenci traktują jego tekst zarówno jako informację, jak i potencjalną instrukcję, pochodzenie treści staje się częścią bezpieczeństwa aplikacji.

Zespoły odpowiedzialne za tożsamość muszą zdecydować, czy agenci współdzielą ludzkie poświadczenia, czy otrzymują odrębne tożsamości usługowe. Współdzielone sesje są wygodne, ale osłabiają rozliczalność. Oddzielne tożsamości wspierają ściślejsze uprawnienia, czytelniejsze logi i szybsze cofanie dostępu.

Deweloperzy potrzebują rejestrów zdarzeń wyjaśniających, co agent zobaczył i dlaczego podjął działanie. Konwencjonalna historia przeglądarki pokazuje odwiedzone strony, ale może nie rejestrować dokładnej treści, decyzji modelu, wywołania narzędzia i upoważnienia stojących za działaniem agenta.

Zespoły reagowania na incydenty napotykają kolejną trudność. Udane prompt injection może przypominać zwykłą aktywność użytkownika, ponieważ agent korzysta z prawidłowych poświadczeń i legalnych funkcji przeglądarki. Wykrywanie musi analizować intencję, sekwencję, miejsce docelowe i przepływ danych.

Pracownicy również potrzebują wyraźniejszych sygnałów. Powinni wiedzieć, kiedy agent czyta stronę, przechodzi do innej usługi, uzyskuje dostęp do prywatnych informacji lub przygotowuje nieodwracalne działanie. Mała animowana ikona nie komunikuje pełnego przejścia między poziomami zaufania.

Nabywcy korporacyjni powinni pytać dostawców, jak działają zabezpieczenia, gdy treść jest wizualna, zaciemniona, wielojęzyczna lub rozłożona na kilka etapów. Powinni także pytać, czy kontrole bezpieczeństwa działają niezależnie od głównego agenta oraz czy zasady pozostają egzekwowalne po zmianach modelu.

Najsilniejsza ocena obejmuje testy adversarialne względem rzeczywistych przepływów pracy organizacji. Ogólny benchmark nie może odtworzyć każdej wewnętrznej aplikacji, źródła danych i kombinacji uprawnień. Zespoły red team powinny testować realistyczne cele, zmieniając jednocześnie złośliwą treść.

Umowy zakupowe również potrzebują jasnych warunków dotyczących incydentów. Kupujący powinni rozumieć okres przechowywania logów, ujawnianie podatności, praktyki aktualizacji modeli oraz odpowiedzialność za niebezpieczne konfiguracje. Prompt injection przekracza granice między zachowaniem dostawcy a projektem klienta.

Żadna firma nie rozwiąże tego problemu współdzielonej odpowiedzialności samą aktualizacją modelu. Dostawcy muszą zapewnić egzekwowalne kontrole, a klienci muszą skonfigurować je wokół konkretnych zadań. Obie strony potrzebują dowodów, że kontrole działają razem.

Co dalej obserwować u Amazon, Google i dostawców przeglądarek AI

Kolejna faza będzie oceniana na podstawie dowodów ograniczania skutków, a nie obietnic wyeliminowania prompt injection.

Pierwszym sygnałem będzie to, czy dostawcy opublikują odtwarzalne oceny obejmujące kompletne przepływy pracy w przeglądarce. Testy powinny uwzględniać ukryty tekst strony, obrazy, działania między kartami, zapisaną pamięć, podłączone konta i wieloetapową manipulację intencją. Pojedynczy benchmark odmowy zapewnia zbyt wąski obraz.

Wyniki powinny oddzielać wykrywanie od skutków. Atak, który wpływa na podsumowanie, różni się od ataku wysyłającego dane lub finalizującego zakup. Kupujący muszą wiedzieć zarówno, jak często agent podąża za wrogą treścią, jak i jakie kontrole zatrzymują wynikające z tego działanie.

Drugim sygnałem będzie szersze wykorzystanie deterministycznych ograniczeń. Polityki przeglądarki Amazon stanowią jeden przykład, ponieważ mogą blokować miejsca docelowe niezależnie od rozumowania modelu. Kontrole działań Google i bramki uprawnień pełnią podobną rolę w obszarze zgodności z intencją użytkownika.

Warto obserwować, czy te kontrole staną się łatwiejsze do granularnej konfiguracji. Przedsiębiorstwa potrzebują zasad opartych na miejscu docelowym, wrażliwości danych, typie działania, tożsamości i zadaniu. Pojedynczy przełącznik włącz/wyłącz dla całej przeglądarki nie może odzwierciedlić tych różnic.

Trzecim sygnałem będzie sposób, w jaki dostawcy reagują na nowo ujawniane łańcuchy ataków. Szybkie poprawki pozostają ważne, nawet gdy klasa podatności nadal istnieje. Informacje o wydaniach powinny wyjaśniać, czy poprawka zmienia wykrywanie, zakres uprawnień, izolację czy podstawową architekturę agenta.

Badacze nadal będą znajdować warianty, ponieważ zachowanie agentów jest niedeterministyczne. Poprawka blokująca jedną frazę lub wzorzec strony internetowej nie rozwiązuje problemu kolizji intencji w różnych kontekstach. Trwałe ulepszenia powinny usuwać możliwości z niezaufanych ścieżek lub dodawać niezależne upoważnienie.

Zgłoszony przez Google wzrost złośliwych wzorców w sieci nadaje tej pracy pilności. Wyrafinowanie ataków było nadal ograniczone w skanie firmy, ale zwiększona aktywność daje atakującym więcej możliwości testowania wdrożonych produktów. Szersze wdrażanie agentów przeglądarkowych zwiększa wartość skutecznych technik.

Konkurencja Amazon i Google ujawni również, jakie kompromisy bezpieczeństwa akceptują użytkownicy. Google może umieszczać potwierdzenia bezpośrednio w Chrome, gdzie widzą je indywidualni użytkownicy. Amazon może oferować deweloperom polityki infrastrukturalne, lecz każdy klient musi zdecydować, jak restrykcyjne powinny być te zasady.

W przypadku wdrożeń korporacyjnych standard krótkoterminowy powinien być prosty. Izoluj agenta, nadaj mu odrębną tożsamość, ogranicz miejsca docelowe, minimalizuj narzędzia i wymagaj zatwierdzenia przed działaniami o istotnych konsekwencjach. Rejestruj każde przejście między niezaufaną treścią a uprzywilejowanym zachowaniem.

Pracownicy umysłowi powinni, gdy to możliwe, trzymać wrażliwe konta poza eksperymentalnymi sesjami agentów. Powinni też sprawdzać proponowane wiadomości, transakcje, pobierane pliki i transfery danych. Aktualizowanie przeglądarki ma znaczenie, ale nie usuwa podstawowego problemu z interpretacją.

Deweloperzy powinni traktować każdą stronę internetową, wiadomość e-mail, przesłany dokument i pobraną notatkę jako niezaufane dane wejściowe. Powinni zakładać, że model podstawowy w końcu błędnie sklasyfikuje część z nich. Mechanizmy kontrolne działające poza tym modelem muszą decydować o tym, co wydarzy się dalej.

Wniosek, że nie istnieje idealne rozwiązanie, jest niewygodny, ponieważ zmienia pytanie dotyczące wdrożenia. Zespoły powinny przestać pytać, czy agent przeglądarkowy jest odporny na prompt injection. Powinny pytać, czy jedno udane wstrzyknięcie może dotrzeć do czegokolwiek istotnego.

Przed włączeniem kolejnej autonomicznej funkcji określ jej najgorsze dozwolone działanie i zdecyduj, czy korzyść uzasadnia takie ryzyko. Jeśli odpowiedź nie jest jasna, pozostaw agenta w trybie tylko do odczytu lub wymagaj zatwierdzenia przez człowieka. Rywalizacja Amazon i Google przyniesie lepsze zabezpieczenia, ale odpowiedzialne wdrażanie nadal zależy od ograniczania skutków.