Historia przeglądania jako źródło wycieku przez agenta AI: co ujawnia przeglądarka, gdy działa w naszym imieniu

Agent AI nie potrzebuje dostępu do całego dysku ani firmowej bazy klientów, żeby zebrać zaskakująco dokładny obraz użytkownika. Czasem wystarczy przeglądarka. Historia odwiedzonych stron pokazuje nie tylko domeny, ale również konkretne adresy URL, tytuły stron, czas wizyt, częstotliwość odwiedzin i ścieżkę poruszania się po sieci. W praktyce można z niej odtworzyć klientów, dostawców, używane systemy SaaS, trwającą rekrutację, problemy zdrowotne, zainteresowanie kredytem czy przygotowania do zmiany pracy.

Trzeba jednak rozdzielić dwie rzeczy. Zwykła strona internetowa nie może po prostu pobrać pełnej historii Chrome, Edge’a czy Firefoksa. Współczesne przeglądarki od lat ograniczają techniki wykrywania odwiedzonych stron. Inaczej wygląda sytuacja, kiedy agent działa jako rozszerzenie, funkcja zintegrowana z przeglądarką albo automat sterujący profilem użytkownika. Wtedy granicą prywatności nie jest już wyłącznie mechanizm bezpieczeństwa strony WWW, lecz zestaw uprawnień przyznanych agentowi.

I właśnie tutaj pojawia się problem: agent ma wykonywać zadania „tak jak użytkownik”, więc z definicji dostaje część jego możliwości. Jeśli dostanie za dużo, historia przeglądania staje się niepozornym magazynem informacji, który można wykorzystać przypadkiem, przez błędną konfigurację albo w wyniku prompt injection.

Historia przeglądania mówi znacznie więcej niż nazwa odwiedzonej strony

Historia Chrome nie jest technicznie prostą tabelą „domena + data”. Rozszerzenie posiadające uprawnienie history może korzystać z interfejsu chrome.history. Dostępne informacje obejmują między innymi:

• adres URL odwiedzonej strony,

• tytuł strony,

• czas ostatniej wizyty,

• liczbę odwiedzin,

• liczbę przypadków, gdy adres został wpisany bezpośrednio,

• czas konkretnej wizyty,

• sposób przejścia na stronę, np. kliknięcie linku, wpisanie adresu, przesłanie formularza czy przeładowanie,

• identyfikator wizyty odsyłającej, pozwalający powiązać część kolejnych przejść.

Domyślne wywołanie wyszukiwania historii w Chrome zwraca maksymalnie 100 wyników, a bez wskazania czasu początkowego obejmuje domyślnie ostatnie 24 godziny. Nie jest to jednak ograniczenie ochronne. Aplikacja może podać własny zakres czasu oraz liczbę wyników.

Szczególnie istotny jest sam URL. Na poprawnie zaprojektowanej stronie nie powinien zawierać sekretów, ale rzeczywiste aplikacje nadal zapisują w ścieżkach i parametrach informacje, których użytkownik nie traktuje jako danych wrażliwych. Można spotkać:

• wpisane do wyszukiwarki zapytanie,

• nazwę projektu lub klienta,

• identyfikator dokumentu,

• numer zgłoszenia serwisowego,

• nazwę produktu oglądanego w systemie B2B,

• parametry kampanii,

• nazwę organizacji lub przestrzeni roboczej.

Jeszcze gorzej wyglądają formularze korzystające z metody GET. W takim przypadku wartości pól mogą zostać dołączone do adresu URL jako parametry zapytania, a URL może trafić do historii. Dlatego formularza zawierającego PESEL, numer klienta, adres e-mail, dane medyczne czy wewnętrzne identyfikatory nie powinno się projektować w taki sposób.

Historia potrafi zdradzić informacje nawet wtedy, gdy pojedynczy wpis wydaje się niegroźny. Sekwencja:

portal rekrutacyjny → profil konkretnej firmy → kalkulator wynagrodzeń → poradnik dotyczący wypowiedzenia umowy

mówi więcej niż którakolwiek z tych stron osobno.

Podobnie wygląda seria odwiedzin portalu medycznego, informacji o określonym leku i systemu rezerwacji wizyt. Historia przeglądania nie jest automatycznie szczególną kategorią danych w rozumieniu RODO, ale może ujawnić lub pozwolić wywnioskować informacje dotyczące zdrowia, poglądów politycznych, przekonań religijnych, przynależności związkowej czy orientacji seksualnej. W konkretnym procesie takie dane wymagają znacznie ostrożniejszej oceny.

Kolejna pułapka to synchronizacja. Po włączeniu synchronizacji historii w Chrome informacje dostępne w profilu mogą obejmować również strony odwiedzane na innych urządzeniach. Chrome rozróżnia nawet wizyty lokalne od zsynchronizowanych. Efekt praktyczny jest prosty: agent uruchomiony na firmowym laptopie może dostać kontekst szerszy niż aktywność wykonana na tym jednym komputerze, jeśli korzysta z tego samego zsynchronizowanego profilu.

To jeden z powodów, dla których podłączanie agenta do codziennego profilu przeglądarki jest złym domyślnym ustawieniem.

Wyciek nie musi oznaczać włamania — wystarczy, że agent wykona niewłaściwe polecenie

Najgroźniejszy scenariusz nie wygląda jak klasyczny atak na komputer. Nie musi pojawić się malware, exploit ani przejęte hasło. Agent otrzymuje legalny dostęp, a następnie wykorzystuje go w sposób, którego użytkownik nie przewidział.

Pierwsza droga to nadmierne uprawnienia.

Agent miał znaleźć trzy faktury, ale pracuje w profilu zawierającym historię z kilku miesięcy, aktywne sesje Microsoft 365, Google Workspace, system CRM i panel księgowy. Zadanie wymagało dostępu do jednego systemu. Agent dostał kontekst pięciu.

To klasyczny błąd architektoniczny: zakres możliwości jest większy niż zakres zadania.

Druga droga to pośredni prompt injection. Agent otwiera stronę, wiadomość e-mail, dokument albo komentarz, w którym znajduje się tekst przygotowany nie dla człowieka, lecz dla modelu. Instrukcja może próbować przekonać agenta, żeby zignorował pierwotne zadanie, pobrał dodatkowe informacje albo wykonał działanie na rzecz atakującego.

Wyobraźmy sobie zadanie:

„Sprawdź strony konkurencji odwiedzane w tym tygodniu i przygotuj zestawienie zmian cen”.

Na jednej ze stron znajduje się spreparowana instrukcja skierowana do agenta. Jeżeli system źle oddziela niezaufaną treść strony od poleceń użytkownika, agent może spróbować wykonać dodatkową czynność: otworzyć dane dostępne w sesji, odczytać informacje z innej aplikacji albo wysłać dane na zewnętrzny adres.

To nie jest problem rozwiązany raz na zawsze filtrem słów. Prompt injection pozostaje jednym z trudniejszych problemów bezpieczeństwa systemów agentowych, ponieważ agent musi czytać niezaufaną treść internetu właśnie po to, aby wykonywać swoją pracę.

Trzeci kanał jest mniej widowiskowy: zrzuty ekranu, logi działania i historia samej sesji agenta.

Agent sterujący interfejsem często potrzebuje obrazu strony, aby ustalić, gdzie kliknąć. Na ekranie mogą znajdować się:

• otwarte karty,

• nazwa zalogowanego użytkownika,

• fragment korespondencji,

• kwota faktury,

• dane kontrahenta,

• treść formularza,

• panel CRM,

• komunikaty wyświetlane przez stronę.

To oznacza, że bezpieczeństwa nie można oceniać wyłącznie pytaniem „czy model ma dostęp do historii Chrome?”. Trzeba sprawdzić również co trafia do kontekstu modelu, jakie ekrany są rejestrowane, gdzie przechowywany jest zapis sesji oraz jak długo pozostają dostępne logi.

Niektóre systemy agentowe celowo korzystają więc z odizolowanej przeglądarki lub kontenera. To lepszy model niż automatyzowanie codziennego Chrome użytkownika, ale ma swoją cenę. Trzeba ponownie się logować, nie działa część zapisanych ustawień, a przekazywanie plików między środowiskami jest mniej wygodne. Z punktu widzenia bezpieczeństwa ta niedogodność jest jednak zaletą: agent nie dziedziczy przypadkiem kilku lat cyfrowego życia użytkownika.

Tryb incognito nie jest pełnym zamiennikiem takiej izolacji. Ogranicza pozostawianie lokalnej historii po zamknięciu sesji, ale podczas działania agent nadal widzi strony, na których pracuje. Nie usuwa też ryzyka wynikającego z aktywnego logowania, zrzutów ekranu, treści formularzy czy prompt injection.

Jak skonfigurować agenta, żeby historia nie stała się bocznymi drzwiami do danych

Najlepsza kontrola nie polega na codziennym kasowaniu historii. Najpierw trzeba zmniejszyć ilość danych, do których agent w ogóle może dotrzeć.

W środowisku firmowym dobrym punktem wyjścia jest osobny profil przeglądarki przeznaczony dla agentów. Powinien zaczynać się praktycznie od zera: bez prywatnej historii, bez synchronizacji osobistego konta, bez zapisanych haseł i bez rozszerzeń odziedziczonych z głównego profilu.

Następnie trzeba przejść przez uprawnienia.

W Chrome pierwszym technicznym testem jest chrome://extensions. Jeżeli agent działa przez rozszerzenie, należy sprawdzić jego deklarowane możliwości. Uprawnienie history powinno od razu uruchamiać dodatkową weryfikację, bo daje dostęp do dedykowanego API historii. Podobnie trzeba traktować możliwość odczytywania danych z wielu stron, korzystania z cookies lub działania na wszystkich domenach.

Zasada jest prosta: jeśli zadanie agenta ogranicza się do crm.firma.pl i poczta.firma.pl, nie ma technicznego uzasadnienia, żeby mógł swobodnie otwierać setki innych domen.

Przy wdrożeniach, które mają rzeczywiście przetwarzać poufne dane, konfiguracja powinna wyglądać mniej więcej tak:

• osobny profil, kontener albo maszyna wirtualna dla agenta;

• wyłączona niepotrzebna synchronizacja historii;

• lista dozwolonych domen zamiast nieograniczonego internetu, gdy proces na to pozwala;

• osobne konto użytkownika z minimalnym zakresem uprawnień;

• brak zapisanych danych logowania do usług niepotrzebnych w danym zadaniu;

• ręczne zatwierdzanie operacji nieodwracalnych: wysyłki, płatności, kasowania danych, publikacji i zmian uprawnień;

• ograniczenie możliwości wysyłania danych do przypadkowych domen;

• określony czas przechowywania logów i nagrań sesji;

• test prompt injection przed dopuszczeniem procesu do danych produkcyjnych.

Istotna jest też hierarchia zabezpieczeń. Najpierw izolacja i minimalne uprawnienia, później filtry oraz wykrywanie prompt injection. Odwrócenie tej kolejności jest częstym błędem. Nawet bardzo dobry mechanizm wykrywający złośliwe instrukcje nie daje gwarancji, że rozpozna każdą nową technikę ataku. Agent, który nie posiada dostępu do danych, nie może ich ujawnić nawet wtedy, gdy zostanie zmanipulowany.

Dobrym testem przed wdrożeniem jest umieszczenie w środowisku kontrolnym charakterystycznego fikcyjnego sekretu, np. TEST-KLIENT-8472-NIE-WYSYLAC, a następnie sprawdzenie, czy różne scenariusze prompt injection są w stanie doprowadzić do pojawienia się tego ciągu w żądaniu wysyłanym poza dozwolone systemy. Nie jest to formalny audyt bezpieczeństwa, ale szybko ujawnia zbyt szeroką komunikację wychodzącą.

W polskiej firmie dochodzi do tego RODO. Historia powiązana z konkretnym pracownikiem, klientem lub użytkownikiem może stanowić dane osobowe, a użycie jej przez system AI jest operacją przetwarzania. Administrator musi więc mieć określony cel i podstawę przetwarzania, ograniczyć dane do niezbędnego zakresu oraz zastosować zabezpieczenia adekwatne do ryzyka.

Praktycznie oznacza to, że argument „agent może to przeczytać, bo pracownik też może” jest niewystarczający. Człowiek mający dostęp do CRM nie dostaje z tego powodu automatycznie prawa do kopiowania całej historii przeglądarki pracownika do dodatkowego systemu.

Przy procesach mogących powodować wysokie ryzyko trzeba rozważyć ocenę skutków dla ochrony danych — DPIA. Artykuł 35 RODO wskazuje wprost na rodzaje przetwarzania, które ze względu na charakter, zakres, kontekst i cele, szczególnie przy użyciu nowych technologii, mogą powodować wysokie ryzyko dla praw lub wolności osób. Nie każdy agent wymaga DPIA. Lokalny automat otwierający publiczne strony bez danych osobowych to inna sytuacja niż agent analizujący historię pracowników, pocztę, CRM i dokumentację medyczną.

Najbardziej irytującą konsekwencją bezpiecznej konfiguracji jest większa liczba przerw w automatyzacji. Użytkownik musi zatwierdzać część działań, ponownie się logować albo ręcznie przekazywać plik do izolowanego środowiska. Tego nie należy „naprawiać” przez stopniowe dodawanie agentowi wszystkich uprawnień. Tarcie jest czasem właśnie mechanizmem bezpieczeństwa.

Jeżeli proces przestaje mieć sens ekonomiczny po wprowadzeniu minimalnych zabezpieczeń, warto zakwestionować samą automatyzację. Agent AI nie powinien dostawać dostępu do całego profilu tylko dlatego, że rozdzielenie środowiska komplikuje wdrożenie.

FAQ: agent AI, historia przeglądania i prywatność

Czy każda strona internetowa może odczytać pełną historię mojej przeglądarki?
Nie. Przeglądarki stosują ograniczenia uniemożliwiające stronom swobodne odpytywanie pełnej historii użytkownika. Problem wygląda inaczej w przypadku rozszerzeń i agentów posiadających dodatkowe uprawnienia przeglądarki.

Czy usunięcie historii przed uruchomieniem agenta rozwiązuje problem?
Tylko częściowo. Usuwa jeden zbiór danych, ale agent nadal może korzystać z aktywnych sesji, otwartych stron, cookies, danych formularzy i informacji pojawiających się na ekranie. Lepszą ochroną jest osobny, czysty profil.

Czy tryb incognito wystarczy do bezpiecznej pracy agenta?
Nie. Incognito ogranicza pozostawianie lokalnych śladów po zakończeniu sesji, ale nie izoluje automatycznie danych widocznych podczas jej trwania. Agent nadal może zobaczyć informacje dostępne na otwartych stronach.

Czy synchronizacja Chrome zwiększa zakres ryzyka?
Tak. Przy włączonej synchronizacji historia profilu może uwzględniać aktywność z innych urządzeń. Dlatego profil przeznaczony dla agenta nie powinien bez potrzeby korzystać z osobistej synchronizacji użytkownika.

Czy history w uprawnieniach rozszerzenia jest powodem do usunięcia rozszerzenia?
Nie automatycznie. Dla niektórych narzędzi jest to funkcja niezbędna. Trzeba jednak sprawdzić, po co jej potrzebują i czy korzyść uzasadnia zakres dostępu. Jeżeli narzędzie do streszczania jednej otwartej strony żąda pełnego dostępu do historii, jest to sygnał ostrzegawczy.

Czy prompt injection da się całkowicie wyeliminować?
Nie ma dziś rozsądnej podstawy, by obiecywać stuprocentową odporność agenta pracującego z niezaufaną treścią internetu. Dlatego podstawowym zabezpieczeniem pozostaje ograniczenie tego, co agent może odczytać i zrobić po ewentualnym przejęciu jego toku działania.

Czy korzystanie z agenta przeglądarkowego jest niezgodne z RODO?
Nie. Problemem nie jest sam agent, lecz sposób przetwarzania danych. Firma musi ustalić cel, zakres, podstawę prawną, okres przechowywania i zabezpieczenia. Jeżeli proces wykorzystuje szeroki zakres danych lub może powodować wysokie ryzyko, potrzebna może być DPIA.

Od czego zacząć audyt?
Od jednej rzeczy: sprawdzić, czy agent pracuje w tym samym profilu przeglądarki, którego używasz codziennie. Jeśli odpowiedź brzmi „tak”, najpierw usuń właśnie ten błąd. Utwórz osobny, czysty profil lub izolowane środowisko, wyłącz zbędną synchronizację i dopiero potem analizuj kolejne zabezpieczenia. Strojenie promptów, filtrów i polityk bezpieczeństwa nie ma sensu, jeśli agent od początku siedzi w środku profilu zawierającego historię, aktywne sesje i zapisane dane.

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