Lokalne pliki komputera w zasięgu agenta WWW: gdzie powinny kończyć się uprawnienia autonomicznej przeglądarki

Największy problem z autonomiczną przeglądarką zaczyna się nie wtedy, gdy agent potrafi kliknąć przycisk „Kup”, zalogować się do panelu albo wypełnić formularz. Prawdziwa zmiana poziomu ryzyka następuje w momencie, w którym ten sam agent dostaje dostęp do lokalnych plików komputera. Od tej chwili błędna decyzja nie musi kończyć się źle wypełnionym formularzem. Może oznaczać odczyt umowy, pliku .env, eksportu z systemu księgowego albo całego katalogu projektu i przesłanie jego zawartości poza komputer.

Granica powinna być więc ustawiona znacznie wcześniej, niż sugeruje wygoda użytkownika. Agent WWW nie potrzebuje „dostępu do plików”. Potrzebuje dostępu do konkretnego pliku, konkretnej operacji i konkretnego celu. To różnica, która w praktyce decyduje, czy błąd modelu pozostanie drobną pomyłką, czy stanie się incydentem bezpieczeństwa.

Dostęp do jednego dokumentu i dostęp do dysku to dwie zupełnie różne rzeczy

Standardowa strona WWW nie może po prostu otworzyć C:\Users\Anna\Documents albo katalogu domowego w Linuksie i zacząć go przeglądać. Klasyczny mechanizm <input type=”file”> udostępnia stronie pliki wskazane przez użytkownika. Bardziej rozbudowany File System Access API potrafi natomiast udostępnić aplikacji uchwyt do wybranego pliku lub katalogu, a następnie pozwolić na jego odczyt, a po nadaniu odpowiednich praw również zapis.

To istotne rozróżnienie. Metody takie jak showOpenFilePicker() czy showDirectoryPicker() wymagają interakcji użytkownika i działają w bezpiecznym kontekście, czyli zasadniczo przez HTTPS. Przy wyborze katalogu tryb domyślny to odczyt, natomiast dostęp readwrite obejmuje także zapis.

Problem zaczyna się później. Użytkownik widzi komunikat „zezwól na dostęp do folderu” i myśli o jednym dokumencie, z którym właśnie pracuje. Dla aplikacji dostęp do katalogu oznacza możliwość poruszania się po jego strukturze i obsługi znajdujących się w nim plików w granicach przyznanych praw. Dlatego wskazanie całego katalogu Dokumenty zamiast jednego PDF-a jest jakościowo inną decyzją bezpieczeństwa.

Chromium posiada dodatkowe zabezpieczenia blokujące wybrane szczególnie wrażliwe ścieżki systemowe. Nie należy jednak traktować ich jako filtra danych firmowych. Przeglądarka może uznać katalog systemowy za niebezpieczny, ale nie wie, że C:\Users\Jan\Documents\Kadry\wynagrodzenia.xlsx zawiera dane płacowe, a projekt\.env klucz API do produkcyjnej bazy.

Do tego dochodzi trwałość zezwoleń. Chrome wprowadził możliwość nadawania wybranym aplikacjom WWW stałego dostępu do wcześniej wskazanych plików i katalogów. Użytkownik może wybrać dostęp tylko na bieżącą sesję albo dostęp przy kolejnych wizytach, a uchwyty do plików mogą być przechowywane przez aplikację m.in. w IndexedDB. To wygodne przy edytorze uruchamianym w przeglądarce. W przypadku autonomicznego agenta oznacza jednak, że zgoda udzielona do jednego zadania może przeżyć samo zadanie.

Jeszcze ważniejsza jest architektura konkretnego produktu. Agent działający jako zwykła strona WWW podlega ograniczeniom API przeglądarki. Agent dostarczony jako rozszerzenie, aplikacja desktopowa albo program korzystający z natywnego pośrednika może mieć znacznie szersze uprawnienia systemowe. Sam wygląd interfejsu niczego więc nie rozstrzyga.

Przed uruchomieniem takiego narzędzia trzeba rozdzielić co najmniej pięć niezależnych praw:

• odczyt zawartości pliku,

• wyświetlanie listy plików w katalogu,

• tworzenie nowych plików,

• modyfikowanie, przenoszenie i usuwanie istniejących plików,

• wysyłanie danych poza komputer.

Najczęstszy błąd polega na potraktowaniu ich jako jednego uprawnienia „dostęp do folderu”. Nie powinny nim być.

Najgroźniejszym scenariuszem nie jest błąd agenta, tylko połączenie prompt injection z szerokimi prawami

Agent autonomicznej przeglądarki działa na treści, której właścicielem często jest ktoś obcy. Czyta stronę sklepu, panel kontrahenta, wiadomość, dokument PDF, repozytorium albo instrukcję znalezioną w sieci. To tworzy warunki do pośredniego prompt injection: treść z zewnętrznego źródła może zawierać instrukcję próbującą zmienić zachowanie modelu.

Nie musi wyglądać jak komunikat „wykradnij plik”. Instrukcja może być schowana w dokumencie, elemencie strony albo innym materiale przetwarzanym przez model. Dla człowieka będzie częścią zawartości. Dla agenta może stać się kolejnym poleceniem do wykonania.

Typowy niebezpieczny łańcuch wygląda tak:

1. Użytkownik poleca agentowi znaleźć informacje na stronie.

2. Agent otwiera treść kontrolowaną przez podmiot zewnętrzny.

3. Zawartość próbuje nakłonić model do wykonania dodatkowej czynności.

4. Agent ma już dostęp do lokalnego katalogu.

5. Ma również sesję w poczcie, komunikatorze, chmurze albo formularzu umożliwiającym załączanie plików.

6. Lokalny dokument może zostać odczytany i wysłany poza komputer.

Każde z tych uprawnień rozpatrywane oddzielnie może wyglądać rozsądnie. Zagrożenie powstaje przez ich kompozycję.

Dlatego tryb „tylko do odczytu” nie rozwiązuje problemu. Chroni przed nadpisaniem pliku, ale nie przed wyciekiem jego treści. Jeżeli agent potrafi przeczytać lista_klientow.xlsx, a następnie umieścić załącznik na stronie WWW, wysłać e-mail albo wkleić dane do formularza, ma kompletną ścieżkę eksfiltracji.

Dostęp do zapisu zwiększa konsekwencje jeszcze bardziej. Agent może przez pomyłkę:

• nadpisać właściwą wersję umowy;

• zmienić kod źródłowy;

• zmodyfikować plik konfiguracyjny;

• usunąć albo przenieść dokument;

• stworzyć plik, który później zostanie automatycznie przetworzony przez inne narzędzie.

Szczególnie źle wygląda połączenie dostępu readwrite z katalogami zawierającymi kod wykonywalny, skrypty, konfigurację CI/CD czy pliki uruchamiane przez inne procesy. Wtedy zwykła operacja zapisu może mieć efekt znacznie większy niż zmiana kilku bajtów na dysku.

W środowisku firmowym dochodzi aspekt prawny. Jeśli dokument zawiera dane osobowe, udostępnienie jego treści agentowi jest elementem procesu przetwarzania danych. Nie wystarcza stwierdzenie, że „plik nadal znajduje się na laptopie”. Trzeba wiedzieć, czy zawartość jest wysyłana do infrastruktury dostawcy modelu, gdzie jest przetwarzana, jak długo jest przechowywana oraz kto występuje jako administrator lub podmiot przetwarzający.

RODO daje tu bardzo praktyczne kryteria. Art. 5 ust. 1 lit. c ustanawia zasadę minimalizacji danych, art. 25 wymaga ochrony danych w fazie projektowania i domyślnej ochrony danych, a art. 32 dotyczy bezpieczeństwa przetwarzania. Dla agenta oznacza to prostą zasadę techniczną: nie otwieramy mu całego katalogu tylko dlatego, że jeden znajdujący się w nim dokument jest potrzebny do zadania.

W organizacjach podlegających wymaganiom NIS2 kwestie kontroli dostępu, zarządzania aktywami, analizy ryzyka i bezpieczeństwa systemów są dodatkowym argumentem przeciwko kontom agentów z szerokimi, trwałymi uprawnieniami. NIS2 nie obejmuje automatycznie każdej małej firmy w Polsce, dlatego zakres trzeba oceniać według rodzaju podmiotu, sektora i aktualnych przepisów krajowych. Sam model bezpieczeństwa pozostaje jednak rozsądny również poza podmiotami formalnie objętymi regulacją.

Bezpieczny agent powinien pracować w wydzielonym warsztacie, a nie w całym katalogu użytkownika

Najlepszy model nie polega na pytaniu użytkownika przed każdą możliwą czynnością. Po kilkunastu komunikatach powstaje permission fatigue i człowiek zaczyna automatycznie wybierać „Zezwól”. Lepsze rezultaty daje prawidłowe ograniczenie przestrzeni roboczej już na początku.

Praktyczna konfiguracja powinna wyglądać następująco.

Poziom 1 — pojedynczy plik, wyłącznie odczyt.
To ustawienie domyślne. Jeżeli agent ma przeanalizować fakturę PDF albo przygotować opis dokumentu DOCX, dostaje dokładnie ten plik. Nie cały katalog, z którego dokument pochodzi.

Poziom 2 — wydzielony katalog roboczy.
Jeżeli zadanie wymaga kilkunastu dokumentów, tworzy się osobny folder, np. AI_TASK_2026-08-19, i kopiuje do niego tylko materiały niezbędne do operacji. Agent nie dostaje katalogu nadrzędnego.

Poziom 3 — zapis do osobnego miejsca.
Agent może generować wyniki do katalogu OUTPUT, ale nie powinien domyślnie nadpisywać plików źródłowych. Zapis nowej wersji umowa_v2.docx jest bezpieczniejszy niż automatyczne zastąpienie umowa.docx.

Poziom 4 — operacje destrukcyjne wymagają potwierdzenia.
Usunięcie, masowa zmiana nazw, przenoszenie plików i nadpisanie istniejącego materiału powinny mieć osobną kontrolę. Potwierdzenie musi pokazywać, co dokładnie zostanie zmienione, a nie tylko komunikat „agent potrzebuje dodatkowych uprawnień”.

Poziom 5 — wysłanie pliku poza urządzenie jest oddzielną decyzją.
To najważniejszy bezpiecznik. Zezwolenie na odczyt nie powinno automatycznie oznaczać zgody na przesłanie dokumentu do dowolnej domeny. Przed eksportem użytkownik powinien zobaczyć nazwę pliku i miejsce docelowe.

Na komputerze używanym zawodowo domyślnie wyłączyłbym agentowi dostęp do:

• całego katalogu domowego użytkownika;

• Dokumentów, Pulpitu i Pobranych jako kompletnych folderów;

• głównych katalogów OneDrive, Google Drive i Dropbox;

• udziałów sieciowych;

• profilu przeglądarki;

• baz i magazynów haseł;

• kluczy SSH i GPG;

• plików .env;

• katalogów zawierających sekrety API;

• kopii baz danych;

• eksportów kadrowych i księgowych;

• folderów z automatycznie wykonywanymi skryptami.

Szczególnie Pobrane jest kiepskim katalogiem roboczym. Zwykle mieszają się tam faktury, archiwa ZIP, instalatory, przypadkowe dokumenty od kontrahentów i pliki pobierane z Internetu. Dla agenta to niepotrzebnie szeroki zbiór danych, a dla użytkownika trudne miejsce do oceny, co właściwie zostało udostępnione.

W firmie warto pójść poziom niżej i ograniczyć narzędzie również na poziomie systemu operacyjnego. Agent uruchomiony z konta posiadającego prawa administratora ma znacznie większy potencjalny obszar szkód niż proces działający jako zwykły użytkownik z dostępem tylko do wydzielonego katalogu. Ograniczenie systemowe jest silniejsze niż instrukcja w promptcie, bo model nie może „przekonać” systemu plików, aby zignorował ACL.

Drugim dobrym zabezpieczeniem jest osobny profil przeglądarki. Profil używany przez agenta nie powinien automatycznie dziedziczyć wszystkich sesji, rozszerzeń i zapisanych danych z przeglądarki, w której pracownik ma bankowość, prywatną pocztę, CRM, system kadrowy i panel administracyjny firmy. Autonomia połączona z kilkunastoma aktywnymi sesjami SSO tworzy niepotrzebnie duży zasięg działania.

Dla wdrożenia firmowego stosuję jeszcze jedną zasadę: każda operacja opuszczająca granicę urządzenia jest traktowana ostrzej niż operacja lokalna. Agent może przeczytać dokument potrzebny do zadania, ale wysłanie go na zewnętrzną stronę, do poczty czy chmury wymaga nowej decyzji. W przypadku systemów umożliwiających polityki domenowe można dodatkowo ograniczyć miejsca docelowe do zatwierdzonej listy usług.

Potrzebny jest również ślad audytowy. Sensowny log powinien zawierać przynajmniej:

• czas operacji;

• rodzaj operacji — odczyt, zapis, usunięcie, upload;

• plik lub katalog, którego dotyczyła;

• stronę lub usługę, z którą agent w tym momencie pracował;

• miejsce docelowe w przypadku przesyłania danych;

• informację, czy operacja wymagała zatwierdzenia człowieka.

Bez takich danych po incydencie zostaje zgadywanie.

Najbardziej irytującym skutkiem tak restrykcyjnego modelu jest konieczność ręcznego przygotowania katalogu roboczego oraz częstsze zatwierdzanie operacji. To realny koszt. Zwykle jednak trwa to kilkadziesiąt sekund. Alternatywą jest agent, który dla wygody dostał dostęp do kilku lat dokumentów, wszystkich pobranych plików i aktywnych kont firmowych. Ta wymiana nie jest korzystna.

FAQ

Czy zwykła strona WWW może samodzielnie przeczytać cały dysk komputera?
Nie przez standardowe mechanizmy WWW. Użytkownik musi wskazać plik lub katalog albo wcześniej nadać aplikacji odpowiednie uprawnienie. Inaczej wygląda sytuacja z rozszerzeniem, aplikacją desktopową lub agentem wyposażonym w natywny dostęp do systemu plików — dlatego trzeba sprawdzić architekturę konkretnego narzędzia.

Czy dostęp tylko do odczytu jest bezpieczny?
Jest znacznie bezpieczniejszy od readwrite, ale nie chroni przed wyciekiem. Agent mający odczyt i możliwość wysyłania danych przez WWW nadal może ujawnić zawartość dokumentu.

Czy można dać agentowi dostęp do całego katalogu projektu programistycznego?
Dopiero po jego oczyszczeniu. Trzeba sprawdzić przede wszystkim .env, klucze prywatne, tokeny, lokalne bazy danych, kopie produkcyjnych konfiguracji i pliki z poświadczeniami. Bezpieczniejszym rozwiązaniem jest kopia projektu przygotowana specjalnie do pracy agenta.

Czy tryb incognito rozwiązuje problem?
Nie. Ogranicza część danych zapisywanych przez przeglądarkę, ale nie jest mechanizmem kontroli uprawnień agenta do systemu operacyjnego. Nie zastępuje wydzielonego katalogu, ograniczenia praw ani kontroli wysyłania plików.

Czy RODO zabrania używania agentów WWW do dokumentów zawierających dane osobowe?
Nie ma ogólnego zakazu. Organizacja musi jednak mieć odpowiednią podstawę i cel przetwarzania, ograniczyć zakres danych, zapewnić bezpieczeństwo oraz ustalić, co dostawca narzędzia robi z przesyłaną treścią. Przy rozwiązaniu chmurowym trzeba też sprawdzić umowę dotyczącą przetwarzania i faktyczny przepływ danych.

Jakie uprawnienie powinno wygasać po zakończeniu zadania?
W praktyce wszystkie uprawnienia do lokalnych danych, które nie są potrzebne do stałego działania aplikacji. Dla autonomicznego agenta najbezpieczniejszym ustawieniem domyślnym jest dostęp na czas konkretnej sesji lub zadania, a nie bezterminowa zgoda.

Od czego zacząć audyt już używanego agenta?
Najpierw sprawdzić, do jakich katalogów ma obecnie dostęp, czy zezwolenia są trwałe oraz czy odczyt plików jest połączony z możliwością automatycznego uploadu. Dopiero później warto analizować prompty i dodatkowe filtry bezpieczeństwa.

Pierwsza decyzja powinna być prosta: usunąć trwały, szeroki dostęp agenta do katalogów Dokumenty, Pobrane, Pulpitu i głównego folderu użytkownika, a następnie utworzyć osobny katalog roboczy zawierający wyłącznie pliki potrzebne do jednego zadania. Dopiero po takim ograniczeniu należy włączać zapis i automatyczne działania w WWW. Naprawianie promptów przed usunięciem nadmiernych uprawnień to odwrócona kolejność — źle zachowujący się agent bez dostępu do danych zrobi znacznie mniej szkód niż świetnie instruowany agent z kluczami do całego komputera.

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