Cloud Browser: Bezpieczna platforma przeglądarki zdalnej dla każdego agenta AI
Projekt referencyjny dla usługi przeglądarki zdalnej niezależnej od modelu: brama, procesory robocze, żywy obraz WebRTC, zatwierdzenia, zabezpieczenia przed SSRF, odtwarzanie oraz wszystkie ustawienia konfiguracyjne.
Agenty AI stały się dosyć sprawne w rozumieniu treści stron internetowych, jednak obsługa prawdziwego przeglądarki wciąż jest trudniejsza, niż się wydaje. Klikanie w przyciski to najłatwiejsza część. Agent przeglądarki, na którym ludzie mogliby polegać, musi utrzymywać sesje aktywne, radzić sobie z oknami dialogowymi i przekierowaniami, rozumieć dynamiczne interfejsy, zajmować się pobieraniem i przesyłaniem plików, umożliwiać człowiekowi przejęcie kontroli, chronić dane logowania, prosić o zgodę przed podjęciem kluczowych działań oraz później pokazywać, co tak naprawdę się wydarzyło.
Cloud Browser to rozwiązanie tego całego problemu: samodzielna usługa do uruchamiania przeglądarki, która nie przejmuje się tym, jaki model znajduje się po drugiej stronie.
Agent stacjonarny, asystent do kodowania w linii poleceń, klient MCP lub niestandardowa aplikacja – wszystkie one mogą go wykorzystywać. Usługa w ogóle nie zawiera LLM. Agent decyduje, co powinno się wydarzyć, podczas gdy Cloud Browser odpowiada za przeglądarkę, granice bezpieczeństwa, wykonywanie zadań, rzeczywisty widok, ślady działań oraz czyszczenie po zakończeniu.
To rozdzielenie jest najważniejszą decyzją architektoniczną w systemie. Zamieniając agenta, platforma przeglądarki pozostaje bez zmian. Aktualizując pracownika przeglądarki, agent nie wymaga przerabiania kodu. Polityka bezpieczeństwa funkcjonuje w ten sam sposób, niezależnie od tego, który klient się łączy.
Następne rozdziały omawiają architekturę, granice zaufania, model interakcji oraz decyzje inżynieryjne, które przekształcają automatyzację przeglądarki w coś, co przedsiębiorstwo może uruchomić.
Kontekst ogólny
Agent sztucznej inteligencji obsługuje zdalny przeglądarkę, podczas gdy osoba może obserwować przebieg działań, interweniować, zatwierdzać delikatne operacje, przeglądać skróty ekranu oraz później ponownie wykonać zadanie. Główny schemat działania jest celowo prosty:
User
|
v
AI agent or agent application
|
| HTTPS API or MCP
v
Cloud Browser gateway
|
v
Isolated browser worker
|
v
Website
Człowiek obserwuje i kieruje pracownikiem za pośrednictwem podpisanej transmisji na żywo WebRTC.
Dlaczego Playwright nie wystarcza
Playwright to doskonały silnik automatyzacji, ale nie jest produktem przeglądarki wielu użytkowników. Usługa produkcyjna musi odpowiadać na wiele pytań, których Playwright nigdy nie zadaje:
- Kto jest właścicielem danej przeglądarki?
- Jaka zadanie odpowiada za dany kartę?
- Czy drugi agent może ponownie użyć identyfikatora karty, którego mu nie przekazano?
- Co się dzieje, gdy następuje kliknięcie, ale odpowiedź sieci znika?
- Jak ktoś może się zalogować, bez konieczności przekazywania hasła do modelu?
- Co powstrzymuje przeglądarkę przed dostępem do punktów końcowych metadanych chmurowych lub prywatnych sieci?
- Kto ma kontrolę, gdy zarówno agent, jak i człowiek są połączeni?
- Jak w sposób bezpieczny przechowywać i pobierać zrzuty ekranu?
- Jakie dowody pozostają po nieudanej akcji?
Zamknięcie silnika w wyraźnych granicach usługi pozwala platformie odpowiadać na wszystkie te pytania w ten sam sposób za każdym razem.
Egzekucja bez planowania
Usługa realizuje żądania, ale nigdy nie planuje. Nie decyduje sama, czy transakcja zakupu powinna zostać sfinalizowana, czy wiadomość powinna zostać wysłana. Dzięki temu jest przydatna w różnych agentach i wyraźnie oddziela dwa zestawy obowiązków.
Z strony agenta:
- zrozumienie tego, czego chce użytkownik
- określenie następnego kroku
- interpretacja tego, co obecnie pokazuje przeglądarka
- zadanie pytania użytkownikowi, gdy intencja nie jest jasna
Z strony Cloud Browsera:
- autoryzacja osoby, która dzwoni
- izolacja sesji i kart od siebie
- wymuszanie przestrzegania zasad przeglądarki
- weryfikacja każdego celu
- realizacja działań
- żądać dowolnych skonfigurowanych zatwierdzeń
- transmitować transmisję na żywo z przeglądarki
- przechowywać ograniczoną ilość dowodów
- wyzwalać zasoby po zakończeniu pracy
Cele i przestarzałe odniesienia
Preferowane cele są semantyczne: przycisk, pole tekstowe, pola wyboru, pozycja w menu lub węzeł dostępności widoczny w bieżącym dokumencie. Aplikacje typu Canvas oraz silnie dostosowane interfejsy nadal wymagają współrzędnych, które są mniej stabilne. W takim przypadku Cloud Browser sprawdza lokalizację i podaje szczegóły dotyczące elementu znajdującego się dokładnie pod wskaźnikiem.
Agent może również określić rolę lub tekst widoczny, który oczekuje. Jeśli element w celu nie odpowiada temu opisowi, działanie zostaje przerwane, zamiast kliknąć coś niezamierzonego.
Strony zmieniają się cały czas. Okno modalne może pojawić się pomiędzy obserwowaniem a działaniem, menu nawigacyjne może zastąpić cały dokument, a okno popup może stać się aktywnym kontynuacją. Aby sobie z tym poradzić, referencje semantyczne są powiązane z konkretną wersją dokumentu. Każda modyfikacja lub zmiana nawigacji unieważnia wcześniejsze referencje, a próba użycia starej powoduje błąd stale_target. W rezultacie powstaje bezpieczny cykl:
Observe -> choose one action -> validate -> execute -> observe again
Gdzie znajdują się zasady
Zatwierdzenia i reguły sieciowe nie mogą istnieć wyłącznie w jednym interfejsie użytkownika, ponieważ inny klient mógłby się do niej połączyć bezpośrednio i je ominąć. Brama jest autorytatywnym punktem egzekwowania tych zasad. Aplikacje agentów mogą dodawać bardziej restrykcyjne zasady, ale żadna z nich nie może złagodzić tych ustalonych przez samą usługę.
Architektura systemu
Implementacja referencyjna składa się z trzech głównych pakietów oraz kilku usług wspomagających.
Agent clients
|
+-- Desktop agent UI
+-- Claude or another MCP client
+-- Codex or another coding agent
+-- Custom application or SDK
|
v
MCP adapter or direct HTTPS client
|
v
Cloud Browser gateway
|
+-- authentication and delegated identity
+-- tenant and task isolation
+-- request validation
+-- idempotency
+-- policy and approvals
+-- session manager
+-- signed live-view service
+-- audit and observability
|
v
Worker scheduler
|
v
Browser worker
|
+-- Playwright and restricted CDP
+-- tabs and popups
+-- semantic state
+-- browser actions
+-- screenshots and artifacts
+-- downloads and uploads
+-- WebRTC video source
+-- secure form filling
|
v
Approved web destinations
Brama
Brama udostępnia wersjonowany kontrakt HTTPS. Autoryzuje żądającego, określa rzeczywistą tożsamość użytkownika, sprawdza właściciela zadania, stosuje kwoty, egzekwuje zasady i przekazuje polecenie odpowiedniemu pracownikowi. Polecenia są przesyłane w powiązanym opakowaniu zawierającym wersję protokołu, identyfikator żądania, identyfikator zadania, opcjonalny identyfikator sesji, nazwę polecenia oraz ograniczone parametry. Polecenia zmieniające stan wymagają również klucza idempotencji.
Wyniki i błędy są zwracane w ustrukturyzowany sposób. Nie wolno, aby informacje wewnętrzne przeglądarki wyciekły poprzez losowe ślady wywołań lub surowe błędy dostawcy.
Adapter MCP
Agenty, które obsługują MCP, łączą się za pośrednictwem celowo uproszczonego adaptera. Chromium nigdy nie działa w jego wnętrzu, a on sam nie zawiera żadnych zasad dotyczących przeglądarki. Jego jedynym zadaniem jest mapowanie wywołań narzędzi na żądania bramy: otwieranie karty (browser_open_tab), odczytywanie stanu, klikanie, robienie zrzutu ekranu lub zamykanie sesji za pomocą odpowiednich narzędzi browser_*. W ten sposób kilka produktów agentów może dzielić się jedną bramą, a nic specyficzne dla danego dostawcy nie przenika do procesu roboczego.
Adaptator nie przekazuje modelowi podpisanych URL-ów do oglądania na żywo. Agent otrzymuje jedynie nieszkodliwe dane prezentacyjne: informację o tym, czy istnieje oglądanie na żywo, którą kartę pokazuje, kto ma kontrolę oraz kiedy dane te wygasają. Tylko zaufana interfejs użytkownika otrzymuje możliwość oglądania podpisanych treści.
Procesor przeglądarki
Każdy pracownik zarządza rzeczywistym procesem przeglądarki lub jej kontekstem. Karty, nawigacja, wydobywanie informacji semantycznych, wprowadzanie danych, zrzuty ekranu, pobieranie i przesyłanie plików, obsługa schowka, okna dialogowe oraz zdarzenia przeglądarki – wszystko przechodzi przez niego. Playwright zajmuje się większością zadań automatyzacyjnych, a niektóre operacje tylko do odczytu mogą aktywować ograniczone funkcje CDP. Pełny dostęp do CDP nigdy nie jest udostępniany jako rozwiązanie uniwersalne.
Ograniczenia te są istotne, ponieważ surowy CDP może uzyskać dostęp do plików cookie, pamięci przechowywania, celów debugowania, możliwości dowolnej ewaluacji oraz wewnętrznych elementów przeglądarki. Bezpieczny produkt udostępnia tylko te funkcje, których zadanie wymaga.
Menedżer sesji
Menedżer sesji kontroluje łańcuch uprawnień:
tenant
-> principal
-> task
-> session
-> tab
-> operation
Identyfikatory nieprzezroczyste są ograniczone do danej łańcuchowej struktury. Identyfikator karty wydany w ramach jednego zadań nie może być używany przez inne zadanie, nawet jeśli oba przypadkowo dzielą ten sam proces przeglądarki. Menedżer zajmuje się również umowami dzierżawy, czasem oczekiwania na bezczynność, stanem sterowania, kartami przechowywanymi, cyklem życia profilu oraz jego finalizacją.
Profile przeglądarki i trwałość danych
Istnieją trzy rodzaje profili. Profil tymczasowy służy do krótkotrwałych sesji i znika po zakończeniu zadania, co zapewnia najwyższy stopień izolacji przez domyślność. Profil zadania trwa tak długo, jak to zadanie, i pozostaje oddzielony od wszystkich innych zadań. Profil trwały umożliwia temu samemu użytkownikowi przechowywanie plików cookie oraz sesji wejścia na strony internetowe z jednego zadania do drugiego.
Chrome zezwala tylko na jeden aktywny proces na katalog profilu, więc zadania należące do tej samej osoby mogą dzielić się procesem przeglądarki, przy czym każde zadanie zachowuje własne karty, wybór, ramki w czasie rzeczywistym, stan skrawka przenośnego oraz uprawnienia kontrolne.
Profilami trwałymi wymagane są bardziej ścisłe kontrole operacyjne:
- Katalog profilu jest czytelny tylko dla jego właściciela.
- Podlegająca mu jednostka pamięci lub usługa przechowywania powinna szyfrować dane w stanie spoczynku.
- Użytkownicy potrzebują sposobu na wylogowanie się i usunięcie przechowywanego profilu.
- Dostęp jest ograniczony do konkretnego użytkownika i podmiotu.
- Czytanie historii przeglądania wymaga wyraźnej zgody.
- Pracownicy nigdy nie przekazują surowych plików cookie ani tokenów autoryzacyjnych z powrotem do agenta.
Życie cyklu jednego polecenia
Każda akcja przechodzi przez tę samą przewidywalną sekwencję:
- Osoba wywołująca usługę jest uwierzytelniana.
Gdy wystąpi awaria transmisji, a przeglądarka mogła już podjąć działanie, bramka odpowiada kodem outcome_unconfirmed. W takim przypadku klient musi dostosować stan przeglądarki w czasie rzeczywistym, zamiast ślepo powtarzać daną czynność. Jest to szczególnie ważne przy rezerwowaniu miejsc, wysyłaniu formularzy lub komunikatów, gdy automatyczna próba ponowna może spowodować podwójne efekty w rzeczywistym świecie.
Interaktywny widok w czasie rzeczywistym przez WebRTC
Wysyłanie zrzutów ekranu za pomocą protokołu agenta raz po raz byłoby wolniejsze, dlatego ścieżka WebRTC zmniejsza opóźnienia i zapobiega szybkiej wymianie informacji poprzez zwykłe odpowiedzi narzędzia. Współrzędne wskaźnika są mapowane w oparciu o rzeczywiste granice wideo, łącznie z paskami letterbox. Zdarzenia kółka myszy są normalizowane i łączone, skróty klawiszowe dostosowują się do platformy odbiorcy, a potwierdzenia rozróżniają dane w kolejce, te już dostarczone, zmienione, odrzucone oraz nadal w oczekiwaniu.
Przekazywanie kontroli tam i z powrotem
Odbiorca działa w trybie obserwacji, podczas gdy agent ma kontrolę. Osoba chcąca przejąć kontrolę klikuje w obszar przeglądarki lub naciska przycisk kontroli. Maszyna stanowa jest jasno zdefiniowana:
Agent control
-> handoff pending
-> user control
-> release pending
-> agent control
Any state
-> finalized
Chociaż użytkownik ma kontrolę, dane wprowadzane przez agenta są zablokowane. Kontrola jest ograniczona do konkretnej zadania i przechodzi na wybraną okno powiadomień, jeśli strona otworzy nowe okno. Stary kadr wideo nie może przekazać kontroli, a opóźniona wiadomość nie może cicho jej zwrócić agentowi, ponieważ brama pozostaje autorytetem decydującym o bieżącym stanie.
Ochrona samego odtwarzacza
Link do oglądania na żywo to krótkotrwała funkcja podpisana HMAC, powiązana z jednym użytkownikiem, podmiotem, zadaniem, sesją i kartą; wygasa ona po zakończeniu zadania. Funkcja tworzenia ram jest wyłączona domyślnie. Aby wmontować odtwarzacz w zaufane aplikacje agenta, plik konfiguracyjny musi wymienić każdy dokładny źródło w swojej polityce bezpieczeństwa treści; znaki zastępcze, ścieżki, dane uwierzytelniające, zapytania i fragmenty są odrzucane jako źródła do tworzenia ram.
Wszystko to ma na celu zapobieganie sytuacji, w której wrogi serwis internetowy wgrze widzera, umieści nad nim niewidzialną warstwę i oszuka użytkownika, skłaniając go do kliknięcia w przyciski takie jak „Przejąć kontrolę” lub „Zatwierdzić”.
Bezpieczne logowanie
Haseł nie wolno nigdy przekazywać modelowi, umieszczać w harmonogramie działań ani przechowywać w dzienniku audytowym. Dwa wzory logowania gwarantują to zachowanie.
Jeden z nich to ręczna kontrola: agent przekazuje przeglądarkę użytkownikowi, który loguje się bezpośrednio na stronie, a następnie kontrola wraca do agenta.
Inny wzorzec to dedykowany wyzwanie typu secure-auth. W tym przypadku procesor znajduje konkretne widoczne pola w bieżącym dokumencie, a zaufany przeglądarkowy widokownik pokazuje zaszyfrowaną formularz z danymi uwierzytelniającymi, w którym podano dokładny adres źródłowy. To, co wpisuje użytkownik, trafia bezpośrednio z widokownika do usługi wypełniania formularzy i do zweryfikowanych pól przeglądarki. Wyzwanie jest powiązane z adresem źródłowym, zadaniem, sesją i kartką, procesem generowania dokumentu, ścieżką ramki, selektorem, oczekiwanym typem pola oraz krótkim oknem ważności. Model może widzieć jedynie niezaszyfrowane szczegóły stanu.
Logowanie za pomocą QR również można przeprowadzać bezpiecznie. Procesor pobiera widoczną obrazkę QR, potwierdza, że można ją odszyfrować, usuwa odszyfrowany treść i pokazuje obrazek wyłącznie w zabezpieczonym, żywym widokowniku. Wartość przechowywana w QR nigdy nie trafia do agenta.
Zatwierdzenia przed podjęciem decyzyjnych działań
Zezwolenie na dostęp do strony internetowej oraz możliwość podjęcia tam określonej czynności to dwa odrębne decyzje. Pozwolenie agentowi na otwarcie strony restauracji nie upoważnia do dokonania rezerwacji, a dostęp do sklepu internetowego nie upoważnia do dokonania zakupu. Cloud Browser ocenia ryzyko w momencie wykonywania czynności. Zatwierdzenie może być wymagane w przypadku takich działań jak:
- brezowanie stolika lub umówienia się na spotkanie
- kupno czegoś lub dokonanie płatności
- modyfikacja kont lub uprawnień
- usuwanie czegokolwiek
- wysyłanie wiadomości w imieniu użytkownika
- przechowywanie danych logowania
- przesyłanie plików
- udzielanie uprawnień przeglądarce
- przekazywanie danych wrażliwych
Każda zatwierdzenie jest powiązana z jedną konkretną akcją, celem, miejscem docelowym, dokumentem oraz zestawem kategorii danych, dlatego staje się bezużyteczna po zmianie strony lub w przypadku innego przycisku. Wysyłanie danych poufnych jest oceniane oddzielnie, niezależnie od ostatecznej akcji. Wprowadzenie adresu e-mail do formularza firmy trzeciej może wymagać zatwierdzenia powiązanego z tym miejscem docelowym, zanim kliknięcie przycisku „Zatwierdź” poprosi o osobne potwierdzenie. To użytkownik pozostaje tym, który dokonuje zatwierdzenia; Cloud Browser je egzekwuje, a aplikacja agenta formułuje decyzję.
Zdjęcia ekranu, artefakty i odtwarzanie
Zdjęcia ekranu ułatwiają szybkie zrozumienie sytuacji, stanowią trwałe dowody oraz pomagają w diagnozowaniu awarii. Zdjęcie ekranu przesyłane w formie połączenia zawiera obraz do natychmiastowego wyświetlenia oraz nieprzezroczysty identyfikator artefaktu, przy czym żaden ścieżka pliku z systemu serwera nie trafia do agenta. Artefakty należą do odpowiedniego zadań, szybko wygasają, mają ograniczenia co do rozmiaru i liczby, są przekazywane przez zabezpieczone ścieżki, mogą być pobierane wyłącznie do skonfigurowanych lokalnych katalogów, a ich tworzenie odbywa się z uprawnieniami dostępnymi tylko dla właściciela, bez nadpisywania istniejących plików.
Udane przeglądanie strony może również tworzyć ograniczony chronologię zdjęć ekranu. Każda pozycja zawiera datę i godzinę, nazwę hosta, źródło, podsumowanie działań oraz opcjonalny artefakt w postaci zdjęcia ekranu. Suwak umożliwia użytkownikowi sprawdzenie wcześniejszego stanu przeglądarki, a wybór opcji LIVE powraca do bieżącej sesji WebRTC.
Sensywniejsze kroki podlegają specjalnemu traktowaniu. Wprowadzanie danych uwierzytelniających nigdy nie jest rejestrowane, a gdy dana akcja przekazuje informacje poufne, chronologia może zawierać jedynie minimalne metadane, celowo pomijając zrzut ekranu.
Funkcja odtwarzania wykracza poza czysto wizualne udogodnienie, ponieważ odpowiada na praktyczne pytania:
- Co było na ekranie u agenta tuż przed kliknięciem?
- Czy po drodze pojawiła się okno dialogowe?
- Czy jakiś inny element mógł znajdować się na wierzchu celu?
- Czy cokolwiek na stronie uległo widocznym zmianom później?
- Czy zadanie zostało zatrzymane na stronie lub w oczekiwaniu na zatwierdzenie użytkownika?
Okna dialogowe, przekierowania i nieprzyjemne strony
Rzeczywiste procesy pracy rzadko pozostają w jednej karcie. Proces rezerwacji może otworzyć okno powiadomień, dostawca tożsamości może przekierowywać użytkownika między kilkoma źródłami, dokument biurowy może próbować uruchomić aplikację na komputerze, a strona spotkania może oferować zarówno link do aplikacji, jak i alternatywę wersję internetową. Cloud Browser traktuje takie przejścia jako wydarzenia pierwszej klasy.
Jeśli jakieś działanie otwiera okno, platforma zgłasza nową kartę, wybiera ją do realizacji zadania i łączy z widokiem na żywo; gdy użytkownik przejmuje kontrolę, ona przechodzi na tę kartę. Jeśli strona próbuje uruchomić aplikację typu native, na przykład aplikację do spotkań, przeglądarka informuje o niedostępności zewnętrznej aplikacji, zamiast symulować udane kliknięcie. Jeśli strona ma bezpieczną alternatywę w przeglądarce, agent lub użytkownik może ją celowo wybrać.
Na platformie nie ma żadnych sposobów na obejście CAPTCHA, interstitiali związanych z bezpieczeństwem przeglądarki, barier płatności, wymagań dotyczących zaufania do urządzenia czy podobnych zabezpieczeń. Gdy pojawi się jedno z nich, jest to zgłaszane jako ograniczenie lub przekazywane użytkownikowi do rozwiązania.
Bezpieczeństwo sieciowe i SSRF
Ponieważ zdalna przeglądarka pełni również rolę klienta sieciowego, niekontrolowana nawigacja może sprawić, że stanie się ona narzędziem do SSRF. Adresy docelowe są rozwiązywane i weryfikowane przed połączeniem. Domyślnie są one odrzucane:
- celi typu loopback
- celi typu link-local
- służby metadanych chmurowych
- przestrzeni prywatne w stylu RFC1918
- przestrzeni multicast oraz innych rezerwowanych obszarów
- każdego schematu URL spoza listy obsługiwanych
Listy dopuszczalnych i zabronionych adresów dla poszczególnych użytkowników mogą to jeszcze bardziej usztywnić.
Pewne struktury korporacyjne wykorzystują podzielony DNS lub zabezpieczone bramy internetowe, które kierują zatwierdzone wewnętrzne nazwy hostów na prywatne adresy NAT lub adresy typu carrier-grade. Takie wyjątki muszą być jasno określone, wąsko sformułowane, ograniczone do zaufanych domen i ustawione poprzez konfigurację wdrożenia, aby dopasowana nazwa hosta nigdy nie stała się ogólnym sposobem dostępu do sieci prywatnej. Przekierowania, okna dialogowe, iframy, żądania od service-workerów oraz ponowne powiązanie DNS podlegają tej samej polityce sieciowej, ponieważ weryfikacja tylko pierwszego adresu URL jest niewystarczająca.
Iniekcja poleceń i niezaufany kontent strony
Procesor przeglądarki traktuje treść strony jako dane, a nie jako instrukcje. Strona może wyświetlać komunikat „zignoruj poprzednie instrukcje” lub publikować opis narzędzia twierdzący, że dana operacja jest bezpieczna, ale żadne z tych stwierdzeń nie nadaje żadnych uprawnień.
Narzędzia reklamowane przez stronę za pośrednictwem WebMCP są powiązane z adresem URL strony, generowaniem dokumentu, identyfikatorem rejestracji oraz zaobserwowanym schematem, a ich opisy nigdy nie są uważane za wiarygodne. readOnlyHint dostarczony przez stronę nie może ominąć procedury zatwierdzenia, chyba że implementacja wyraźnie zaufała dokładnemu temu źródłu w tym celu. Snapyty semantyczne podlegają tej samej zasadzie: rozumowanie dotyczące treści należy do agenta, natomiast przyznanie uprawnień przeglądarce zależy wyłącznie od bramy.
Pobieranie, przesyłanie i skrawka roboczego
Pobrane pliki są przechowywane jako elementy należące do konkretnego zadań, więc nie ujawnia się ścieżki pracownika. Do przesłania pliku potrzebny jest wybieracz plików powiązany z jakimś wydarzeniem oraz ścieżka źródłowa w ramach skonfigurowanej głównej ścieżki przesyłania. Linki symboliczne są rozstrzygane i odrzucane, jeśli wskazują na miejsca poza zatwierdzoną katalogiem, a przed umieszczeniem plików pracownik sprawdza, czy wybieracz przyjmuje jeden plik, czy wiele.
Każde zadanie ma swój własny stan skrzynki wycinków. Tekst oraz binarne elementy MIME mogą być synchronizowane za pośrednictwem widżetu w czasie rzeczywistym, przy czym uprawnienia przeglądarki są udzielane w ograniczonym zakresie i następnie cofane. W trwałym kontekście przeglądarki uprawnienie do skrzynki wycinków udzielone jednemu zadaniu nie może pozostać aktywne dla innego.
Życiowy cykl i czyszczenie
Czyszczenie musi być wykonywane nawet wtedy, gdy agent nigdy nie kończy swojej pracy prawidłowo. Usługa odbiera wyraźny sygnał zakończenia rundy, który rozróżnia rundy ukończone, przerwane, zatrzymane lub zatrzymane przez podagenta, a uruchamiane wtedy czyszczenie jest ograniczone i idempotentne. Każda karta może mieć jedną z trzech oznaczeń:
- karta aktywna, zamykana po zakończeniu rundy
- materiał do przekazania, przechowywany dla użytkownika
- przekazanie dalsze, pozostawione otwarte, aby użytkownik mógł kontynuować
Oznaczenia odnoszące się do konkretnej rundy są usuwane po ich realizacji, dlatego karta musi być celowo ponownie zachowana w późniejszej rundzie. Dodatkowe etapy czyszczenia pochodzą z umów sesyjnych, czasów oczekiwania przy bezczynności, wygaśnięcia artefaktów, usuwania nieaktywnych profili oraz bezawaryjnego wyłączania bramy.
Obserwowalność bez wycieku danych prywatnych
Łogi bramy rejestrują wydarzenia operacyjne związane z tworzeniem sesji, nawigacją, decyzjami polityki, przekazywaniem kontroli, mutacjami, awariami oraz czyszczeniem danych. Zapis audytowy powinien zawierać identyfikatory i wyniki, a nie dane uwierzytelniające czy treści stron. Adresy URL są w miarę możliwości skracane do bezpiecznych części, a zapytania, wartości formularzy, hasła, tokeny oraz dane osobowe są maskowane lub usuwane.
Przydatne sygnały operacyjne to:
- opóźnienia w bramie oraz w procesach
- liczba istniejących sesji i przeglądarek
- połączone strony WebRTC
- kategorie odmów polityki
- częstotliwość starych celów
- wyniki pozostające nieweryfikowane
- procesy, które nie udają się uruchomić
- skuteczność połączeń w trybie na żywo
- pliki utworzone i wygasłe
- nieudane operacje czyszczenia
Widz zgłasza, gdy wideo faktycznie przechodzi w stan odtwarzania, ponieważ samo utworzenie podpisanej URL nie dowodzi, że użytkownik może cokolwiek zobaczyć.
Niezawodność i testy obciążeniowe
Najgorsze błędy w automatyzacji przeglądarek są te niewidoczne: kliknięcie, które nic nie przyniosło, dane wprowadzone dwa razy, okno dialogowe, którego nikt nie zobaczył, lub działanie powtórzone po wygaśnięciu czasu oczekiwania. Dlatego poważny zestaw testów obejmuje znacznie więcej niż tylko standardową nawigację. Cloud Browser sprawdza te obszary:
- wielu użytkowników i sesji jednocześnie
- rozdzielenie zadań od wyników ich wykonywania
- mutacje, które muszą być idempotentne
- odniesienia do przestarzałych dokumentów
- obsługa okien dialogowych
- celowanie w elementy wewnątrz iframów i shadow roots
- ponowne łączenie się przez WebRTC
- konflikty podczas zmiany kontroli
- strony, które są zajęte lub na chwilę zamarzają
Testy obciążeniowe powinny łączyć rzeczywiste procesory Chromium z wieloma odbiorcami WebRTC jednocześnie. Testy jednostkowe dobrze pokrywają logikę zasad i protokołów, ale problemy z uruchamianiem przeglądarki, transmisją wideo, fokusem, wybieraniem okienek i dostarczaniem danych pojawiają się tylko przy rzeczywistym obciążeniu.
Model wdrażania
Architektura referencyjna może działać jako jeden węzeł, chociaż jej interfejsy są przeznaczone dla większej struktury kontroli produkcyjnej. Podstawowe wdrożenie łączy te elementy ze sobą:
TLS ingress
-> Cloud Browser gateway
-> isolated browser workers
-> encrypted profile and artifact volume
Brauser powinien działać jako użytkownik bez uprawnień specjalnych w odpowiednim profilu seccomp, z ograniczoną ilością CPU i pamięci oraz wystarczającą ilością pamięci współdzielonej dla Chromium. Kontenery stanowią praktyczny punkt wyjścia, a środowiska o wyższym ryzyku mogą wybrać jedną mikroVM na każdego pracownika brausera w celu lepszej izolacji.
Często dodawane elementy w implementacjach korporacyjnych to:
- logowanie przez OIDC dla konsoli samodzielnej
- autoryzacja typu maszyna-do-maszyny dla agentów
- identyfikator użytkownika końcowego przekazywany za pośrednictwem zaufanych backendów
- Redis do przechowywania rozproszonych certyfikatów i kluczy idempotencji
- PostgreSQL lub dedykowana platforma audytowa do rejestrowania trwałych zdarzeń
- szyfrowane magazynowanie obiektów dla plików
- planer, który umieszcza pracowników
- serwery TURN wydające krótkotrwałe uprawnienia WebRTC
- menedżer tajemnic z mechanizmem rotacji kluczy
- rozmieszczenie ruchu według regionów wraz z kontrolami rezydencji danych
Brama powinna być dostępna z zewnątrz wyłącznie przez HTTPS. Zwykły HTTP nie nadaje się do niczego poza specyficznym rozwojem w trybie loopback.
Konfiguracja, po jednej zmiennej
Plik env określa tożsamość sieciową bramy, zachowanie przeglądarki, mechanizmy przechowywania danych, izolację oraz granice polityki. Traktuj go jako konfigurację wdrażania, a nie jako źródło aplikacji. Poniższy przykład można bezpiecznie pokazać, ponieważ jego wartości mają charakter ilustracyjny i nie zawierają żadnych rzeczywistych tokenów ani sekretów służących do podpisywania:
CB_HOST=127.0.0.1
CB_PORT=8787
CB_PUBLIC_URL=http://127.0.0.1:8787
CB_TOKENS=replace-with-a-long-random-token:tenant-example:agent-service:delegate
CB_MAX_SESSIONS_PER_PRINCIPAL=8
CB_LIVEVIEW_SECRET=replace-with-a-separate-random-signing-secret
CB_LIVEVIEW_FRAME_ANCESTORS=http://localhost:8088,http://127.0.0.1:8088
CB_HEADLESS=true
CB_SERVICE_WORKERS=allow
CB_BROWSER_CHANNEL=chrome
CB_EXTENSION_PATHS=
CB_PROFILE_MODE=persistent
CB_PROFILE_DIR=./var/profiles
CB_ARTIFACT_DIR=./var/artifacts
CB_AUDIT_FILE=./var/audit.log
CB_USER_AGENT=
CB_ALLOW_ORIGINS=
CB_BLOCK_ORIGINS=
CB_TRUSTED_PRIVATE_ORIGINS=*.company.example
CB_ALLOW_CGNAT_NAVIGATION=true
CB_REQUIRE_APPROVAL=false
CB_ALLOW_LOOPBACK_NAVIGATION=true
CB_SYNTHETIC_MEDIA_DEVICES=true
CB_HOST
To interfejs sieciowy, na którym nasłuchuje brama.
CB_HOST=127.0.0.1
Z użyciem 127.0.0.1 usługa odpowiada tylko na żądania lokalnego komputera, co stanowi najbezpieczniejszy wybór podczas rozwoju interfejsu użytkownika agenta, adaptera MCP oraz bramy na jednym komputerze. Kontener może wymagać adresu 0.0.0.0, aby jego sieć lub proxy wejściowy mogły się do niego połączyć, ale to nie jest powód, by publikować ten port w Internecie; bramy produkcyjne działają za zabezpieczeniami w postaci autoryzowanego TLS, reguł firewall oraz uprawnień na poziomie usługi. Należy również pamiętać, że CB_HOST określa, gdzie proces nasłuchuje, a nie adresy URL w linkach do widoku na żywo, które są obsługiwane przez CB_PUBLIC_URL.
CB_PORT
To jest port TCP używany przez bramę.
CB_PORT=8787
Każda liczba od 1 do 65535 jest dopuszczalna, a domyślną wartością w rozwoju jest 8787. Numer ten musi być nieobsługiwany na wybranym interfejsie. Jeśli proxy odwrotny lub kontener używa innego zewnętrznego portu, CB_PORT pozostaje wewnętrznym portem odsłuchu, natomiast CB_PUBLIC_URL określa adres widoczny dla osób z zewnątrz.
CB_PUBLIC_URL
Publiczny adres bazowy to ten, który brama używa do tworzenia podpisanych linków do oglądania na żywo.
CB_PUBLIC_URL=http://127.0.0.1:8787
To coś więcej niż zwykła etykieta, ponieważ interfejs użytkownika otrzymuje na jej podstawie informacje o możliwościach widza, dlatego musi być dostępny z przeglądarki wyświetlającej transmisję na żywo. Rozwijanie lokalne obsługuje protokół HTTP loopback:
CB_PUBLIC_URL=http://127.0.0.1:8787
Dla zdalnego rozgłoszenia potrzebny jest źródło HTTPS dostępne z zewnątrz:
CB_PUBLIC_URL=https://browser.example.com
Nie umieszczaj w tym adresie URL ścieżek, zapytań, nazw użytkowników wplecionych w tekst, haseł ani surowych danych poufnych, a także zakończ protokół TLS na zaufanym punkcie wejścia lub bezpośrednio w bramce. Kolejna pułapka: 127.0.0.1 zawsze oznacza maszynę, na której się znajdujesz. Załóżmy, że interfejs użytkownika agenta działa na laptopie, a bramka znajduje się na serwerze w innym miejscu. Link przeznaczony do odtworzenia treści, utworzony przy użyciu 127.0.0.1, skieruje użytkownika z powrotem na laptopa i nigdy nie dotrze do bramki.
CB_TOKENS
Ta zmienna wymienia dane uwierzytelniające usług, które akceptuje bramka. Każda pozycja ma taki sam format:
<bearer-token>:<tenant-id>:<service-principal>[:scope]
Upoważnione kredencjały backendu wyglądają w ten sposób:
CB_TOKENS=replace-with-a-long-random-token:tenant-example:agent-service:delegate
Przecinki służą do oddzielania kilku wpisów. Pierwszym polem jest token nosiciela, który znajduje się w nagłówku HTTP Authorization; musi mieć co najmniej 20 znaków, być wygenerowany za pomocą szyfrowo bezpiecznego źródła losowości i przechowywany w menedżerze sekretów. ID najemcy stanowi najzewnętrzniejszą granicę izolacji, dzięki czemu sesje, zadania, profile, karty i artefakty nigdy jej nie przekraczają. Nazwa podmiotu określa usługę przechowującą dane uwierzytelniające, a bez delegacji sesje działają jako ten właśnie podmiot.
Opcjonalny zakres delegate umożliwia zaufanemu serwerowi backendowemu wysłanie nagłówka X-Cloud-Browser-Principal z nazwą rzeczywistego użytkownika końcowego. Sesja staje się wtedy własnością tego użytkownika, podczas gdy ślad audytowy oddzielnie rejestruje, który backend działał w jego imieniu. Przywilej delegacji powinny mieć wyłącznie zaufane aplikacje po stronie serwera. Klient stacjonarny czy zwykły token użytkownika nie powinien go otrzymać, ponieważ w przeciwnym razie mógłby podawać się za innego użytkownika w ramach konta.
Zarówno skonfigurowane, jak i prezentowane tokeny są haszowane przed porównaniem w czasie stałym, co zmniejsza ryzyko ujawnienia informacji na podstawie długości tokena, ale nie czyni wyciekłego tokena bezpiecznym. Należy natychmiast wymienić token, jeśli pojawi się on na zrzutce ekranu, w repozytorium, nagraniu terminala lub zgłoszeniu obsługi klienta. Nie należy go również używać ponownie jako CB_LIVEVIEW_SECRET, ponieważ oba chronią różne funkcje i wymagają niezależnej generacji.
CB_MAX_SESSIONS_PER_PRINCIPAL
To ogranicza maksymalną liczbę sesji jednoczesnych, które może utrzymywać jeden aktywny użytkownik.
CB_MAX_SESSIONS_PER_PRINCIPAL=8
Dozwolone wartości wynoszą od 1 do 128, przy czym domyślną wartością jest 8. Ten limit chroni przed przypadkowymi atakami z użyciem przeglądarek oraz niekontrolowanym działaniem agentów, a także zapobiega temu, by jeden użytkownik wyczerpał globalną pojemność; łączy się z ograniczeniem liczby sesji na poziomie bramy. Optymalna wartość zależy od pamięci procesora, mocy obliczeniowej CPU, trybu profilu oraz oczekiwanej jednoczesności działania. Nawet jeśli trwały profil dzieli proces przeglądarki pomiędzy różne zadania użytkownika, każde z tych zadań nadal zużywa zasoby tablicy, strumieniowania, plików artefaktowych oraz bramy.
CB_LIVEVIEW_SECRET
To jest klucz HMAC służący do podpisania funkcji obsługi oglądania na żywo.
CB_LIVEVIEW_SECRET=replace-with-a-separate-random-signing-secret
Każda informacja zawarta w podpisanym tokenie (tenant, principal, task, session, tab, expiry) jest objęta podpisem, więc zmiana którejkolwiek z nich unieważnia go. Rozwiązanie dostępne z zewnątrz wymaga własnego sekretu składającego się co najmniej z 32 znaków; w praktyce oznacza to co najmniej 32 losowe bajty w formacie hex lub Base64, pobrane z menedżera sekretów. Wyciek sekretu umożliwiłby atakownikowi posiadającemu wystarczające metadane sesji sfałszowanie funkcjonalności odtwarzacza. Rotacja unieważnia nowo zweryfikowane podpisy utworzone przy użyciu starego klucza, dlatego należy ją dostosować do terminu wygaśnięcia sesji live-view. Trzymaj tę wartość z dala od agentów, stron przeglądarki, pakietów klienta, dzienników i repozytoriów.
CB_LIVEVIEW_FRAME_ANCESTORS
To określa, które zaufane aplikacje internetowe mogą wstawiać podpisany odtwarzacz do iframe.
CB_LIVEVIEW_FRAME_ANCESTORS=http://localhost:8088,http://127.0.0.1:8088
Brama konwertuje tę listę na dyrektywę frame-ancestors w polityce bezpieczeństwa treści przeglądarki. Jeśli wartość jest pusta, przeglądarka wysyła frame-ancestors 'none' oraz X-Frame-Options: DENY, dzięki czemu funkcjonuje jako samodzielna strona, ale odrzuca możliwość wstawiania jej w inne strony. Jeśli podano konkretne źródła, tylko te dokładnie mogą ją zawierać w ramkach, a X-Frame-Options: DENY nie jest używany, ponieważ ten starszy nagłówek nie może określić kilku źródeł i unieważniłby listę dopuszczalnych adresów.
Wpisane wartości muszą być dokładnymi adresem HTTP lub HTTPS; ścieżki, dane uwierzytelniające w URL, zapytania, fragmenty oraz znaki wildcard są odrzucane. Scheme, host i port mają znaczenie, więc następujące trzy adresy stanowią odrębne źródła:
http://localhost:8088
http://127.0.0.1:8088
https://agent.example.com
To ustawienie nie ma związku z CORS. Chroni potężną stronę przeglądarki przed atakami typu clickjacking, dlatego należy wymienić tylko te interfejsy, które rzeczywiście potrzebują wyświetlenia żywej przeglądarki.
CB_HEADLESS
Kontroluje to, czy proces pracowniczy uruchamia przeglądarkę bez lokalnego okna pulpitu.
CB_HEADLESS=true
Gdy wartość wynosi true, Chromium lub Chrome działają bez interfejsu graficznego, a użytkownicy obserwują i kierują procesem za pośrednictwem transmisji na żywo WebRTC, zamiast przez lokalne okno Chrome. Serwery i kontenery zazwyczaj tego wymagają, ponieważ zużywa to mniej zasobów komputera i pozwala na automatyzację niezależną od sesji wyświetlania. Gdy wartość wynosi false, przeglądarka uruchamia się z interfejsem graficznym i wymaga działającego ekranu, zwykle wirtualnego, takiego jak Xvfb, lub obrazu pracownika do streamowania pulpitu w systemie Linux; natomiast w macOS otwiera oddzielne okno przeglądarki, chyba że architektura pracownika jest inna. Zmiana tej flagi nigdy nie powoduje przejęcia kontroli nad już otwartym osobistym oknem Chrome przez Cloud Browser – wpływa jedynie na sposób uruchamiania przeglądarki zarządzanej przez pracownika.
CB_SERVICE_WORKERS
To określa, czy strony internetowe mogą rejestrować i uruchamiać pracowników usługowych.
CB_SERVICE_WORKERS=allow
Wybierz allow lub block; block jest bezpiecznym standardowym ustawieniem. Aplikacje webowe typu Progressive Web Apps, aplikacje do spotkań, oprogramowanie biurowe oraz strony silnie skracane często polegają na service workers i mogą przestać działać, utknąć na ekranie ładowania lub wyglądać jakby były zamarłe bez nich. Włączenie ich poprawia kompatybilność, ale zwiększa zakres funkcji sieciowych i zarządzania danymi w przeglądarce, dlatego upewnij się wcześniej, że żądania service-worker nadal przestrzegają zasad nawigacji, reguł wyjścia, zapobiegania utracie danych oraz polityki użytkownika. Wybierz allow tylko dla zweryfikowanej aplikacji, która tego potrzebuje, a nie jako rozwiązanie ogólne.
CB_BROWSER_CHANNEL
To ustawienie wybiera kanał przeglądarki zainstalowany systemowo zamiast wbudowanego Chromium w Playwright.
CB_BROWSER_CHANNEL=chrome
Przyjmowane są cztery kanały: chrome, chrome-beta, chrome-dev oraz msedge. Jeśli pozostawi się to puste, zostanie użyty skonfigurowany plik wykonywalny Chromium lub pakiiet Playwright. Prawdziwe wersje Chrome lub Edge są czasami konieczne, gdy firma sprawdza zaufanie do urządzenia, zarządza przeglądarkami centralnie, wprowadza zasady lub wydaje certyfikaty klienta. Wybór chrome nie ładuje standardowego profilu użytkownika Chrome, ponieważ profile nadal pochodzą z CB_PROFILE_MODE i CB_PROFILE_DIR, więc Cloud Browser nie może bezgłośnie dołączyć do osobistej, interaktywnej sesji. Kanał musi być zainstalowany na serwerze roboczym, a zaufanie do urządzenia może wymagać również odpowiedniego profilu, zapisu systemu operacyjnego, certyfikatów, zasad lub rozszerzeń; sama ustawienie nie tworzy zaufania przedsiębiorstwa.
CB_EXTENSION_PATHS
Lista katalogów rozpakowanych rozszerzeń przeglądarki, oddzielona przecinkami.
CB_EXTENSION_PATHS=
Zostaw to puste, aby nie ładować rozpakowanych rozszerzeń. Wspomniane ścieżki są przekazywane zarządzanemu przeglądarce za pomocą flag do ładowania rozszerzeń, co działa tylko przy ustawieniu CB_HEADLESS=false oraz gdy CB_PROFILE_MODE ma wartość task lub persistent; tymczasowe konteksty i zwykłe uruchomienia bezinterfejsowe nie mogą bezpiecznie obsługiwać tego funkcjonowania. Ładowanie rozpakowanych plików przeznaczone jest do celów rozwojowych i kontrolowanych testów. Przedsiębiorstwa produkcyjne powinny wymuszać instalację zatwierdzonych rozszerzeń za pomocą polityk Chrome lub Edge, fiksujeć identyfikatory i aktualizować źródła, a także sprawdzać uprawnienia. Ponieważ rozszerzenie działa z uprawnieniami przeglądarki i może obserwować lub modyfikować aktywność w sieci, jego pochodzenie, ścieżka aktualizacji, uprawnienia oraz właściciel muszą zostać włączone do przeglądu bezpieczeństwa.
CB_PROFILE_MODE
To określa, w jaki sposób izolowana jest stan przeglądarki oraz jak długo utrzymuje się stan zalogowania.
CB_PROFILE_MODE=persistent
Ustawienie może być ephemeral, task lub persistent. W trybie ephemeral tworzony jest tymczasowy kontekst przeglądarki bez katalogu profilu, który można by ponownie wykorzystać – to najwyższy poziom izolacji, odpowiedni do anonimowego przeglądania lub pracy, która nie powinna pozostawiać żadnych śladów logowania. Tryb task tworzy katalog profilu tylko dla jednego zadań: pliki cookie i stan aplikacji istnieją tak długo, jak to zadanie, a po jego zakończeniu katalog profilu jest usuwany. Tryb persistent umożliwia współdzielenie jednego profilu pomiędzy zadaniami tego samego użytkownika i głównego podmiotu, dzięki czemu pliki cookie oraz sesje stron internetowych przetrwają nowe zadania i restarty bramy, choć każde zadanie zachowuje oddzielną własność karty, wybraną kartę, skrawnik, transmisje na żywo, pliki oraz informacje dotyczące kontroli. Tryb persistent jest najwygodniejszy, ale też najbardziej ryzykowny; należy używać szyfrowanego przechowywania, ścisłych uprawnień do katalogów, wyraźnych procedur logowania się i usuwania profilu oraz ograniczonego czasu bezczynności.
CB_PROFILE_DIR
Katalog główny, w którym znajdują się dane przeglądarki oparte na profilach.
CB_PROFILE_DIR=./var/profiles
Ścieżka względna odnosi się do katalogu roboczego procesu bramy. W kontenerach należy tutaj zamontować zabezpieczony wolumen, jeśli profile muszą przetrwać wymianę kontenera. Brama sama tworzy podkatalogi specyficzne dla użytkownika i podmiotu, i nigdy nie przyjmuje ścieżek profili wybranych przez agenty. Katalogi powinny być dostępne wyłącznie dla właściciela i nigdy nie powinny być udostępniane do pobrania. Nie należy ustawiać tego parametru na profil Chrome rzeczywistej osoby; kopiowanie lub jednoczesne otwieranie aktywnego profilu może go uszkodzić i narazić dane z przeglądania niepowiązane z nim na dostęp pracownika.
CB_ARTIFACT_DIR
Miejsce, w którym przechowywane są zrzuty ekranu należące do zadań, pliki pobrane, eksportowane treści, obrazy do odtworzenia oraz inne ograniczone artefakty.
CB_ARTIFACT_DIR=./var/artifacts
Drogi względne są ponownie rozstrzygane na podstawie katalogu roboczego bramy. Agenty otrzymują nieprzejrzyste ID artefaktów zamiast dróg, a każde pobieranie sprawdza informacje o użytkowniku, podmiocie, zadaniu, terminie ważności oraz właścicielu. Ustaw katalog jako dostępny do zapisu wyłącznie dla konta usługowego Cloud Browser, ogranicz czas trwania artefaktów, liczbę i rozmiar plików, usuwaj wygasłe pliki, szyfruj przechowywane dane i unikaj trzymania tymczasowych artefaktów w kopiach zapasowych nieograniczenie długo. Profile i artefakty służą różnym celom: zrzut ekranu może trafić do użytkownika, natomiast profil przeglądarki nigdy nie powinien być traktowany jako plik do pobrania.
CB_AUDIT_FILE
Droga do ograniczonego logu audytowego w formacie JSON Lines.
CB_AUDIT_FILE=./var/audit.log
Każdy wiersz stanowi zstrukturyzowane zdarzenie dotyczące na przykład utworzenia sesji, wykonywania polecenia, odrzucenia polityki, przeniesienia kontroli, wyniku połączenia w trybie rzeczywistym, zniszczenia sesji lub niepowodzenia przy czyszczeniu danych. Zapisuj, kto i co się wydarzyło, a nie wartości formularzy czy treść stron, oraz usuwaj lub maskuj dane uwierzytelniające, tokeny, zapytania oraz wrażliwe dane użytkowników. W środowisku produkcyjnym traktuj lokalne pliki JSONL jako format rozwojowy lub transportowy i przesyłaj zdarzenia na trwałą platformę audytową oferującą politykę przechowywania, kontrolę dostępu, ochronę integralności, powiadamiania oraz dochodzenia uwzględniające specyfikę poszczególnych użytkowników.
CB_USER_AGENT
Opcjonalna modyfikacja ciągu User-Agent przeglądarki.
CB_USER_AGENT=
Najlepiej pozostawić to puste. Narzędzie tworzy standardową tożsamość Chrome na podstawie wersji przeglądarki i dostarcza odpowiadające jej wskazówki dla klienta, unikając rozbieżności pomiędzy nagłówkiem żądania, navigator.userAgent a navigator.userAgentData. Spersonalizowana strona tekstowa zastępuje jedynie wartość User-Agent, bez tworzenia odpowiadających wskazówek, a niektóre dostawcy tożsamości oraz detektory botów wykrywają tę niezgodność. Nie używaj tego, aby przedstawić stary przeglądarkę jako nowszy lub obejść politykę bezpieczeństwa strony; zachowaj to do celów związanych z udokumentowanymi wymaganiami kompatybilności i sprawdź pełną tożsamość przeglądarki później.
CB_ALLOW_ORIGINS
Lista pozwolonych domen dla nawigacji użytkownika.
CB_ALLOW_ORIGINS=
Jeśli lista jest pusta, adresy publiczne HTTP i HTTPS są dopuszczane, chyba że interweniuje inna zasada, natomiast adresy sieci prywatnej, metadane, lokalne linki, adresy zarezerwowane oraz nieobsługiwane nadal przechodzą przez filtr sieciowy. Gdy lista zawiera już wpisy, każda nawigacja musi odpowiadać przynajmniej jednej zasadzie, sformułowanej jako dokładny adres źródłowy taki jak https://portal.example.com, sufiks z gwiazdką takty jak *.example.com lub sam nazwa hosta taka jak portal.example.com. Gdy liczy się schemat lub port, należy użyć dokładnego adresu źródłowego. Sufiks z gwiazdką obejmuje podstawową nazwę hosta wraz z jej poddomenami, więc należy je używać ostrożnie. Obecność w liście dopuszczalnych adresów nie upoważnia do korzystania z prywatnego IP, ponieważ klasyfikacja DNS oraz polityka zaufanych prywatnych źródeł są oceniane oddzielnie.
CB_BLOCK_ORIGINS
Jawny lista adresów źródłowych do odrzucenia.
CB_BLOCK_ORIGINS=
Zasady wykorzystują te same trzy formy co lista dozwolonych adresów, a najpierw sprawdza się tę listę, więc wszystko, co pasuje do obu list, jest blokowane. Typowymi zastosowaniami są wrażliwe punkty końcowe administracyjne, aplikacje niesprawdzane, znane niebezpieczne destynacje lub poddomeny, które należy usunąć z szerszej listy dozwolonych adresów. Klasyfikacja sieci ma zastosowanie nawet wtedy, gdy lista jest pusta.
CB_TRUSTED_PRIVATE_ORIGINS
Nazwy hostów korporacyjnych, które mogą odnosić się do adresów prywatnych lub CGNAT.
CB_TRUSTED_PRIVATE_ORIGINS=*.company.example
Powodem jego istnienia są konfiguracje split-DNS, w których nazwa hosta zatwierdzonej firmy rozwiązuje się inaczej w VPN lub sieci wewnętrznej. Zasady wykorzystują składnię listy nawigacyjnej. Ogranicz je do domen należących do organizacji i unikaj dodawania ogólnych znaków zastępczych lub nazw hostów tylko dlatego, że jakaś aplikacja zachowuje się niewłaściwie. Zaufane dopasowanie może umożliwić adresy typu RFC1918 lub CGNAT, ale nigdy adresy loopback, link-local, metadane chmurowe, multicast ani adresy zarezerwowane. Przeanalizuj je tak jak wyjątek SSRF – platforma musi mieć kontrolę nad DNS, ruchem wyjściowym oraz własnością każdego zaufanego sufiksu.
CB_ALLOW_CGNAT_NAVIGATION
Zezwala na nawigację do zakresu NAT typu carrier-grade, 100.64.0.0/10.
CB_ALLOW_CGNAT_NAVIGATION=true
Domyślnie ma wartość false. W niektórych sieciach firmowych VPN lub zabezpieczony bramkarz internetowy udostępnia usługi publiczne lub wewnętrzne pod adresem znajdującym się w przestrzeni CGNAT. Włączenie tego trybu umożliwia dostęp do tych usług i może wyłączyć ograniczenia dotyczące dostępu do sieci lokalnej w przeglądarce, które mogłyby zapobiec dotarciu strony do syntetycznego adresu. Jest to szersze podejście niż poleganie na jednym nazwie hosta, dlatego należy użyć CB_TRUSTED_PRIVATE_ORIGINS, jeśli potrzebne są tylko znane domeny firmy. Przestrzenie RFC1918, loopback, link-local, metadane, multicast oraz rezerwowane pozostają zamknięte, ale zasięg sieciowy nadal znacznie się rozszerza, więc należy to włączyć tylko w kontrolowanym środowisku korporacyjnym.
CB_REQUIRE_APPROVAL
Włącza ogólne mechanizmy zatwierdzania komend przez bramkarz internetowy dla tych, które są klasyfikowane jako istotne.
CB_REQUIRE_APPROVAL=false
Gdy wartość to true, polecenia o znaczeniu krytycznym są wstrzymywane do chwili otrzymania dokładnej zgody w momencie wykonywania. Gdy wartość to false, blokada zostaje zniesiona, co jest rozsądnym rozwiązaniem, jeśli zaufane aplikacje agentów już stosują surowsze zasady. Bezpieczeństwo jednak nie jest wyłączane. Uznawane za ryzykowne czynności, takie jak przesyłanie wrażliwych danych, ich usuwanie, transakcje płatnicze, rezerwacje, wysyłanie wiadomości w imieniu kogoś, zmiany konta lub uprawnień, dostęp do historii oraz używanie narzędzi na stronach nieklasfikowanych, nadal wymagają zgody. Kontrola dotyczy innego aspektu: działania agentów pozostają zablokowane, dopóki użytkownik kontroluje przeglądarkę. W przypadku produktu samodzielnego używanego przez kilku agentów zazwyczaj rozsądniej jest zachować włączone wymogi bezpieczeństwa, ponieważ wtedy bezpieczeństwo nie zależy od tego, czy każdy klient prawidłowo wdroży odpowiednie zasady.
CB_ALLOW_LOOPBACK_NAVIGATION
Przycisk rozwoju umożliwiający przeglądarce pracownika odwiedzanie adresów loopback (localhost, 127.0.0.1 lub ::1).
CB_ALLOW_LOOPBACK_NAVIGATION=true
Domyślnie wartość to false. Korzystają z tego testy automatyczne oraz aplikacje internetowe lokalne uruchamiane na tej samej maszynie co proces pracowniczy. Nie umożliwia on dostępu przeglądarce zdalnej do laptopa użytkownika, ponieważ w środowisku zdalnym 127.0.0.1 reprezentuje środowisko zdalne. Unikaj przypadkowego włączania tej opcji w środowisku produkcyjnym: dostęp typu loopback może ujawnić wewnętrzne porty administracyjne, serwery deweloperskie, interfejsy do debugowania oraz usługi zaprojektowane przy założeniu, że niezaufany treść internetowa nie będzie mogła do nich dotrzeć. Nawet po włączeniu nazwa hosta musi odwoływać się wyłącznie do adresów loopback, więc mieszana odpowiedź DNS nie może przekształcić tej wyjątkowej reguły w ogólne obejście.
CB_SYNTHETIC_MEDIA_DEVICES
Zapewnia przeglądarce zarządzanej syntetyczny mikrofon i kamerę.
CB_SYNTHETIC_MEDIA_DEVICES=true
Domyślnie wartość to również false. Przeglądarki bez interfejsu użytkownika często nie wykazują żadnych urządzeń multimedialnych, a niektóre strony do prowadzenia spotkań i nagrywania sprawdzają obecność mikrofonu lub kamery przed kontynuacją, więc strona wygląda, jakby utknęła, gdy żadne z tych urządzeń nie zostanie znalezione. Sztuczne urządzenia sprawiają, że te sprawdzenia kończą się pomyślnie: mikrofon pozostaje cichy, a kamera pokazuje wzór testowy zamiast rzeczywistego wideo. Nic tutaj nie rejestruje fizycznego mikrofonu ani kamery żadnej osoby i nigdy nie powinno być tak to opisywane. Jeśli pracownik dołącza do rzeczywistego spotkania, należy wyłączyć jego kamerę, chyba że ma być nadawany wzór testowy. Strona nadal może prosić o zgodę, a jej udzielenie to odrębna decyzja polityki niż samo udostępnienie urządzenia.
Odczytywanie przykładu jako jednej konfiguracji
Całość przykładowej konfiguracji opisuje lokalne środowisko rozwojowe:
- Brama przyjmuje tylko połączenia lokalne, na porcie
8787.
8088 pod dowolnym nazwą hosta.To działa jako lokalny profil integracji, ale nie stanowi bazy dla środowiska produkcyjnego. Przed uruchomieniem: przenieś publiczną adresację URL na HTTPS, rotuj wszystkie hasła i przechowuj je poza plikiem, wyłącz loopback, zawęż specyfikacje wyjątków dotyczących CGNAT i prywatnych źródeł, przeanalizz dostęp service-workera, włącz politykę zatwierdzania przez bramę, przechowuj profile i pliki na szyfrowanym zarządzanym magazynie oraz przekierowuj zdarzenia audytowe na trwałą platformę.
Łączenie agenta
Agent zdolny do obsługi MCP może uruchomić adapter jako lokalny proces i skierować go na bramę. Prawdziwe dane uwierzytelniające nie powinny znajdować się w systemie kontroli źródeł, dlatego użyj takich zmiennych zastępczych:
{
"mcpServers": {
"cloud-browser": {
"command": "node",
"args": ["/path/to/cloud-browser/packages/mcp/src/index.js"],
"env": {
"CB_GATEWAY_ENDPOINT": "https://browser.example.com/v1/browser",
"CB_GATEWAY_TOKEN": "retrieve-from-your-secret-manager",
"CB_DOWNLOAD_ROOTS": "/approved/output"
}
}
}
}
Typowa interakcja przebiega w następujący sposób:
Agent: browser_open_tab(url)
Cloud Browser: tab identifier, page metadata, safe live-view metadata
Agent: browser_get_state(tab)
Cloud Browser: revision-bound semantic state
Agent: browser_click(fresh target)
Cloud Browser: confirmed receipt, updated state, evidence
User: take control through signed viewer
Cloud Browser: block agent input
User: release control
Cloud Browser: restore agent input
Agent: browser_finalize_session()
Cloud Browser: close working tabs, revoke authority, expire artifacts
Jak to różni się od narzędzia przeglądarki wewnątrz jednego agenta
Wiele produktów typu agent dostarcza własne narzędzie przeglądarki. Cloud Browser ma służyć jako platforma przeglądarkowa dla wielu agentów, a jego wartość wynika z połączenia następujących cech:
- jest neutralny pod względem używanego modelu
- sesje są przechowywane zdalnie
- interakcja jest zarówno semantyczna, jak i wizualna
- WebRTC umożliwia obserwację i kontrolę
- hasła są przetwarzane w sposób bezpieczny
- brama kontrolna zapewnia zatwierdzenia
- skriny zapewniają dowody i możliwość odtworzenia
- dane artefaktów są powiązane z konkretnymi zadaniami
- czyszczenie odbywa się zgodnie z określonym cyklem życia
- identyfikacja przedsiębiorstwa, zasady oraz mechanizmy audytu są wbudowane
Istota tego rozwiązania sprowadza się do następującego:
Należy raz zaprezentować proces pracy, a następnie uruchomić go za pomocą dowolnego agenta AI, przy czym człowiek nadal może zatrzymać kolejne kroki.
Lekcje z budowy
Brauzer nie jest najtrudniejszą częścią; kluczowym elementem jest autorytet. Z projektu wynikło sześć lekcji.
Żywy widok to element związany z bezpieczeństwem, a nie tylko odtwarzacz wideo: zawiera kontrolki, zatwierdzenia, dane uwierzytelniające oraz intencje użytkownika, dlatego jego adres URL, zasady ramkowania, termin ważności oraz stan kontroli wymagają takiej samej uwagi jak funkcje API.
Przekazanie wiadomości to nie to samo, co zakończenie interakcji. Kliknięcie może nadejść, podczas gdy strona po prostu je ignoruje, dlatego dane wejściowe wymagają potwierdzenia, sprawdzenia strony później oraz oddzielnych oznaczeń dla stanów „przekazane”, „zmienione” i „nadal w oczekiwaniu”.
Bezsensowne próby ponawiane automatycznie są ryzykowne. Tam, gdzie działanie przeglądarki może mieć realne konsekwencje, konieczna jest izodempotencja oraz możliwość skorygowania błędów.
Sesje trwałe sprawiają, że produkt staje się bardziej przydatny, ale jednocześnie bardziej ryzykowny. Należy je izolować pod względem tożsamości i połączyć z funkcjami logowania się wylogowanego, przechowywania danych, historii działań oraz mechanizmami czyszczenia.
Traktuj treść stron oraz narzędzia dostarczane przez strony jako niezaufane. Strona może opisać dane działanie, ale nie ma uprawnień do jego zatwierdzenia.
Wreszcie, ograniczone dowody ułatwiają budowanie zaufania do automatyzacji. Dzięki chronologii zrzutów ekranu i podsumowaniom działań użytkownicy, programiści oraz operatorzy mogą łatwiej zrozumieć przyczyny awarii.
Jak to wygląda w praktyce
Agenci potrzebują przeglądarek, ale przedsiębiorstwa chcą czegoś więcej niż tylko skryptów. Pragną platformy z jasno określonym właścicielem, uprawnieniami, które wygasają, bezpieczną przekazującą się kontrolą między ludźmi, zabezpieczonym logowaniem, zatwierdzeniem przed jakimikolwiek działaaniami oraz możliwością obserwacji wyników i niezawodnego usuwania śladów.
Cloud Browser przekształca Playwright i Chromium w taką platformę, oddzielając planowanie od realizacji, agentów od danych uwierzytelniających oraz możliwości przeglądarki od uprawnień użytkownika. To rozdzielenie sprawia, że projekt można wykorzystywać wielokrotnie: wystarczy zastąpić agenta, model lub interfejs, a granice bezpieczeństwa wokół przeglądarki pozostają niezmienione. To właśnie stanowi podstawę, której potrzeba, zanim ludzie będą mogli naprawdę ufać automatyzacji przeglądarek.
Literatura pokrewna
- Praktyczne notatki: Budowanie agenta do programowania w prywatnej chmurze: OpenCode + lokalny LLM — Szczegółowy przewodnik po praktycznych notatkach dotyczących budowania agenta do programowania w prywatnej chmurze: OpenCode + lokalny LLM, w tym informacje o kontraktach, sprawdzaniach oraz miejscach na kod dostępnych dla zespołów wdrażających ten model.
- Budowanie agenta podtrzymywania LEPA za pomocą LangGraph — Implementacja elementów takich jak SupportState, węzły do przyjmowania i klasyfikacji zapytań, warunkowe krawędzie oraz elementy START/END, aby prośby o pomoc w szkole mogły zostać wyjaśnione lub skierowane do odpowiednich dokumentacji.