PleaseFix: jak sama treść strony może przejąć agenta AI w przeglądarce bez kliknięcia

Agent AI w przeglądarce nie musi dostać złośliwego pliku, nie musi uruchomić podejrzanego skryptu i nie potrzebuje kliknięcia użytkownika. Wystarczy, że przeczyta treść przygotowaną przez atakującego i uzna ją za instrukcję, którą należy wykonać. Na tym polega problem pokazany przez rodzinę ataków PleaseFix: warstwa treści, która w zwykłej przeglądarce jest tylko informacją, w przeglądarce agentowej może zacząć sterować działaniem automatu.

PleaseFix został publicznie ujawniony przez Zenity Labs 3 marca 2026 r. Badacze opisali nie pojedynczy błąd programistyczny, lecz klasę ataków wykorzystujących indirect prompt injection, czyli pośrednie wstrzyknięcie instrukcji do modelu. Szczególnie dobrze problem było widać na przykładzie Perplexity Comet, ale późniejsze demonstracje Zenity objęły również rozwiązania agentowe powiązane m.in. z Chrome, Edge i ChatGPT Atlas. Problem jest więc szerszy niż jedna przeglądarka czy jeden model AI.

Najważniejsza zmiana względem klasycznego phishingu jest prosta: ofiarą manipulacji nie musi być człowiek. Treść próbuje przekonać do działania agenta, który już ma dostęp do zalogowanych usług, dokumentów i funkcji przeglądarki.

Zero-click nie oznacza „magicznego włamania”. Oznacza brak decyzji użytkownika

Określenie zero-click bywa mylące, bo sugeruje atak działający natychmiast po przypadkowym wejściu na dowolną stronę. Mechanizm PleaseFix jest bardziej konkretny. Złośliwa instrukcja musi znaleźć się w treści, którą agent rzeczywiście przetwarza w ramach zadania. Może to być strona WWW, wiadomość, dokument albo zaproszenie kalendarzowe.

Przykładowy scenariusz wygląda tak:

• atakujący umieszcza spreparowaną instrukcję w treści dostępnej dla agenta;

• użytkownik zleca agentowi normalne zadanie, np. obsługę kalendarza, przeczytanie wiadomości albo zebranie informacji;

• agent pobiera treść razem ze złośliwą instrukcją;

• model nie rozpoznaje wystarczająco pewnie, że fragment pochodzi od niezaufanego autora;

• instrukcja zaczyna wpływać na plan działania agenta;

• agent wykorzystuje posiadane już uprawnienia, nadal zachowując się z punktu widzenia użytkownika jak zwykły asystent.

W demonstracji dotyczącej Perplexity Comet spreparowane zaproszenie kalendarzowe mogło przekierować agenta na kontrolowaną przez atakującego stronę, a następnie skłonić go do sięgnięcia do lokalnego systemu plików. Dane mogły zostać wyprowadzone przy okazji zwykłego ładowania strony, podczas gdy agent nadal wykonywał zadanie, o które poprosił użytkownik.

To istotna różnica wobec popularnych kampanii ClickFix. Tam człowiek widzi fałszywy komunikat w rodzaju „napraw błąd”, kopiuje polecenie do terminala albo uruchamia wskazaną operację. PleaseFix usuwa z tego procesu człowieka. „Prośba” trafia bezpośrednio do agenta.

Najbardziej niebezpieczny jest przy tym nie sam prompt. Tekst nie zdobywa dostępu do plików czy kont w sposób podobny do klasycznej luki RCE. Problem powstaje dlatego, że agent posiada już legalne możliwości wykonywania działań w imieniu użytkownika.

Jeżeli asystent potrafi wyłącznie streścić otwartą kartę, skutki udanego wstrzyknięcia instrukcji są ograniczone. Jeżeli może równocześnie:

• korzystać z aktywnej sesji Gmaila,

• otwierać Google Drive,

• obsługiwać kalendarz,

• wchodzić w interakcję z menedżerem haseł,

• wysyłać wiadomości,

• otwierać nowe strony,

• korzystać z lokalnych narzędzi,

ten sam błąd interpretacji treści otrzymuje zupełnie inny blast radius, czyli możliwy zakres szkód.

I właśnie tutaj podejście „przecież użytkownik niczego nie kliknął” przestaje uspokajać. Brak kliknięcia oznacza jedynie, że punkt kontrolny, do którego przyzwyczaiły nas klasyczne przeglądarki, w ogóle nie wystąpił.

Największy problem: agent miesza polecenie użytkownika z danymi, które dopiero odczytał

W tradycyjnej aplikacji rozdzielenie kodu od danych jest jednym z fundamentów bezpieczeństwa. Agent oparty na dużym modelu językowym pracuje inaczej. Dostaje polecenie użytkownika, opis aktualnego stanu, treść stron i dokumentów, a następnie musi ustalić, co z tego jest instrukcją, a co materiałem do analizy.

To właśnie ten punkt wykorzystuje indirect prompt injection.

Załóżmy, że użytkownik wydaje proste polecenie:

„Przejrzyj dzisiejsze zaproszenia i zaakceptuj spotkania związane z projektem.”

Jedno z zaproszeń zawiera jednak tekst przeznaczony dla modelu: polecenie zmiany zadania, wejścia na inną stronę albo pobrania określonych danych. Dla człowieka taki tekst może być ukryty, mało widoczny albo przedstawiony jako nieistotny fragment. Agent nie musi postrzegać strony tak samo jak użytkownik. Może analizować DOM, tekst dostępności, metadane albo inne reprezentacje dokumentu.

Sednem ataku nie jest więc „niewidzialny napis”. Nawet całkowicie widoczna treść może być niebezpieczna, jeżeli agent nada jej autorytet, którego nie powinna mieć.

Cloud Security Alliance wskazuje w analizie PleaseFix dwa podstawowe problemy architektoniczne. Pierwszy to brak niezawodnego mechanizmu określającego pochodzenie instrukcji. System powinien wiedzieć, że polecenie właściciela konta ma inny poziom zaufania niż tekst napisany przez autora odwiedzonej strony. Drugi problem to zbyt szerokie, odziedziczone uprawnienia agenta, np. stały dostęp do poczty, dysku i innych usług.

To dlatego prosty filtr wyszukujący frazy typu „ignore previous instructions” nie rozwiązuje sprawy. Atakujący nie musi używać charakterystycznego zwrotu. Instrukcję można napisać na setki sposobów, rozbić na kilka elementów, dostosować do kontekstu strony albo przedstawić jako element zadania, które agent właśnie realizuje.

Drugi kłopot to walka z objawem zamiast z modelem uprawnień. Po ujawnieniu jednego z wariantów PerplexedBrowser Perplexity zablokował agentowi dostęp do adresów file://. Zenity opisało następnie obejścia wykorzystujące m.in. view-source:file:// oraz odpowiednio skonstruowane sufiksy fragmentu URL. Pokazuje to, dlaczego blokowanie pojedynczego schematu adresu jest potrzebne, ale samo w sobie nie stanowi pełnego rozwiązania problemu zaufania.

W praktyce przy ocenie przeglądarki agentowej ważniejsze od marketingowej deklaracji „AI chronione przed prompt injection” są cztery pytania:

• Czy treść strony może bezpośrednio zmieniać plan wykonania zadania?

• Czy agent przed operacją wysokiego ryzyka ponownie potwierdza intencję użytkownika?

• Czy dostęp jest ograniczany do minimum potrzebnego w danym zadaniu, czy agent stale dziedziczy szerokie uprawnienia?

• Czy administrator potrafi później odtworzyć, jaka treść wywołała daną akcję i jakie dane agent odczytał?

Jeżeli odpowiedź na dwa ostatnie pytania brzmi „nie”, sam dobry model językowy nie powinien być traktowany jako granica bezpieczeństwa.

Co faktycznie ogranicza ryzyko PleaseFix — i dlaczego samo ostrzeżenie w promptcie nie wystarczy

Najrozsądniejsza obrona zaczyna się od ograniczenia skutków udanego wstrzyknięcia, a nie od założenia, że każde wstrzyknięcie uda się wykryć.

W firmowej przeglądarce agentowej agent nie powinien domyślnie otrzymywać jednocześnie dostępu do poczty, całego Dysku Google, systemu CRM, komunikatora i narzędzi lokalnych tylko dlatego, że czasem potrzebuje każdej z tych usług. Z punktu widzenia wygody taki model jest świetny. Z punktu widzenia bezpieczeństwa oznacza koncentrację uprawnień w jednym komponencie, którego zachowaniem steruje model analizujący niezaufany tekst.

Pierwszy priorytet to uprawnienia. Agent powinien dostawać możliwość wykonania konkretnej czynności dopiero wtedy, gdy jest ona potrzebna. Odczyt jest inną klasą ryzyka niż zapis, a wyszukanie danych inną niż wysłanie ich na zewnętrzną domenę.

Przykład: agent, który ma przygotować listę spotkań, potrzebuje dostępu do odczytu kalendarza. Nie powinien w tym samym przebiegu otrzymywać swobodnego dostępu do lokalnych plików ani prawa wysyłania dokumentów na dowolny serwer.

Drugi priorytet to twarde granice techniczne. Zakaz powinien być egzekwowany poza samym modelem. Jeżeli agent nie może wysyłać danych do domen spoza listy dozwolonych, złośliwy prompt nie powinien być w stanie zmienić tej reguły kolejną instrukcją tekstową.

W krytycznych środowiskach sensowne jest oddzielanie:

• etapu odczytu niezaufanych danych,

• planowania,

• wykonywania operacji,

• dostępu do sekretów,

• operacji nieodwracalnych.

Trzeci priorytet to potwierdzenie działań wysokiego ryzyka. Nie ma sensu wymagać zgody na każde przewinięcie strony. Agent przestanie wtedy oszczędzać czas. Potwierdzenia powinny pojawiać się przy zmianie domeny zaufania albo przy operacji, której skutki wykraczają poza pierwotne zadanie: wysłaniu pliku, udostępnieniu dokumentu, zmianie hasła, publikacji wiadomości, zakupie, usunięciu danych czy dostępie do menedżera haseł.

Samo „ask before acting” także nie jest jednak absolutną gwarancją. Zenity opisało scenariusze, w których złośliwy przepływ działał mimo mechanizmów wymagających potwierdzenia przed wykonaniem części operacji. Kontrola użytkownika jest więc jedną warstwą, a nie zastępstwem właściwego modelu uprawnień.

Firmy testujące agentowe przeglądarki powinny dodatkowo prowadzić osobne logowanie aktywności AI. Trzeba móc odpowiedzieć nie tylko na pytanie „kto pobrał plik?”, lecz także:

jaki agent pobrał plik, na podstawie jakiego zadania, po przetworzeniu jakiej treści i dokąd później wysłał dane?

Bez takiego śladu audytowego incydent może wyglądać jak poprawna aktywność zalogowanego użytkownika.

Dla polskiej firmy dochodzi aspekt ochrony danych. Jeżeli agent ma dostęp do poczty, dokumentów pracowników albo danych klientów, możliwość autonomicznego przekazania tych danych poza organizację nie jest wyłącznie problemem „AI security”. Może przerodzić się w naruszenie ochrony danych osobowych, które trzeba analizować również pod kątem RODO, procedur reagowania na incydenty i obowiązków administratora danych. Nie każdy udany prompt injection automatycznie oznacza zgłoszenie naruszenia do Prezesa UODO — decyduje rzeczywisty zakres zdarzenia i ryzyko dla osób, których dane dotyczą — ale brak dzienników aktywności agenta znacznie utrudnia taką ocenę.

Najbardziej irytująca cecha tej klasy problemów jest jednocześnie najważniejszym ostrzeżeniem dla administratora: nie istnieje jeden przełącznik „wyłącz prompt injection”. Nawet dobre filtry wejścia mogą przepuścić nową formę instrukcji. Dlatego bezpieczeństwo trzeba projektować tak, aby przejęty tok rozumowania agenta nie oznaczał automatycznie przejęcia wszystkich możliwości użytkownika.

Więcej informacji można znaleźć również na końcu artykułu.

FAQ

Czy PleaseFix wymaga kliknięcia złośliwego linku przez użytkownika?
Nie. Charakterystyczną cechą opisanej klasy ataków jest możliwość uruchomienia łańcucha podczas normalnego przetwarzania treści przez agenta. Użytkownik może wykonywać zwykłe zadanie, a złośliwa instrukcja znajduje się już w stronie, wiadomości, dokumencie lub zaproszeniu, które agent pobiera.

Czy samo otwarcie strony zawsze wystarczy do przejęcia agenta?
Nie. Agent musi przetworzyć złośliwą treść, a jego architektura i dostępne narzędzia muszą pozwolić instrukcji wpłynąć na dalsze działania. Zakres skutków zależy przede wszystkim od uprawnień agenta i zastosowanych granic bezpieczeństwa.

Czy wyłączenie JavaScriptu blokuje PleaseFix?
Nie rozwiązuje problemu jako takiego. Istotą indirect prompt injection jest treść interpretowana przez model, a nie wykonanie JavaScriptu w przeglądarce. Złośliwa instrukcja może istnieć w zwykłym tekście, dokumencie czy zaproszeniu kalendarzowym.

Czy menedżer haseł jest bezpieczny, jeśli sam nie ma żadnej luki?
Nie daje to pełnej ochrony. Jeden ze scenariuszy PleaseFix polegał właśnie na wykorzystaniu autoryzowanego przepływu między agentem a menedżerem haseł, bez konieczności bezpośredniego łamania zabezpieczeń samego menedżera.

Czy aktualizacja przeglądarki wystarczy?
Aktualizacje trzeba instalować, ponieważ zamykają konkretne znane ścieżki ataku. Nie należy jednak traktować ich jako dowodu, że cała klasa indirect prompt injection została wyeliminowana. PleaseFix pokazuje problem architektoniczny: agent jednocześnie interpretuje niezaufane dane i dysponuje uprawnieniami do działania.

Co sprawdzić najpierw w firmie korzystającej z agentów przeglądarkowych?
Najpierw sporządzić listę uprawnień agenta: Gmail, Drive, kalendarz, CRM, komunikatory, menedżer haseł, pliki lokalne i systemy wewnętrzne. Następnie odciąć wszystko, czego agent nie potrzebuje do bieżących zadań, szczególnie możliwość wysyłania danych na zewnętrzne domeny i wykonywania operacji zapisu bez potwierdzenia.

Jeżeli trzeba wybrać tylko jedno działanie na początek, nie zaczynaj od poprawiania system promptu. Najpierw sprawdź, jakie uprawnienia agent odziedziczył po użytkowniku, i usuń te, których nie potrzebuje. Filtr może nie rozpoznać kolejnej formy prompt injection; brak uprawnienia do odczytu pliku albo wysłania go poza organizację zatrzymuje natomiast konkretny skutek ataku.

Więcej informacji na: https://sajo.pl