Przejęcie bez kliknięcia ujawnia kluczowe ryzyko bezpieczeństwa w przeglądarkach AI

Google News zwróciło uwagę na ostrzeżenie, że przeglądarki AI mogą zostać przejęte bez kliknięcia, zatwierdzenia czy świadomego otwarcia złośliwego polecenia przez ofiarę. Badacze bezpieczeństwa twierdzą, że spreparowana treść może przekierować agenta podczas wykonywania zwykłego zadania. Ta sama automatyzacja, która oszczędza czas, może następnie ujawnić pliki, poświadczenia, wiadomości lub uwierzytelnione konta.

Badania koncentrują się na PleaseFix, klasie podatności przedstawionej przez Zenity Labs w marcu 2026 roku i rozwiniętej podczas Black Hat USA. W odróżnieniu od tradycyjnej inżynierii społecznej atak jest wymierzony w oprogramowanie działające w imieniu użytkownika. Zaproszenie kalendarzowe, post w mediach społecznościowych, strona internetowa lub formularz newslettera mogą stać się kanałem instrukcji.

Tworzy to konflikt, którego producenci przeglądarek nie mogą zbyć jako kolejnego odizolowanego błędu. Przeglądarki AI potrzebują szerokiego dostępu, aby wykonywać użyteczne zadania w różnych witrynach. Dostęp ten staje się niebezpieczny, gdy agent nie potrafi niezawodnie oddzielić celu użytkownika od instrukcji umieszczonych w niezaufanej treści.

Dark Reading poinformował, że badacze Zenity znaleźli ścieżki ataku w głównych projektach przeglądarek agentowych, w tym w produktach powiązanych z OpenAI, Google, Anthropic, Microsoft i Perplexity. Kluczowe pytanie nie brzmi już, czy jeden produkt wymaga poprawki. Chodzi o to, czy autonomiczne przeglądanie sieci może zachować znane granice bezpieczeństwa Webu, działając jednocześnie z uprawnieniami użytkownika.

PleaseFix zmienia zwykłą treść w wyzwalacz ataku

PleaseFix przenosi inżynierię społeczną z przekonywania człowieka na przekierowywanie agenta, który już dysponuje jego uprawnieniami.

Tradycyjne ataki ClickFix nakłaniają użytkowników do wykonania niebezpiecznego działania, często poprzez skopiowanie polecenia lub zatwierdzenie podejrzanego komunikatu. PleaseFix usuwa to ludzkie wąskie gardło. Atakujący umieszcza zamiast tego instrukcje tam, gdzie przeglądarka AI napotka je podczas normalnego procesu pracy.

Zenity po raz pierwszy ujawniło PleaseFix 3 marca 2026 roku. Jego badacze zademonstrowali dwie ścieżki wykorzystania podatności związane z Perplexity Comet. Jedna mogła wykorzystać zaproszenie kalendarzowe, aby skierować agenta przeglądarki do lokalnych plików i wysłać ich zawartość do miejsca kontrolowanego przez atakującego.

Druga ścieżka była wymierzona w procesy pracy z menedżerami haseł. Według Zenity atakujący nie musiał bezpośrednio wykorzystywać menedżera haseł. Złośliwa treść przekierowywała agenta przeglądarki, gdy działał on w ramach uwierzytelnionej sesji.

Perplexity naprawiło podstawowy problem po stronie przeglądarki przed publicznym ujawnieniem. Zenity podało, że 1Password potwierdził, iż pierwotna przyczyna nie leżała w jego menedżerze haseł. To rozróżnienie ma znaczenie, ponieważ agent działał jako upoważniony pośrednik między skądinąd legalnymi systemami.

Technicznie jest to pośrednie wstrzyknięcie promptu. Dochodzi do niego, gdy model AI traktuje niezaufane dane jako instrukcję, choć użytkownik nigdy takiej instrukcji nie wydał. Złośliwy tekst może znajdować się na stronie internetowej, w e-mailu, dokumencie lub wydarzeniu kalendarzowym.

Atak może pozostać ukryty, gdy agent wykonuje widoczne zadanie. Użytkownik może poprosić przeglądarkę AI o zaakceptowanie zaproszenia lub podsumowanie strony. Agent może zwrócić oczekiwaną odpowiedź, jednocześnie wykonując dodatkową czynność wybraną przez atakującego.

Współzałożyciel i CTO Zenity Michael Bargury opisał tę wadę jako porażkę zaufania do agenta, a nie jedynie wadliwy menedżer haseł lub stronę internetową. Badanie PleaseFix firmy wskazuje, że wstrzyknięta instrukcja dziedziczy wszelki dostęp przyznany agentowi przez użytkownika.

Ten odziedziczony dostęp zmienia skalę skutków. Przejęta strona internetowa zwykle działa w ramach ograniczeń przeglądarki. Przejęty agent może przechodzić między kartami, odczytywać połączone usługi, wpisywać tekst, klikać kontrolki i wywoływać inne narzędzia.

Podczas Black Hat badacze rozszerzyli ustalenia poza pierwotne demonstracje Comet. Opisali technikę zwaną kolizją intencji. Pozwala ona uniknąć bezpośredniego nakazywania agentowi porzucenia żądania użytkownika.

Zamiast tego złośliwa treść dostarcza fałszywą definicję tego, jak żądanie powinno zostać wykonane. Jeśli użytkownik prosi o zapisanie się do newslettera, atak może powiedzieć agentowi, że niezwiązane z tym złośliwe działanie jest częścią rejestracji.

Agent nadal sprawia wrażenie zgodnego z pierwotnym zadaniem. Po prostu zaakceptował kontrolowaną przez atakującego ścieżkę prowadzącą do jego realizacji. To ogranicza skuteczność prostych kontroli wykrywających instrukcje, które są w oczywisty sposób sprzeczne.

Lipiecowe doniesienia Dark Reading wskazywały, że Zenity znalazło istotnie różne projekty i gwarancje bezpieczeństwa w przeglądarkach agentowych. Mimo to badacze stwierdzili, że każdy produkt udostępniał jakąś drogę ataku. Ten wzorzec przekształca przejęcie agenta bez kliknięcia w problem całej kategorii.

Pojedyncza poprawka może zamknąć zademonstrowany łańcuch ataku. Nie usuwa jednak podstawowej kolizji między niezaufaną treścią, autonomicznymi decyzjami i uwierzytelnionym dostępem.

Dlaczego przeglądarki AI wywierają presję na znane granice Webu

Przeglądarka AI zyskuje użyteczność, przekraczając granice, których egzekwowaniu konwencjonalne przeglądarki poświęciły dekady.

Jedną z takich granic jest polityka same-origin. Zasadniczo uniemożliwia ona treści z jednej witryny odczytywanie lub manipulowanie treścią należącą do innej. Złośliwa strona nie powinna uzyskać dostępu do otwartej sesji bankowej, e-mailowej ani służbowej.

Agenci przeglądarkowi komplikują ten model, ponieważ aktywność między witrynami stanowi część ich celu. Zadanie związane z podróżą może wymagać odczytania strony rezerwacyjnej, porównania map, otwarcia e-maila, wprowadzenia danych płatniczych i aktualizacji kalendarza. Agent potrzebuje szerszej widoczności niż otrzymuje pojedyncza strona internetowa.

Badacze z University of Washington przetestowali siedem przeglądarek agentowych na początku 2026 roku. Ich badanie same-origin objęło Brave Leo AI, ChatGPT Atlas, Chrome with Gemini, Claude for Chrome, Microsoft Edge with Copilot, Firefox AI Mode i Perplexity Comet.

Zespół zademonstrował pełny atak kradzieży danych między źródłami przeciwko ChatGPT Atlas w Agent Mode. Badacze znaleźli również warunki dla powiązanych ataków w Chrome with Gemini, Claude for Chrome i Perplexity Comet, jeśli wstrzyknięcie promptu zakończyło się powodzeniem.

W dowodzie koncepcji złośliwa strona osadziła treść z innego źródła. Wstrzyknięta instrukcja skierowała agenta do odczytania tej treści i umieszczenia jej w formularzu, który został automatycznie przesłany. Agent stał się pomostem, którego zwykły kod przeglądarki nie mógł utworzyć.

Badacze nie twierdzili, że każdy testowany produkt był podatny na ten sam pełny exploit. Ich ustalenie miało bardziej strukturalny charakter. Kilka projektów sprowadzało skuteczność polityki same-origin do skuteczności ochrony przed wstrzyknięciem promptu.

To wymagająca zależność. Wstrzyknięcie promptu nie jest tradycyjną sygnaturą, którą obrońcy mogą niezawodnie zablokować raz na zawsze. Atakujący mogą przeformułować instrukcję, ukryć ją w treści wizualnej, podzielić między elementy lub przedstawić jako część zadania.

Człowiek może zignorować słabo widoczny tekst lub niedostępne metadane strony. Agent multimodalny może wydobyć te informacje i na ich podstawie działać. Cloud Security Alliance zauważa, że badacze zademonstrowali instrukcje w kolorach, które ludzie z trudem dostrzegają, lecz systemy AI nadal mogą je odczytać.

Pamięć tworzy kolejny problem z granicami. Agenci mogą kompresować wcześniejszą aktywność do podsumowań wpływających na późniejsze zachowanie. Jeśli wroga treść trafi do tej pamięci, jej pierwotne źródło może stać się mniej widoczne podczas przyszłych decyzji.

LayerX opisał wcześniej Tainted Memories, atak umieszczający złośliwe instrukcje w pamięci ChatGPT Atlas. Inne ujawnione ataki wykorzystywały fragmenty URL, współdzielone dokumenty i ścieżki pobierania po stronie serwera do dostarczania instrukcji adversarialnych.

Metody te różnią się, lecz wykorzystują tę samą niejednoznaczność. Model otrzymuje intencję użytkownika i zewnętrzną treść przez kanały, które nie zapewniają wiarygodnego pochodzenia instrukcji.

Pochodzenie instrukcji oznacza wiedzę o tym, kto dostarczył polecenie i jaką powinno mieć ono rangę uprawnień. Konwencjonalne oprogramowanie może oznaczać kod, dane wejściowe, uprawnienia i procesy za pomocą jawnych struktur technicznych. Modele językowe często otrzymują te elementy jako tekst we wspólnym kontekście.

Przeglądarki AI wywierają więc presję na zespoły bezpieczeństwa w dwóch kierunkach. Ograniczanie dostępu zmniejsza szkody, ale ogranicza też zadania, które agent może ukończyć. Rozszerzanie dostępu usprawnia automatyzację, jednocześnie zwiększając konsekwencje jednej błędnej decyzji.

Zespół University of Washington zauważył, że przeglądarka o najmniejszym ryzyku w jego testach miała również najbardziej ograniczone możliwości. To ustalenie oddaje główny kompromis. Możliwości i ekspozycja są zwiększane przez wiele tych samych decyzji projektowych.

Nagłówki Google News skrywają głębszy problem uprawnień

Nagłówek dotyczy złośliwych promptów, ale większa porażka bezpieczeństwa dotyczy uprawnień, które pozostają aktywne po błędnym odczytaniu przez agenta jednej instrukcji.

Google News może sprawiać, że przejęcie agenta bez kliknięcia wygląda jak kolejna szybko rozwijająca się historia o podatności. Takie ujęcie grozi skupieniem uwagi na sprytnym ładunku zamiast na uprawnieniach dostępnych po jego zadziałaniu.

Asystent AI, który jedynie podsumowuje publiczne strony, ma ograniczony zasięg szkód. Agent mogący czytać e-maile, uzyskiwać dostęp do lokalnych plików, używać zapisanych poświadczeń, wysyłać wiadomości do kontaktów i dokonywać zakupów stwarza inne ryzyko.

Atak nie musi niezależnie przełamywać zabezpieczeń każdej połączonej usługi. Może manipulować agentem, który został już zatwierdzony do ich używania. Legalne uwierzytelnianie staje się częścią łańcucha ataku.

Przypomina to problem confused deputy, w którym zaufany komponent niewłaściwie wykorzystuje swoje uprawnienia na rzecz innej strony. Przeglądarka AI uważa, że służy użytkownikowi, podczas gdy atakujący wpływa na sposób interpretacji celu użytkownika.

PleaseFix demonstruje ten problem za pośrednictwem zwykłej treści. Inne badania rozszerzają go na różne kanały dostarczania. GeminiJack miał podobno wykorzystywać współdzielone dokumenty Google zawierające ukryte instrukcje. HashJack umieszczał instrukcje po symbolu hash w URL, w obszarze, który mechanizmy kontroli sieciowej mogą ignorować.

ZombieAgent był wymierzony w zachowanie związane z pobieraniem danych w agencie AI do badań. CometJacking wykorzystywał spreparowane parametry zapytania i wymagał kliknięcia. Te warianty pokazują, że obrońcy nie mogą zabezpieczać wyłącznie stron internetowych, pozostawiając bez ochrony e-maile, dokumenty, pamięć i odpowiedzi narzędzi.

NIST zdefiniował przejęcie agenta jako formę pośredniego wstrzyknięcia promptu, która powoduje, że agent realizuje cel atakującego. Jego oceny przejęć podkreślają testowanie, czy agenci realizują złośliwe cele ukryte w zasobach, które przetwarzają.

To podejście ewaluacyjne ma znaczenie, ponieważ system może wyglądać na bezpieczny podczas zwykłych zadań testowych. Może również blokować znaną frazę wstrzyknięcia, pozostając podatnym na instrukcję sformułowaną inaczej.

Kolizja intencji utrudnia problem testowania. Wroga treść nie zawsze przeczy żądaniu użytkownika. Może twierdzić, że złośliwy krok jest konieczny do realizacji żądania.

Wąska kontrola zgodności może zobaczyć żądanie rejestracji do newslettera, po którym następują interakcje z formularzem, i uznać, że plan pozostaje istotny. Musi też wykryć, że jedno z proponowanych działań przekracza granicę niezwiązanego źródła, narzędzia lub uprawnienia.

Uprawnienia powinny być zatem przypisane do konkretnego zadania, a nie jedynie do ogólnej tożsamości agenta. Prośba o podsumowanie strony internetowej nie wymaga dostępu do menedżera haseł. Przyjęcie zaproszenia kalendarzowego nie powinno upoważniać do przesyłania lokalnych plików.

Krótkotrwałe uprawnienia ograniczone do zakresu zadania zmniejszyłyby potencjalny zasięg szkód. Tak samo jak wyraźne rozdzielenie dostępu do odczytu i zapisu. Agent mógłby analizować kilka źródeł, nie otrzymując jednocześnie uprawnień do przekazywania ich treści gdzie indziej.

Ta sama zasada dotyczy wdrożeń korporacyjnych. Agent przeglądarkowy połączony z danymi klientów, dokumentami wewnętrznymi, repozytoriami kodu i systemami komunikacji nie powinien otrzymywać jednego, niezróżnicowanego zestawu uprawnień.

Zespoły bezpieczeństwa potrzebują również wglądu w działania agentów. Tradycyjne logi mogą pokazywać uwierzytelnioną sesję użytkownika wykonującą prawidłowe żądania. Mogą jednak nie wskazywać, czy żądania pochodziły od człowieka, planera agenta czy treści o charakterze adversarialnym.

Osłabia to znaną logikę wykrywania zagrożeń. Może nie być skradzionego hasła, podejrzanego pliku wykonywalnego ani nieautoryzowanego logowania. Szkodliwe działanie może nastąpić za pośrednictwem zatwierdzonej przeglądarki na zatwierdzonym urządzeniu.

Dla klientów korporacyjnych kluczowe pytanie produktowe nie brzmi, czy przeglądarka zawiera filtrowanie prompt injection. Nabywcy powinni pytać, jak system ogranicza zakres uprawnień, rejestruje źródła instrukcji, izoluje originy i powstrzymuje nieoczekiwany przepływ danych.

Twórcy przeglądarek budują zabezpieczenia, ale żadne nie eliminuje kompromisu

Wielowarstwowe mechanizmy obronne mogą przerwać znane ścieżki ataku, jednak żadna opublikowana architektura nie usuwa podstawowego napięcia między autonomią a kontrolą.

Google otwarcie wskazuje pośrednie prompt injection jako główne nowe zagrożenie dla przeglądarek agentowych. Proponowane przez firmę mechanizmy ochronne Chrome łączą trenowanie modeli, ograniczenia dotyczące originów, kontrolę działań, wykrywanie zagrożeń oraz potwierdzenia dla krytycznych kroków.

Jednym z komponentów jest User Alignment Critic. Ten odrębny model ocenia planowane działanie i decyduje, czy realizuje ono cel deklarowany przez użytkownika. Google podaje, że krytyk otrzymuje metadane działania, nie widząc nieprzefiltrowanej treści strony internetowej, która wpłynęła na planera.

Takie rozdzielenie zmniejsza prawdopodobieństwo, że ten sam złośliwy tekst zatruje zarówno planera, jak i jego recenzenta. Krytyk może odrzucić działanie niezgodne z celem lub poprosić planera o opracowanie innego planu.

Google opisuje również Agent Origin Sets. Ograniczają one, które strony internetowe agent może odczytywać i które może modyfikować podczas zadania. Zaufana funkcja kontrolna decyduje, czy dany origin należy do żądanego przepływu pracy.

Projekt zmierza w kierunku uprawnień ograniczonych do konkretnego zadania. Nadal jednak musi ustalić, które originy są rzeczywiście istotne. Prośba dotycząca zakupów, podróży lub badań może naturalnie obejmować kilka nieznanych stron.

Atakujący mogą wykorzystać tę niejednoznaczność. Złośliwa strona może przedstawiać inną witrynę jako niezbędną do ukończenia zadania. Znaczenie mają również fałszywie pozytywne wyniki, ponieważ nadmierne blokowanie zmniejsza użyteczność agenta.

OpenAI podobnie traktuje prompt injection jako trwające wyzwanie bezpieczeństwa. Opis prac nad bezpieczeństwem Atlas przedstawia ciągłe red teaming i aktualizacje modeli, a nie ukończoną poprawkę.

Microsoft przyjął ostrożne podejście do działań przeglądarkowych agentów. Publiczne wytyczne firmy opisują ograniczenia dotyczące uruchamiania zewnętrznych aplikacji, wprowadzania poufnych informacji oraz niektórych działań o dużym wpływie. Dostęp eksperymentalny również ogranicza ekspozycję, gdy projekty nadal ewoluują.

Potwierdzenia pozostają cenne, zwłaszcza przed zakupami, wysyłaniem wiadomości, transferami plików lub użyciem poświadczeń. Okno potwierdzenia może jednak zawieść, jeśli przedstawia narrację atakującego zamiast rzeczywistej konsekwencji.

Użytkownicy przyzwyczajają się też do zatwierdzania częstych komunikatów. Autonomiczne narzędzie traci dużą część swojej atrakcyjności, jeśli każdy istotny krok wymaga dokładnej ręcznej kontroli. Mechanizm, który użytkownicy rutynowo akceptują, zapewnia ograniczoną ochronę.

Modele wykrywania uczestniczą w wyścigu z przeciwnikami. Badacze mogą tworzyć nowe sformułowania, kodowania, obrazy i wieloetapowe instrukcje. Detektor wytrenowany na promptach z wczoraj może nie rozpoznać instrukcji wyrażonej poprzez kontekst i sugestię.

Nie oznacza to, że zabezpieczenia są bezcelowe. Kontrole warstwowe zmuszają atakujących do pokonania kilku barier i ograniczają szkody, gdy jedna z nich zawiedzie. Problemem jest traktowanie pojedynczego modelu, polityki lub ostrzeżenia jako wystarczającej granicy bezpieczeństwa.

Sceptyczne spojrzenie również wymaga ostrożności. Szerokie stwierdzenia Zenity opisują klasę podatności i kilka demonstracji, a nie dowodzą, że każdy użytkownik przeglądarki AI został skompromitowany. Dostęp uzyskany w ramach proof of concept nie potwierdza masowego wykorzystywania.

Produkty także szybko się zmieniają. Perplexity rozwiązało problem po stronie przeglądarki ujawniony w marcu, podczas gdy inni dostawcy nadal modyfikują mechanizmy kontroli originów i potwierdzeń. Ustalenie dotyczące jednej wersji nie powinno automatycznie opisywać każdego późniejszego wydania.

Mimo to brak znanego masowego wykorzystania nie rozwiązuje problemu architektonicznego. Przeglądarki AI działają w ramach uwierzytelnionych sesji o wysokiej wartości, a społeczność bezpieczeństwa wielokrotnie znajdowała ścieżki od niezaufanej treści do uprzywilejowanego działania.

Przedsiębiorstwa powinny traktować te produkty jako uprzywilejowaną automatyzację, a nie zwykłe oprogramowanie zwiększające produktywność. Przeglądy wdrożeniowe powinny obejmować te same praktyki, które stosuje się wobec kont usługowych, robotycznej automatyzacji procesów i narzędzi administracyjnych.

Oznacza to ograniczanie połączonych usług, rozdzielanie sesji osobistych i służbowych, wyłączanie niepotrzebnego dostępu do zapisu oraz monitorowanie działań wychodzących. Procesy o dużym wpływie powinny zachować niezależną weryfikację poza własnym interfejsem agenta.

Trzy sygnały pokażą, czy przeglądarki AI stają się bezpieczniejsze

Kolejnym sprawdzianem będzie to, czy dostawcy potrafią ograniczyć uprawnienia agentów, nie redukując autonomicznego przeglądania do nadzorowanego dema.

Pierwszym sygnałem będzie egzekwowanie originów specyficznych dla zadania. Twórcy przeglądarek muszą wykazać, że agenci nie mogą swobodnie przenosić informacji między niepowiązanymi stronami tylko dlatego, że obie pojawiają się w jednej sesji.

Niezależni badacze powinni powtarzać testy między originami po dużych wydaniach. Skuteczna obrona uniemożliwiłaby wstrzykniętej instrukcji dodanie nowego miejsca docelowego, odczytanie niepowiązanej treści lub przesłanie poufnych informacji.

Wzmocniłoby to argument, że przeglądarki AI mogą zachować podstawowe granice Webu. Kolejne dowody kradzieży w formie proof of concept w zaktualizowanych produktach pokazałyby, że kontrola originów nadal zbyt mocno zależy od zawodnych decyzji modelu.

Drugim sygnałem będzie niezależne potwierdzanie działań o istotnych konsekwencjach. Najsilniejszy projekt generowałby informacje do zatwierdzenia na podstawie zaufanych metadanych działania, a nie strony internetowej czy narracji planera.

Użyteczne potwierdzenie powinno wskazywać, jakie dane zostaną przekazane, które miejsce docelowe je otrzyma oraz które konto wykona działanie. Powinno też blokować cichą eskalację z zadania tylko do odczytu do operacji zapisu.

Badacze będą sprawdzać, czy złośliwa treść może maskować, tłumić lub przeformułowywać te ostrzeżenia. Jeśli potwierdzenia konsekwentnie ujawnią rzeczywistą konsekwencję, osłabią ataki oparte na kolizji intencji. Jeśli użytkownicy nadal będą widzieć niejasne komunikaty, ochrona pozostanie krucha.

Trzecim sygnałem będzie przejrzyste raportowanie incydentów i ocen. Dostawcy powinni publikować, które klasy ataków testują, jakie uprawnienia mają ich agenci oraz które działania zawsze wymagają zatwierdzenia przez człowieka.

Same zagregowane wskaźniki skuteczności nie wystarczą. Testy muszą obejmować realistyczne e-maile, zaproszenia kalendarzowe, osadzone ramki, dokumenty, obrazy, komponenty URL, wpisy pamięci oraz odpowiedzi narzędzi. Muszą również uwzględniać ataki wspierające powierzchniowe brzmienie zadania użytkownika.

OWASP zalicza prompt injection do kluczowych zagrożeń dla aplikacji opartych na modelach językowych. Wskazówki dotyczące prompt injection zalecają ograniczanie zachowania modeli, walidację wyników, rozdzielanie zewnętrznej treści oraz stosowanie zasady najmniejszych uprawnień.

Publiczne raportowanie może ujawnić, czy te zasady działają w wdrożonych przeglądarkach. Może także odróżnić postęp architektoniczny od łatania pojedynczych demonstracji.

Użytkownicy nie muszą rezygnować z każdej funkcji przeglądarki AI, dopóki te prace trwają. Powinni dopasować uprawnienia agenta do wrażliwości zadania.

Podsumowywanie publicznych badań wiąże się z mniejszym ryzykiem niż działanie w ramach sesji e-mail, bankowości, pamięci masowej w chmurze czy zarządzania hasłami. Oddzielne profile przeglądarki mogą ograniczyć ekspozycję, choć nie naprawią niebezpiecznego projektu agenta.

Organizacje powinny zaczynać od kont o ograniczonych uprawnieniach i niekrytycznych procesów. Powinny uniemożliwiać agentom dostęp do poświadczeń lub lokalnych plików, chyba że konkretnie zatwierdzone zadanie wymaga takiego dostępu.

Zespoły bezpieczeństwa powinny także zakładać, że treść może być wroga, nawet gdy usługa ją hostująca jest zaufana. Współdzielony dokument, wydarzenie w kalendarzu, reklama, zgłoszenie wsparcia lub wiadomość wewnętrzna mogą zawierać instrukcje kontrolowane przez atakującego.

Google News będzie nadal prezentować pojedyncze odkrycia, gdy badacze testują nowe produkty. Czytelnicy powinni patrzeć poza nazwę każdego produktu i pytać, czy agent potrafił odróżnić zweryfikowaną intencję od niezaufanej treści.

Rozstrzygające dowody przyniosą powtarzalne, niezależne testy. Czy zaktualizowany agent potrafi odrzucić wrogą treść, pozostać w obrębie originów specyficznych dla zadania i ujawnić każde działanie o istotnych konsekwencjach przed jego wykonaniem?

Dopóki dostawcy nie będą mogli konsekwentnie odpowiedzieć na te pytania, przejęcie agenta bez kliknięcia pozostanie czymś więcej niż tymczasowym cyklem błędów. Jest kosztem przyznawania oprogramowaniu szerokich uprawnień, zanim otrzyma ono niezawodny sposób rozpoznawania, kto wydaje polecenie.