Same-Origin Policy przez lata działała jak niewidzialna ściana między stronami otwartymi w tej samej przeglądarce. Kod z attacker.example nie powinien móc swobodnie czytać DOM-u banku, poczty czy panelu firmowego działającego pod innym originem. Problem zaczyna się wtedy, gdy między stroną a przeglądarką pojawia się agent AI, który widzi więcej niż skrypt, rozumie polecenia zapisane językiem naturalnym i potrafi wykonywać działania w imieniu zalogowanego użytkownika.
Badania opublikowane w 2026 r. przez Franziskę Roesner i Davida Kohlbrennera z University of Washington pokazały, że nie jest to wyłącznie hipotetyczny model zagrożenia. Autorzy przetestowali siedem systemów agentowych działających w przeglądarkach, a w przypadku części z nich stwierdzili dostęp do treści pochodzących z innych originów. Dla ChatGPT Atlas w trybie Agent Mode przygotowali działający proof of concept kradzieży danych cross-origin.
SOP nadal działa. Tyle że agent potrafi przejść obok niej
Klasyczna Same-Origin Policy, czyli SOP, dotyczy relacji między zasobami sieciowymi i kodem wykonywanym przez przeglądarkę. Origin określają w uproszczeniu trzy elementy: schemat, host i port. https://firma.pl oraz https://konto.firma.pl to inne originy, podobnie jak http://firma.pl i https://firma.pl.
Jeżeli złośliwa strona umieści bank w iframe, JavaScript działający na stronie atakującego nie dostaje automatycznie prawa do odczytania zawartości tego iframe. To właśnie jeden z fundamentów bezpieczeństwa współczesnego WWW.
Agent przeglądarkowy nie musi jednak zachowywać się jak JavaScript. Może otrzymywać informacje z warstwy dostępności, DOM-u, zrzutu ekranu, kontekstu kart albo specjalnego API przygotowanego przez producenta przeglądarki. Następnie model interpretuje zawartość i decyduje, co zrobić.
W testach University of Washington ChatGPT Atlas w Agent Mode, Chrome z Gemini, Claude for Chrome i Perplexity Comet odczytywały treść osadzonych iframe’ów cross-origin. Brave Leo AI, Edge z Copilotem, Firefox AI Mode oraz Atlas bez Agent Mode w badanej konfiguracji takiego dostępu nie wykazywały. Eksperymenty wykonano pod koniec stycznia i na początku lutego 2026 r. na macOS Sequoia, używając aktualnych wówczas stabilnych wersji produktów.
To ważne rozróżnienie. Nie oznacza ono, że SOP w Chromium czy Firefoxie nagle przestała działać. Przeglądarka może poprawnie blokować cross-origin JavaScript, a równocześnie przekazać agentowi reprezentację treści, której skrypt strony nigdy by nie dostał.
W efekcie powstaje drugi kanał przepływu informacji:
-
strona A nie może bezpośrednio odczytać strony B;
-
agent widzi A i B;
-
treść z A wpływa na decyzję agenta;
-
agent odczytuje B;
-
agent może następnie wykonać działanie na A albo innej stronie.
Granica bezpieczeństwa przesuwa się więc z deterministycznego mechanizmu przeglądarki do komponentu opartego na modelu językowym.
I właśnie tutaj zaczyna się problem. Filtr SOP odpowiada zasadniczo „wolno” albo „nie wolno”. Obrona modelu przed prompt injection działa probabilistycznie i może zachowywać się inaczej zależnie od kontekstu, treści strony, sposobu sformułowania instrukcji czy aktualizacji modelu.
Prompt injection zmienia zwykłą stronę w polecenie dla zalogowanego użytkownika
Najbardziej niebezpieczny scenariusz nie wymaga przejęcia przeglądarki ani złamania sandboxa. Wystarczy, że agent potraktuje tekst pochodzący ze strony jako instrukcję.
Schemat ataku może wyglądać następująco:
-
użytkownik otwiera stronę kontrolowaną przez atakującego;
-
strona zawiera obcy iframe albo inną treść dostępną agentowi;
-
w kodzie, tekście, elemencie strony lub komponencie zewnętrznym znajduje się indirect prompt injection;
-
użytkownik prosi agenta np. o podsumowanie strony;
-
agent interpretuje złośliwą treść jako część zadania;
-
odczytuje dane z innego originu;
-
wpisuje je do formularza, wysyła wiadomość albo wykonuje inne dostępne działanie.
W proof of concept przygotowanym dla Atlas Agent Mode agent podsumował stronę razem z treścią iframe’u pochodzącego z innego originu, a następnie umieścił wynik w polu formularza na stronie zewnętrznej. Formularz wysłał dane do serwera atakującego. Badacze sprawdzili też wariant odwrotny: złośliwy iframe pobierał za pośrednictwem agenta informacje z nadrzędnej strony należącej do innego originu.
Nie każdy realny serwis da się zaatakować dokładnie takim samym iframe’em. Współczesne mechanizmy ograniczające osadzanie stron, polityki cookies i ustawienia ramek często blokują najprostszy wariant. To ograniczenie ma znaczenie — demonstracja nie oznacza automatycznie możliwości wyciągnięcia danych z dowolnego banku działającego w Polsce.
Problem architektoniczny pozostaje jednak szerszy niż konkretny PoC. Jeżeli agent może jednocześnie czytać dane w jednym kontekście i wykonywać akcje w drugim, staje się kanałem pomiędzy domenami.
Badacze wskazali trzy praktyczne klasy ryzyka:
-
cross-origin data theft — przeniesienie danych z jednego originu do drugiego;
-
cross-origin action forgery — wykonanie przez agenta działania na innej stronie, np. wypełnienie albo wysłanie formularza;
-
cross-origin chat memory poisoning — pozostawienie fałszywych informacji w pamięci lub historii agenta tak, aby wpływały na późniejsze zadania wykonywane na innych stronach.
Ta ostatnia kategoria jest łatwa do zlekceważenia. Atak nie musi zakończyć się natychmiastowym przelewem czy wyciekiem hasła. Złośliwa strona może zostawić w pamięci agenta fałszywy numer telefonu, adres rachunku, nazwę dostawcy albo instrukcję operacyjną. Kilka dni później użytkownik pyta agenta o właściwe dane, a ten korzysta z zatrutego kontekstu.
Jeszcze poważniejszy sygnał pojawił się przy polach formularzy. W badaniu Atlas Agent Mode i Claude for Chrome potrafiły odczytać również tekst znajdujący się w wizualnie zamaskowanym polu hasła, co wskazuje na dostęp wykraczający poza zwykłe „patrzenie” na ekran.
Dlatego poleganie wyłącznie na komunikacie „agent zapyta przed ważną operacją” jest za słabe. Potwierdzenie użytkownika pomaga przy zakupie lub wysłaniu wiadomości, ale nie rozwiązuje problemu, jeśli człowiek nie widzi, że decyzja agenta została wcześniej zmieniona przez obcą treść.
Co powinno zostać zmienione w architekturze agentic browsers
Najmocniejszą ochroną nie jest kolejny prompt systemowy mówiący modelowi, żeby ignorował podejrzane instrukcje. Granica musi być egzekwowana poza modelem.
Google opisał dla agentowych funkcji Chrome mechanizm Agent Origin Sets. Założenie jest konkretne: agent nie powinien automatycznie otrzymywać dostępu do każdej domeny widocznej w przeglądarce. Originy mają być przypisywane do zbiorów związanych z wykonywanym zadaniem, osobno dla odczytu oraz dla odczytu i zapisu. Treść iframe’u spoza dozwolonego zbioru nie powinna w ogóle trafiać do modelu. Google opisuje również oddzielny komponent oceniający działania agenta, który nie otrzymuje surowej, niezaufanej treści strony.
To kierunek znacznie sensowniejszy niż próba nauczenia modelu, aby zawsze rozpoznawał atak.
W środowisku firmowym kolejność zabezpieczeń powinna wyglądać tak:
-
najpierw ograniczenie uprawnień agenta — które originy może czytać, na których może pisać i jakie narzędzia może uruchamiać;
-
następnie izolacja sesji o wysokiej wartości, zwłaszcza poczty, systemów ERP, CRM, bankowości, paneli chmurowych i aplikacji administracyjnych;
-
dalej obowiązkowa autoryzacja operacji powodujących skutki zewnętrzne: wysłanie wiadomości, publikację danych, zmianę konfiguracji, zakup lub płatność;
-
dopiero później detekcja prompt injection, klasyfikatory i filtry modelowe jako dodatkowa warstwa.
Szczególnie ryzykowne jest uruchamianie agenta w tej samej stale zalogowanej przeglądarce, w której pracownik ma otwarte Microsoft 365, Google Workspace, system księgowy, GitHub, panel AWS lub firmowy CRM. Agent otrzymuje wtedy zestaw możliwości, których pojedyncza strona internetowa nigdy nie powinna posiadać.
W polskich firmach dochodzi jeszcze konsekwencja prawna i organizacyjna. Jeśli agent uzyska dostęp do danych osobowych z aplikacji wewnętrznej, a następnie prześle je do innego originu lub zewnętrznej usługi, problem nie kończy się na błędzie technicznym. Może powstać incydent dotyczący poufności danych wymagający oceny w procedurze naruszeń ochrony danych. Nie każdy incydent oznacza automatycznie zgłoszenie do Prezesa UODO, ale administrator musi ocenić ryzyko dla osób, których dane dotyczą.
Najbardziej irytujący kompromis jest oczywisty: im dokładniej ograniczymy agentowi dostęp do originów, kart i elementów strony, tym częściej agent przestanie wykonywać zadania, dla których został kupiony. Bezpieczny agent może nie zobaczyć osadzonego kalkulatora, wyniku w iframe albo danych z drugiej karty. Agent z pełnym dostępem jest wygodniejszy, ale z punktu widzenia bezpieczeństwa zaczyna przypominać uprzywilejowanego użytkownika reagującego na instrukcje znalezione przypadkiem w internecie.
Dlatego przy wyborze takiego rozwiązania nie wystarczy zapytać dostawcę o „ochronę przed prompt injection”. Trzeba żądać odpowiedzi na pięć prostych pytań:
-
Czy ograniczenie cross-origin jest wymuszane przez kod i politykę przeglądarki, czy tylko przez instrukcję dla modelu?
-
Czy agent widzi DOM, accessibility tree, screenshot, iframe’y i pola formularzy?
-
Czy może czytać inne karty bez każdorazowego wskazania ich przez użytkownika?
-
Czy potrafi samodzielnie kliknąć, wpisać tekst, wysłać formularz albo uruchomić JavaScript?
-
Czy dane z jednej strony mogą zostać zachowane w historii lub pamięci i wykorzystane później na innej domenie?
Odpowiedź „model został wytrenowany, aby tego nie robić” nie powinna być traktowana jako granica bezpieczeństwa.
FAQ
Czy agentic browser rzeczywiście łamie Same-Origin Policy?
Nie zawsze w znaczeniu błędu samego silnika przeglądarki. Problem polega na tym, że agent może otrzymać cross-origin dane innym kanałem niż JavaScript strony i później przenieść je między domenami. Z perspektywy efektu bezpieczeństwa ochrona SOP zostaje wtedy obejścia przez dodatkową warstwę agentową.
Czy zwykły Chrome, Edge albo Firefox bez aktywnego agenta są podatne na ten sam problem?
Nie. Opisywana klasa ryzyka dotyczy funkcji agentowych posiadających dostęp do treści stron lub możliwość wykonywania operacji. Sama obecność klasycznej przeglądarki nie tworzy tego kanału.
Czy wystarczy wyłączyć dostęp agenta do haseł?
Nie. Hasło jest tylko jednym rodzajem danych. Równie wartościowe mogą być treści poczty, faktury, dane CRM, numery rachunków, tokeny widoczne w panelach, informacje kadrowe albo zawartość prywatnych dokumentów.
Czy potwierdzanie każdej operacji przez użytkownika rozwiązuje problem?
Ogranicza skutki, ale nie usuwa przyczyny. Użytkownik może zaakceptować działanie, nie wiedząc, że agent zaplanował je na podstawie złośliwej instrukcji ukrytej w treści strony. Architektoniczne ograniczenie dostępu powinno działać przed etapem potwierdzenia.
Które przeglądarki wypadły najbardziej restrykcyjnie w badaniu z 2026 r.?
W konfiguracjach użytych przez badaczy Brave Leo AI, Edge z Copilotem oraz Firefox AI Mode miały bardziej ograniczony dostęp do iframe’ów niż najbardziej autonomiczne rozwiązania. Nie należy jednak traktować tej tabeli jako stałego rankingu bezpieczeństwa — funkcje agentowe są intensywnie rozwijane i ich architektura może zmienić się wraz z aktualizacją.
Więcej informacji na: https://sajo.pl
Jeżeli agentic browser ma trafić do firmy, pierwszym krokiem nie powinien być test jakości odpowiedzi, lecz test granic uprawnień: otwórz dwie kontrolowane aplikacje na różnych originach, umieść w jednej unikalny znacznik testowy i sprawdź, czy agent potrafi odczytać go z drugiego kontekstu albo przepisać do formularza na innej domenie. Jeśli potrafi to zrobić bez jednoznacznie nadanej zgody na oba originy, najpierw usuń właśnie ten problem albo wyłącz funkcje agentowe dla sesji z danymi wrażliwymi.