Menedżer haseł był projektowany z prostym założeniem: to człowiek decyduje, kiedy i gdzie użyć zapisanych poświadczeń. Agent przeglądarkowy podważa właśnie to założenie. Potrafi czytać stronę, klikać elementy interfejsu, wypełniać formularze, przechodzić między serwisami i wykonywać wieloetapowe zadania. Jeżeli działa w profilu przeglądarki, w którym użytkownik ma odblokowany sejf albo aktywne sesje, dostaje znacznie więcej niż możliwość szybszego wpisania tekstu.
Nie oznacza to, że model AI nagle potrafi złamać szyfrowanie 1Password, Bitwardena czy innego poprawnie zaprojektowanego menedżera. Problem jest subtelniejszy. Nie trzeba odszyfrować całego sejfu, jeśli można doprowadzić do użycia właściwego sekretu we właściwym momencie. To przesuwa granicę bezpieczeństwa z kryptografii na interakcję między agentem, przeglądarką, rozszerzeniem i stroną internetową.
W praktyce administrator powinien dziś pytać nie tylko: „kto zna hasło?”, ale również: „jaki agent może spowodować użycie tego hasła, na jakiej stronie i bez czyjego udziału?”.
Od „zaszyfrowanego sejfu” do autonomicznego użytkownika przeglądarki
Klasyczny model zagrożeń dla menedżera haseł koncentrował się na kilku dobrze znanych problemach: kradzieży hasła głównego, przejęciu urządzenia, złośliwym rozszerzeniu, phishingu, błędzie implementacyjnym albo wycieku zaszyfrowanej bazy. Agent przeglądarkowy dodaje nową kategorię: legalnie uruchomione oprogramowanie, które ma wykonywać działania użytkownika, ale może błędnie zinterpretować cudzą instrukcję jako polecenie użytkownika.
To istotna różnica.
W typowym scenariuszu autofill menedżera haseł działa na podstawie dopasowania domeny. Jeśli poświadczenie zapisano dla example.com, rozszerzenie nie powinno zaoferować go na stronie examp1e.com. Taki mechanizm pozostaje bardzo dobrą ochroną przed tradycyjnym phishingiem. Nie rozwiązuje jednak problemu agenta, który otrzymał niebezpieczną instrukcję na jednej stronie, a następnie sam przejdzie na prawidłową domenę.
Przykładowy łańcuch ryzyka wygląda następująco:
-
agent analizuje stronę internetową, wiadomość, dokument albo komentarz zawierający indirect prompt injection;
-
treść próbuje przekonać model, że wykonanie dodatkowej czynności jest częścią zadania;
-
agent przechodzi do innego serwisu, w którym użytkownik ma aktywną sesję albo dostępny autofill;
-
korzysta z poświadczenia, kodu jednorazowego lub istniejącej sesji;
-
wykonuje czynność, której użytkownik nie zamierzał zlecać, albo próbuje przenieść dane do zewnętrznego miejsca.
Kluczowe jest słowo „używa”, a nie „kradnie”. Eksport całego sejfu nie jest konieczny, aby skutki były poważne.
Dobrze pokazuje to obecna architektura systemów agentowych. ChatGPT agent podczas logowania może oddać użytkownikowi kontrolę nad wirtualną przeglądarką; podczas takiego przejęcia nie wykonuje zrzutów ekranu z wpisywanym hasłem. Po zakończeniu logowania agent dostaje jednak z powrotem przeglądarkę, w której sesja jest już uwierzytelniona, a pliki cookie mogą pozostać aktywne między kolejnymi operacjami. To rozsądna bariera dla samego hasła, ale jednocześnie dobry przykład tego, dlaczego ochrona sekretu nie jest równoznaczna z ochroną konta.
Jeżeli agent może wykonywać operacje jako zalogowany użytkownik, w wielu scenariuszach hasło przestaje być najcenniejszym celem. Cenniejsza staje się sesja.
Podobnie należy patrzeć na rozszerzenia menedżerów haseł. W dokumentacji 1Password opublikowanej w sierpniu 2026 r. granica bezpieczeństwa autofill jest określona bardzo praktycznie: po świadomym wypełnieniu danych ich bezpieczeństwo zależy już również od strony, do której zostały przekazane. 1Password nie wypełnia loginu bez interakcji użytkownika i sprawdza zgodność domeny, ale sam producent zwraca uwagę na clickjacking, zwodnicze nakładki oraz złośliwe lub przejęte strony.
W środowisku agentowym pojawia się więc pytanie, którego kilka lat temu prawie nie trzeba było zadawać: czy kliknięcie wykonane przez model powinno być traktowane jak świadoma interakcja człowieka?
Jeżeli odpowiedź brzmi „tak”, część zabezpieczeń opartych na wymaganiu kliknięcia traci znaczenie. Jeżeli odpowiedź brzmi „nie”, potrzebna jest techniczna granica uniemożliwiająca agentowi wykonanie tej konkretnej interakcji.
To powinno być przedmiotem testu, a nie założenia.
Najgroźniejsze nie jest hasło główne. Najgroźniejsze są uprawnienia odziedziczone po użytkowniku
Pierwszy błąd przy wdrażaniu agentów polega na instalowaniu ich w tym samym profilu przeglądarki, którego pracownik używa przez cały dzień. W takim profilu znajdują się często jednocześnie:
-
rozszerzenie menedżera haseł,
-
sesja Microsoft 365 lub Google Workspace,
-
panel CRM,
-
system księgowy,
-
GitHub lub GitLab,
-
narzędzia administracyjne,
-
poczta,
-
panel hostingowy,
-
system płatności,
-
historia przeglądania i pobrane dokumenty.
To ogromny zestaw odziedziczonych uprawnień. Agent uruchomiony do niewinnego zadania — na przykład zebrania ofert dostawców — może otrzymać środowisko pozwalające równocześnie wejść do poczty zarządu i firmowego panelu administracyjnego.
Nie należy udostępniać agentowi całego środowiska tylko dlatego, że potrzebuje jednej strony.
Najlepszą pierwszą barierą jest osobny profil przeglądarki albo osobne środowisko wykonawcze. Profil agenta powinien zawierać wyłącznie konta potrzebne do jego zadań. Jeżeli agent nie potrzebuje menedżera haseł, rozszerzenia nie powinno tam być w ogóle.
Gdy dostęp do poświadczeń jest konieczny, bezpieczniejszy model wygląda inaczej:
-
Osobne konto dla automatyzacji. Nie konto pracownika i nie konto administratora.
-
Minimalny zakres uprawnień. Dostęp tylko do funkcji potrzebnych do konkretnego procesu.
-
Osobny sejf, kolekcja lub grupa poświadczeń. Agent nie powinien widzieć prywatnych haseł użytkownika ani credentiali do innych systemów.
-
Brak stałych uprawnień administracyjnych. Przywileje administratora powinny być nadawane czasowo, jeśli proces rzeczywiście ich wymaga.
-
Rejestrowanie operacji. Organizacja musi wiedzieć, kto lub jaki agent użył konta i co zrobił.
-
Mechanizm zatrzymania przed czynnością wysokiego ryzyka. Zmiana hasła, dodanie użytkownika, wygenerowanie klucza API, przelew czy modyfikacja uprawnień nie powinny przechodzić wyłącznie dlatego, że agent potrafi nacisnąć odpowiedni przycisk.
Dla kont szczególnie ważnych sensowne są passkeys albo sprzętowe klucze FIDO2/WebAuthn. Ograniczają ryzyko klasycznego phishingu, ponieważ uwierzytelnienie jest związane z właściwą domeną i klucz prywatny nie jest przekazywany stronie jak hasło.
Nie wolno jednak traktować passkey jako rozwiązania problemu agentów. Jeśli człowiek uwierzytelni się kluczem sprzętowym, a następnie odda agentowi zalogowaną sesję administracyjną, model nadal może działać z uprawnieniami tej sesji. Passkey chroni etap logowania. Nie ogranicza automatycznie tego, co agent zrobi po zalogowaniu.
Drugi często pomijany element to kody TOTP. Przechowywanie hasła i kodu jednorazowego w jednym menedżerze jest wygodne i nadal chroni przed wieloma realnymi atakami. W przypadku agenta oznacza jednak, że jedno odblokowane narzędzie może dostarczyć oba elementy potrzebne do logowania. Dla kont administracyjnych, finansowych i dostępu do infrastruktury lepsze jest rozdzielenie czynników — na przykład hasło w menedżerze, a drugi czynnik na sprzętowym kluczu wymagającym świadomego działania człowieka.
Jest tu również niewygodny aspekt użytkowy. Im więcej potwierdzeń, blokad i przełączeń profili wprowadzimy, tym mniej „autonomiczny” staje się agent. To nie błąd projektu. Autonomia i kontrola dostępu są w pewnym zakresie przeciwstawnymi wymaganiami. Agent, który może bez pytania wejść wszędzie, jest wygodny dokładnie z tego samego powodu, z którego jest niebezpieczny.
Jak zmienić politykę dostępu, zanim pierwszy agent dostanie firmowy profil
Przed dopuszczeniem agentów do prawdziwych kont warto przeprowadzić krótki audyt, który nie wymaga wielkiego programu bezpieczeństwa. Najpierw trzeba spisać trzy rzeczy: jakie przeglądarki obsługuje agent, jakie konta są w nich zalogowane i jaki menedżer haseł lub rozszerzenia są dostępne.
Najważniejsze pytanie kontrolne brzmi:
Czy agent ma techniczną możliwość dotarcia do danych lub funkcji wykraczających poza zadanie, które mu powierzamy?
Jeżeli tak, pierwszym działaniem powinna być izolacja środowiska, a nie poprawianie promptu.
Instrukcja typu „nigdy nie otwieraj menedżera haseł” jest pomocna, ale pozostaje instrukcją dla modelu. Nie zastępuje ograniczenia technicznego. Dużo mocniejszą barierą jest brak rozszerzenia w profilu, brak sesji administracyjnej albo konto bez odpowiednich uprawnień.
W praktyce warto przyjąć trzy klasy agentów.
Klasa 1 — agent bez dostępu do kont.
Przegląda publiczny internet, porównuje informacje, przygotowuje zestawienia. Nie posiada sejfu ani zalogowanych sesji. To powinien być wariant domyślny.
Klasa 2 — agent z ograniczonym kontem roboczym.
Może logować się do kilku wskazanych usług, ale korzysta z oddzielnych kont i minimalnych uprawnień. Tutaj potrzebne są logi, osobny profil i możliwość szybkiego unieważnienia sesji.
Klasa 3 — agent pracujący w środowisku uprzywilejowanym.
Dostęp administracyjny, finanse, infrastruktura, kadry, dane szczególnie wrażliwe. Taki model powinien wymagać świadomego udziału człowieka przy operacjach zmieniających stan systemu albo ujawniających sekrety. Pełna autonomia w tej klasie jest trudna do obrony.
Trzeba też przejrzeć ustawienia samego menedżera. Na przykład 1Password w aktualnej dokumentacji pozwala wyłączyć automatyczne wysyłanie formularza po autofill. To drobny parametr, ale w środowisku agentowym jest istotny: wypełnienie danych i ich wysłanie powinny być dwiema osobnymi operacjami, szczególnie gdy agent działa na stronach spoza ścisłej listy zaufanych domen.
W Bitwarden i innych rozwiązaniach warto sprawdzić przede wszystkim:
-
czas automatycznego blokowania sejfu;
-
zachowanie po zamknięciu przeglądarki;
-
dopasowanie URI dla zapisanych loginów;
-
sposób obsługi schowka;
-
możliwość dodatkowego potwierdzania dostępu do szczególnie wrażliwych wpisów;
-
politykę rozszerzeń narzuconą centralnie przez administratora;
-
logowanie zdarzeń i możliwość szybkiego odebrania dostępu.
Nie należy przy tym wyłączać autofill „na wszelki wypadek” w całej organizacji. Poprawnie działające dopasowanie domeny jest nadal istotnym zabezpieczeniem przed phishingiem. Ręczne kopiowanie haseł do schowka może zmniejszyć bezpieczeństwo zamiast je zwiększyć. Problemem jest nie sam autofill, lecz udostępnienie go autonomicznemu procesowi bez odpowiednich granic.
Polskie firmy objęte nowelizacją ustawy o krajowym systemie cyberbezpieczeństwa mają dodatkowy powód, żeby ten temat potraktować formalnie. Nowelizacja KSC weszła w życie 3 kwietnia 2026 r. i rozszerzyła obowiązki podmiotów kluczowych i ważnych w zakresie zarządzania ryzykiem cyberbezpieczeństwa. Podmioty spełniające kryteria w dniu wejścia ustawy w życie mają termin na wpis do Wykazu KSC do 3 października 2026 r., a zasadniczy okres dostosowawczy dotyczący m.in. systemu zarządzania bezpieczeństwem informacji kończy się 3 kwietnia 2027 r. Dla sektora finansowego dodatkową warstwą pozostaje DORA, stosowana od 17 stycznia 2025 r.
Agent z dostępem do firmowego sejfu nie powinien więc być traktowany jako zwykłe „narzędzie AI”. Z punktu widzenia zarządzania ryzykiem przypomina raczej nowego wykonawcę z dostępem do systemów, któremu trzeba określić tożsamość, zakres dostępu, zasady eskalacji, rejestrowanie działań oraz procedurę odebrania uprawnień.
Najbardziej praktyczna polityka sprowadza się do jednej zasady: agent nie powinien dziedziczyć uprawnień człowieka tylko dlatego, że korzysta z jego przeglądarki.
Więcej na ten temat na stronie: https://sajo.pl.
FAQ: agenci AI i menedżery haseł
Czy agent przeglądarkowy może odczytać cały mój sejf z hasłami?
Nie wynika to automatycznie z samego faktu korzystania z przeglądarki. Menedżery takie jak 1Password czy Bitwarden szyfrują zawartość sejfu i stosują własne mechanizmy kontroli dostępu. Realniejszym scenariuszem jest doprowadzenie do użycia pojedynczego pasującego poświadczenia albo wykorzystanie już zalogowanej sesji.
Czy wystarczy zablokować agentowi możliwość otwierania rozszerzenia menedżera haseł?
Nie. Agent może mieć dostęp do konta przez istniejące cookies sesyjne bez ponownego używania hasła. Ochrona sejfu musi iść w parze z izolacją profilu przeglądarki i ograniczeniem zalogowanych usług.
Czy passkeys rozwiązują problem?
Rozwiązują dużą część problemu phishingu i kradzieży haseł, ale nie chronią przed niewłaściwym działaniem agenta po utworzeniu uwierzytelnionej sesji. Dla kont uprzywilejowanych nadal potrzebne są ograniczenia uprawnień oraz potwierdzanie ryzykownych operacji.
Czy agent powinien korzystać z mojego osobistego sejfu?
Nie jest to dobry model dla zastosowań firmowych. Jeżeli automatyzacja rzeczywiście potrzebuje poświadczeń, powinna używać osobnego konta, osobnego zakresu sekretów i uprawnień ograniczonych do konkretnego procesu.
Czy trzeba całkowicie wyłączyć autofill?
Nie. Dopasowanie poświadczeń do domeny pozostaje skuteczną ochroną przed wieloma atakami phishingowymi. Lepiej ograniczyć dostęp agenta do rozszerzenia lub kont niż zmuszać wszystkich użytkowników do ręcznego kopiowania haseł.
Co jest bardziej niebezpieczne: dostęp do sejfu czy aktywna sesja?
W wielu procesach aktywna sesja. Jeżeli agent odziedziczy zalogowany panel administracyjny, pocztę albo system finansowy, nie musi znać hasła, żeby wykonać działania dostępne użytkownikowi.
Od czego zacząć zabezpieczanie agentów w firmie?
Od inwentaryzacji profili przeglądarkowych i aktywnych sesji. Najpierw usuń najbardziej niebezpieczny błąd: nie uruchamiaj agenta w codziennym profilu pracownika zawierającym menedżer haseł, pocztę i konta administracyjne. Utwórz osobny profil bez sejfu i dodawaj dostęp do kolejnych usług dopiero wtedy, gdy konkretne zadanie rzeczywiście go wymaga.
