W dyskusji o agentach AI zbyt łatwo myśleć o prompt injection jak o problemie pojedynczego pola tekstowego. ShadowPrompt pokazuje coś znacznie groźniejszego. Kiedy agent działa w przeglądarce, problem nie zaczyna się już od promptu, ale od granicy zaufania między stroną, rozszerzeniem i kontekstem użytkownika. W ujawnionym łańcuchu wystarczało odwiedzić stronę, by obca instrukcja została potraktowana przez rozszerzenie Claude jak własna prośba użytkownika. Koi opisało tę lukę jako zero-click prompt injection chain w oficjalnym rozszerzeniu Claude dla Chrome; Anthropic załatało problem w wersji 1.0.41, a źródłowy komponent Arkose usunięto po wcześniejszej poprawce XSS.
I właśnie dlatego ShadowPrompt jest ciekawsze niż zwykła historia o błędzie XSS. To nie jest po prostu „strona wykonała zły JavaScript”. To przypadek, w którym agentowa warstwa w przeglądarce przyjęła wrogi kontekst jako legalny sygnał sterujący. Koi opisało dwa kluczowe elementy łańcucha: rozszerzenie ufało szeroko całemu *.claude.ai, a podatny komponent Arkose hostowany na a-cdn.claude.ai zawierał DOM-based XSS. Razem pozwalało to wysłać do rozszerzenia złośliwy prompt tak, jakby pochodził od użytkownika.
To bardzo dobrze spina się z wcześniejszymi wnioskami Cyberfluxa o agentach AI. W tekście o permission injection problemem nie był sam prompt, ale środowisko pełne uprawnień, integracji i możliwości działania. W tekście o prompt injection po erze prostych analogii problemem była granica między analizą a wykonaniem. ShadowPrompt pokazuje następną warstwę: kiedy agent siedzi już w przeglądarce, sama przeglądarka przestaje być neutralnym oknem na web. Zaczyna być warstwą wykonania. A jeśli warstwa wykonania ufa złemu kontekstowi, prompt injection przestaje być tekstową sztuczką. Staje się kanałem realnego sterowania.
To nie tylko XSS. To przejęcie granicy zaufania
Najważniejsze w ShadowPrompt nie jest samo istnienie błędu w jednym komponencie. Najważniejsze jest to, jak ten błąd połączył się z modelem zaufania rozszerzenia. Koi opisało, że rozszerzenie akceptowało prompt-carrying messages od szerokiej klasy originów *.claude.ai, a podatny komponent Arkose był hostowany właśnie w tym zaufanym obszarze. W praktyce oznaczało to, że złośliwy JavaScript uruchomiony na zaufanym subdomenowym kontekście mógł przesłać rozszerzeniu instrukcję, która wyglądała jak legalny input użytkownika.
To jest kluczowy moment analityczny. W klasycznym myśleniu o bezpieczeństwie webowym granicą bywa zwykle origin. Jeśli origin jest zaufany, system często idzie dalej bez większej weryfikacji. ShadowPrompt pokazuje, że w świecie agentów AI to za mało. Zaufany origin to nie to samo co autoryzowana intencja użytkownika. I właśnie tu przeglądarka zaczyna być polem walki: nie dlatego, że uruchomiła kod, ale dlatego, że pomyliła źródło wykonania z prawem do sterowania agentem.
Agent w przeglądarce to nie widget. To operator
Ta historia byłaby mniej ważna, gdyby chodziło o bierne rozszerzenie pokazujące streszczenia albo podpowiedzi. Ale Koi wyraźnie podkreśla, że Claude w Chrome był projektowany jako agent zdolny czytać strony, nawigować, wykonywać JavaScript i działać na witrynach w imieniu użytkownika. TechRadar streszcza to podobnie: problem nie sprowadzał się do zwykłego pop-upu czy treści bocznego panelu, tylko do realnej możliwości przejęcia przeglądania i wykonywania działań w sesji użytkownika.
To nie jest opowieść o jednym niefortunnym bugfixie. To jest opowieść o tym, że agent browserowy przestaje być asystentem tekstowym, a staje się uprzywilejowanym operatorem, który działa na granicy:
- sesji użytkownika,
- kontekstu strony,
- rozszerzenia,
- i zaufanych originów.
Jeśli taki operator zaakceptuje cudzą instrukcję jako własne polecenie użytkownika, problemem nie jest już prompt. Problemem jest utrata kontroli nad warstwą wykonania.
Zero-click zmienia znaczenie prompt injection
W starszym modelu prompt injection często wyobrażano sobie jako coś, co wymaga przynajmniej pośredniej współpracy użytkownika: wklejenia tekstu, otwarcia dokumentu, załadowania strony do agenta, skopiowania polecenia. ShadowPrompt przesuwa ten model. Tutaj użytkownik nie musiał nic zatwierdzać, nic kopiować, nic wklejać. Wystarczyło odwiedzić stronę. To właśnie dlatego zarówno Koi, jak i kolejne omówienia tej luki, nazywają ten łańcuch zero-click.
To ważne, bo pokazuje, że prompt injection przestaje być wyłącznie podatnością semantyczną. W przypadku agentów browserowych staje się problemem architektury sterowania. Jeśli przeglądarka, rozszerzenie i agent są ze sobą spięte tak, że wroga strona może doprowadzić do wykonania instrukcji bez udziału użytkownika, to prompt injection schodzi na poziom środowiska wykonawczego. I właśnie dlatego ShadowPrompt warto czytać nie jako „ciekawostkę o rozszerzeniu Claude”, ale jako zapowiedź większego trendu.
Najsłabszy origin staje się najsłabszym ogniwem agenta
Koi ujęło to bardzo trafnie: jeśli rozszerzenie potrafi nawigować, czytać credentials i działać w imieniu użytkownika, to jego bezpieczeństwo jest tylko tak mocne, jak najsłabsze originy w jego granicy zaufania. To zdanie ma dużo większe znaczenie niż sam case Claude. Bo ten sam problem będzie wracał wszędzie tam, gdzie agent:
- działa w przeglądarce,
- używa danych sesyjnych,
- łączy się z zaufanymi domenami,
- i ma możliwość wykonywania akcji zamiast samego generowania tekstu.
To jest dokładnie ten moment, w którym bezpieczniej przestać myśleć o browser AI jak o „pomocniku do czytania stron” i zacząć myśleć o nim jak o systemie sterowania z ograniczoną, ale realną sprawczością. A system sterowania wymaga innych pytań niż chatbot:
- kto może do niego mówić,
- z jakiego kontekstu,
- przez jakie originy,
- przy jakim poziomie zaufania,
- i z jakim skutkiem wykonawczym.
ShadowPrompt pokazuje większy problem niż Claude
Największa wartość tej historii nie polega na tym, że dotyczy konkretnego rozszerzenia. Polega na tym, że obnaża szerszy problem projektowy. Kiedy agent dostaje możliwość czytania, decyzji i działania wewnątrz przeglądarki, każde uproszczenie trust boundary zaczyna działać jak część control plane’u. Penligent trafnie zauważa, że to już nie jest zwykły problem wiadomości między komponentami, tylko nowa odmiana confused deputy: rozszerzenie miało wystarczająco dużo autorytetu, żeby wykonywać zadania, ale nie miało wystarczająco silnego sposobu odróżniania intencji użytkownika od wrogiego inputu dostarczonego przez zaufaną ścieżkę.
To bardzo dobrze domyka wcześniejsze wnioski Cyberfluxa. Jeżeli permission injection dotyczy tego, co agent może zrobić, a prompt injection tego, czym da się nim sterować, to ShadowPrompt pokazuje jeszcze jedną rzecz: browser agent to miejsce, w którym te dwa problemy spotykają się z architekturą webu. I wtedy nie trzeba nawet spektakularnego exploita. Wystarczy, że zaufanie do kontekstu okaże się szersze niż powinno.
Co z tego wynika dla security
Najbardziej praktyczny wniosek jest prosty: w świecie agentów browserowych nie wystarczy już pytać, czy strona jest zaufana albo czy rozszerzenie ma poprawny permission set. Trzeba pytać szerzej:
- jakie originy mogą wysyłać agentowi instrukcje,
- czy zaufana domena naprawdę oznacza zaufaną intencję,
- czy input „od użytkownika” jest technicznie odróżnialny od inputu „od strony”,
- i czy agent ma możliwość przejścia od interpretacji do działania bez dodatkowych granic kontrolnych.
ShadowPrompt pokazuje, że browser AI to nie jest „kolejna wygodna funkcja produktywności”. To nowa warstwa wykonawcza, która siedzi bardzo blisko sesji użytkownika, jego kontekstu i jego zaufania. A jeśli tak, to jej bezpieczeństwo nie może być projektowane jak bezpieczeństwo prostego widgetu. Musi być projektowane jak bezpieczeństwo uprzywilejowanego operatora.
Podsumowanie
ShadowPrompt pokazuje, że gdy agent trafia do przeglądarki, prompt injection przestaje być wyłącznie problemem tekstu. Staje się problemem wykonania. Nie trzeba kliknięcia. Nie trzeba kopiowania. Nie trzeba zgody użytkownika. Wystarczy, że warstwa wykonania zaufa złemu kontekstowi.
I właśnie dlatego przeglądarka przestaje być tylko miejscem, w którym czytamy web. Coraz częściej staje się miejscem, z którego agent może działać w naszym imieniu. A wtedy pytanie nie brzmi już tylko: czy agent rozumie polecenie?
Lepsze brzmi: kto naprawdę steruje warstwą, która może je wykonać?
Źródła
Koi — oryginalny opis ShadowPrompt, łańcucha zero-click prompt injection w rozszerzeniu Claude dla Chrome.
The Hacker News — omówienie podatności, wersji 1.0.41 i roli Arkose/XSS.
TechRadar — streszczenie skutków ataku i znaczenia tej klasy ryzyka dla browser AI.
Penligent — analiza architektoniczna, dlaczego ShadowPrompt to browser-scale risk, a nie zwykły bug rozszerzenia.
