Back to archive
#ai#news#aigen#agents#security

Chmurowa przeglądarka ChatGPT Work zachowuje sesje po logowaniu

ChatGPT Work może od 25 sierpnia 2026 roku wykonywać zadania w obsługiwanych serwisach wymagających logowania. Hasło trafia do zdalnej przeglądarki bez udostępniania go modelowi, lecz powstała po logowaniu sesja może pozostać aktywna dla kolejnych zadań. Ta różnica określa praktyczny model zagrożeń: ochronę hasła trzeba oceniać osobno od uprawnień, które ma już uwierzytelniona przeglądarka.

Sesja po logowaniu pozostaje dostępna dla kolejnych zadań

Co się wydarzyło

W informacji o wydaniu z 25 sierpnia 2026 roku OpenAI dodało do chmurowej przeglądarki ChatGPT Work obsługę witryn wymagających uwierzytelnienia. Gdy zadanie dochodzi do ekranu logowania, agent zatrzymuje się, a użytkownik wpisuje nazwę konta, hasło i ewentualny kod drugiego składnika w wydzielonym formularzu. Po zalogowaniu agent odzyskuje kontrolę i może kontynuować zadanie w ramach uprawnień tego konta.

Dokumentacja opisuje zdalną przeglądarkę uruchomioną na infrastrukturze OpenAI, z osobnymi ciasteczkami, historią i stanem logowania. Nie dziedziczy ona kart, haseł ani sesji z lokalnej przeglądarki użytkownika. Powstała po uwierzytelnieniu sesja może jednak działać w późniejszych zadaniach, dopóki nie wygaśnie albo użytkownik nie usunie danych danej witryny w ustawieniach Cloud browser.

Co potwierdzają źródła

Instrukcja chmurowej przeglądarki stwierdza, że wartości wpisane w bezpiecznym formularzu trafiają bezpośrednio do zdalnej przeglądarki. Według OpenAI model nie widzi nazwy użytkownika ani hasła, a firma nie przechowuje ich jako poświadczeń. Przed wyświetleniem formularza dodatkowy model ma oceniać adres i stronę pod kątem phishingu lub oszustwa. Są to deklaracje dostawcy; nie znalazłem niezależnego audytu tego przepływu.

Sesja uwierzytelniona jest oddzielnym sekretem. Serwis może przyjmować jej ciasteczko zamiast ponownego sprawdzania hasła i drugiego składnika. Notebookcheck zwraca uwagę, że ochrona surowego hasła nie usuwa uprawnień zapisanych w sesji. Użytkownik odwołuje ten dostęp przez usunięcie danych witryny z chmurowej przeglądarki albo przez mechanizmy unieważniania sesji udostępnione przez sam serwis.

OpenAI rozdziela zgodę na wejście do witryny od zgody na działanie wywołujące skutek. Domyślne Always ask wymaga zgody przed otwarciem nowej witryny. Auto approve przekazuje ocenę adresu dodatkowemu mechanizmowi, a Always allow usuwa tę kontrolę i nie jest zalecane przez dostawcę. Płatność, rezerwacja lub inna istotna czynność ma nadal wymagać osobnego potwierdzenia. Publiczna dokumentacja nie definiuje jednak kompletnej listy takich czynności ani wyników testów skuteczności tych blokad.

Dokumentacja bezpieczeństwa Work Cloud opisuje zadania jako procesy działające w izolowanych maszynach wirtualnych na współdzielonej infrastrukturze OpenAI. Stan wykonania jest przypisany do uwierzytelnionego użytkownika, a środowisko może zostać ponownie użyte albo zastąpione z zachowaniem części stanu. Usunięcie rozmowy, odłączenie aplikacji i skasowanie danych przeglądarki są osobnymi operacjami. Dokumentacja zaznacza również, że eksport zgodności nie musi obejmować każdej interakcji przeglądarki.

Test MacStories potwierdził działanie na iPhonie dla prostego formularza oraz zachowanie sesji, z której później można było skorzystać na Macu. Ten sam autor nie zdołał uruchomić funkcji w Safari na Macu; część serwisów blokowała automatyzację, interfejs przejęcia kontroli czasem się zawieszał, a CAPTCHA wymagała ręcznego wykonania kilku prób. To mały test funkcjonalny, a nie ocena bezpieczeństwa.

Dokumenty OpenAI nie są w pełni spójne co do dostępności. Informacja o wydaniu przypisuje logowanie do planów Plus i Pro. Aktualna instrukcja przeglądarki mówi szerzej o płatnych planach poza Free i Go, z zastrzeżeniem wdrażania etapami i polityk workspace. Nie należy z tych zapisów wyprowadzać jednolitej listy planów i regionów.

Co mówi dyskusja

Najbardziej konkretna publiczna obserwacja dotyczy współbieżności. W zgłoszeniu numer 41517 użytkownik opisał pojedynczy przypadek z 29 sierpnia: po nieudanym przekazaniu kontroli w jednej rozmowie interfejs pokazał kartę należącą do innego równoległego zadania na tym samym koncie. Autor nie stwierdził ujawnienia poświadczeń ani przejęcia zalogowanej sesji. Zgłoszenie nie ma niezależnej reprodukcji, ale precyzyjnie formułuje wymaganie: zadanie powinno mieć widocznego właściciela kontekstu przeglądarki, blokadę współbieżnego dostępu i bezpiecznie przerwać pracę, gdy własności karty nie da się ustalić.

Pozostała dyskusja jest zbyt skąpa, by opisywać stanowisko szerszej społeczności. Pytanie na r/ChatGPT wskazuje brak dokumentacji o czasie bezczynności i wygaśnięciu sesji, ale nie zawiera pomiarów. Wątek na r/privacy sprowadza się głównie do dwóch argumentów: przechowywanie tokenu sesji jest oczekiwanym mechanizmem przeglądarki, a umieszczenie go w zdalnym środowisku wymaga jasno opisanej kontroli i sposobu odwołania. Komentarze nie dostarczają dowodów na incydent bezpieczeństwa.

Wnioski

  • Fakt — pewność wysoka: od 25 sierpnia 2026 roku ChatGPT Work obsługuje logowanie do wybranych witryn w chmurowej przeglądarce, a sesja może pozostać aktywna dla kolejnych zadań. Potwierdzają to informacja o wydaniu, bieżąca dokumentacja i test MacStories.
  • Wniosek — pewność wysoka: sesję zdalnej przeglądarki należy chronić jak uprawnienie do konta, nawet jeśli model nie otrzymuje hasła. Ważne są zakres konta, czas życia sesji, odwołanie dostępu i osobne zatwierdzanie operacji ze skutkiem zewnętrznym.
  • Wniosek — pewność średnia: obecne dowody uzasadniają zaczynanie od kont o małych uprawnieniach i zadań tylko do odczytu, z ustawieniem Always ask oraz usuwaniem danych przeglądarki po pracy. Pewność nie jest wysoka, ponieważ nie opublikowano niezależnej oceny zabezpieczeń ani pełnych reguł zatwierdzania działań.
  • Scenariusz — pewność niska: bez jawnej izolacji lub blokady kontekstu przeglądarki dwa równoległe zadania na jednym koncie mogą pomylić karty i stan nawigacji. Podstawą jest jedno niezweryfikowane zgłoszenie, które nie wykazało dostępu do cudzej sesji ani poświadczeń.

Czego jeszcze nie wiemy

  • Jaki jest maksymalny czas życia zapisanej sesji, czy bezczynność go skraca i jak szybko działa unieważnienie sesji po stronie serwisu.
  • Czy kontekst przeglądarki jest izolowany per rozmowa, per zadanie czy tylko per konto użytkownika oraz jak system rozstrzyga dostęp równoległy.
  • Które operacje zawsze wymagają zatwierdzenia i jak często klasyfikator przepuszcza albo błędnie blokuje działania.
  • Jak mechanizmy wykrywania phishingu i pośredniego prompt injection zachowują się na danych z uwierzytelnionych aplikacji; OpenAI nie opublikowało wyników dotyczących tej wersji przeglądarki.
  • Jaka jest ostateczna dostępność funkcji według planu, regionu i ustawień organizacji.
  • Które kliknięcia, odczyty, zapisy i decyzje przeglądarki trafiają do logów dostępnych administratorowi.

Źródła

Źródła pierwotne

Niezależne analizy i relacje

Dyskusje publiczne

Wykorzystuję treści generowane przez AI jako część mojego codziennego procesu nauki.