Cloud-Browser: Eine sichere Remote-Browser-Plattform für jeden KI-Agenten
Ein Referenzdesign für einen modellunabhängigen Remote-Browser-Service: Gateway, Worker-Prozesse, Live-Ansicht über WebRTC, Freigabeverfahren, SSRF-Schutzmechanismen, Wiedergabe sowie alle Konfigurationseinstellungen.
AI-Agenten sind in der Lage, über Webseiten zu reasoningen, doch das Steuern eines echten Browsers bleibt schwieriger, als es scheint. Das Klicken von Buttons ist der einfachere Teil. Ein Browser-Agent, auf den man sich verlassen kann, muss Sessions am Laufen halten, mit Pop-ups und Umleitungen umgehen, dynamische Benutzeroberflächen verstehen, Downloads und Uploads verarbeiten, es einem Menschen ermöglichen, die Kontrolle zu übernehmen, Zugangsdaten schützen, vor bedeutungsvollen Schritten um Erlaubnis bitten und anschließend zeigen, was tatsächlich passiert ist.
Cloud Browser ist eine Lösung für dieses gesamte Problem: ein eigenständiger Browser-Exekutionsdienst, der sich nicht darum kümmert, welches Modell auf der anderen Seite steht.
Ein Desktop-Agent, ein Assistent für die Kommandozeilen-Programmierung, ein MCP-Client oder eine benutzerdefinierte Anwendung können alle davon Gebrauch machen. Der Service enthält überhaupt kein LLM. Der Agent entscheidet, was geschehen soll, während Cloud Browser für den Browser, die Sicherheitsgrenzen, die Ausführung, die Echtzeitansicht, die Nachweisspur sowie die Aufräumarbeiten verantwortlich ist.
Diese Trennung ist die bedeutendste architektonische Entscheidung im System. Wechselt man den Agenten, bleibt die Browser-Plattform unverändert. Erstellt man einen Browser-Worker auf einem neueren Stand, muss der Agent nicht neu geschrieben werden. Die Sicherheitsrichtlinien verhalten sich unabhängig davon, welcher Client anfragt, auf dieselbe Weise.
Im Folgenden wird die Architektur, die Vertrauensgrenzen, das Interaktionsmodell sowie die ingenieurtechnischen Entscheidungen erläutert, die die Browser-Automatisierung zu etwas machen, das ein Unternehmen betreiben kann.
Das große Ganze
Ein KI-Agent steuert einen entfernten Browser, während eine Person zusehen, eingreifen, sensible Aktionen genehmigen, Screenshot ansehen und die Aufgabe später erneut ausführen kann. Der oberste Ablauf ist absichtlich einfach gehalten:
User
|
v
AI agent or agent application
|
| HTTPS API or MCP
v
Cloud Browser gateway
|
v
Isolated browser worker
|
v
Website
Die Person beobachtet und steuert den Mitarbeiter über eine signierte Live-Ansicht von WebRTC.
Warum Playwright nicht ausreicht
Playwright ist ein hervorragender Automatisierungsmechanismus, doch es handelt sich dabei nicht um ein Produkt für mehrere Benutzer im Browser. Ein Produktionsservice muss zahlreiche Fragen beantworten, die Playwright niemals stellt:
- Wer besitzt einen bestimmten Browser?
- Welche Aufgabe ist für ein bestimmtes Tab verantwortlich?
- Könnte ein zweiter Agent einen Tab-Identifikator wiederverwenden, der ihm nicht gegeben wurde?
- Was passiert, wenn ein Klick erfolgt, aber die Netzwerkanfrage nicht ankommt?
- Wie kann jemand sich anmelden, ohne dass das Passwort jemals beim Modell ankommt?
- Was verhindert, dass der Browser auf Cloud-Metadaten-Endpunkte oder private Netzwerke zugreift?
- Wer hat die Kontrolle, wenn sowohl der Agent als auch die Person verbunden sind?
- Wie werden Screenshot sicher gespeichert und heruntergeladen?
- Welche Beweise bleiben erhalten, wenn eine Aktion fehlschlägt?
Durch die Einbettung des Engines in eine klare Servicegrenze kann die Plattform auf all diese Fragen jedes Mal auf dieselbe Weise antworten.
Ausführung ohne Planung
Der Service führt Anfragen aus, plant aber nicht. Er entscheidet nicht eigenmächtig, ob ein Kauf abgewickelt oder eine Nachricht gesendet werden soll. Dadurch bleibt er in verschiedenen Agenten nutzbar und schafft eine klare Trennung zwischen zwei Aufgabengebieten.
Auf der Agentenseite:
- Erkennen, was der Benutzer möchte
- Den nächsten Schritt festlegen
- Das aktuell Anzeigeteil im Browser interpretieren
- Sonst den Benutzer um Klarstellung bitten, wenn die Absicht unklar ist
Auf der Seite des Cloud Browsers:
- Jeden Anrufer authentifizieren
- Sessions und Tabs voneinander isolieren
- Die Browserrichtlinien durchsetzen
- Jedes Ziel überprüfen
- Aktionen ausführen
Ziele und veraltete Referenzen
Bevorzugte Ziele sind semantisch: ein Button, ein Textfeld, eine Kontrollkästchen, ein Menüpunkt oder ein Zugänglichkeitsknoten im aktuellen Dokument. Canvas-Anwendungen sowie stark angepasste Benutzeroberflächen benötigen weiterhin Koordinaten, die weniger stabil sind. In solchen Fällen prüft der Cloud Browser die Position und gibt detaillierte Informationen über das Element preis, das sich tatsächlich unter dem Zeiger befindet.
Ein Agent kann außerdem die erwartete Rolle oder den sichtbaren Text angeben. Wenn das Element am Ziel nicht übereinstimmt, scheitert die Aktion, anstatt versehentlich auf etwas anderes geklickt zu werden.
Seiten ändern sich ständig. Ein Modalfenster kann zwischen Beobachten und Handeln eingeschoben werden, eine Navigation kann das gesamte Dokument ersetzen und ein Popup kann zur aktiven Fortsetzung werden. Um damit umzugehen, sind semantische Referenzen an eine Dokumentversion gebunden. Jede Änderung oder Navigation macht frühere Referenzen ungültig, und der Versuch, eine alte zu verwenden, führt zu einem stale_target-Fehler. Das Ergebnis ist ein sicheres Schleifenverhalten:
Observe -> choose one action -> validate -> execute -> observe again
Wo die Richtlinien liegen
Auswahl- und Netzwerkrichtlinien können nicht nur in einer Benutzeroberfläche gespeichert werden, sonst könnte ein anderer Client sich direkt verbinden und sie überspringen. Das Gateway ist der autoritative Durchsetzungspunkt. Agentenanwendungen können strengere Richtlinien darauf aufbauen, doch keine kann die eigenen Richtlinien des Services lockern.
Systemarchitektur
Die Referenzimplementierung umfasst drei Hauptpakete sowie einige unterstützende Dienste.
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
Der Gateway
Der Gateway stellt einen versionierten HTTPS-Vertrag zur Verfügung. Er authentifiziert den Aufrufer, ermittelt die tatsächliche Benutzeridentität, überprüft das Eigentumsrecht an Aufgaben, wendet Quoten an, setzt Richtlinien durch und leitet den Befehl an den richtigen Worker weiter. Die Befehle werden in einem korrelierten Paket übertragen, das eine Protokollversion, eine Anfrage-ID, eine Aufgaben-ID, optional eine Sitzungs-ID, den Befehlnamen sowie begrenzte Parameter enthält. Befehle, die den Zustand ändern, benötigen außerdem einen Idempotenzschlüssel.
Ergebnisse und Fehler werden strukturiert zurückgegeben. Interna des Browsers dürfen nicht durch zufällige Stack-Traces oder rohe Fehler des Anbieters nach außen dringen.
Der MCP-Adapter
Agenten, die MCP unterstützen, verbinden sich über einen absichtlich schlichten Adapter. Chromium läuft darin niemals, und er enthält keine Browserrichtlinien. Seine einzige Aufgabe besteht darin, Tool-Aufrufe in Gateway-Anfragen umzuwandeln: ein Tab öffnen (browser_open_tab), den Zustand lesen, klicken, einen Screenshot machen oder eine Sitzung über die entsprechenden browser_*-Tools abschließen. Mehrere Agentenprodukte können somit einen einzigen Gateway teilen, ohne dass etwas herstellerspezifisches in den Worker eindringt.
Von dem Adapter werden signierte Live-View-URLs vor dem Modell zurückgehalten. Was der Agent erhält, sind harmlose Präsentationsdaten: ob eine Live-View vorhanden ist, welcher Tab angezeigt wird, wer die Kontrolle hat und wann sie abläuft. Nur die vertrauenswürdige Benutzeroberfläche erhält jemals die signierte Viewer-Funktion.
Der Browser-Worker
Jeder Worker verfügt über den eigentlichen Browser-Prozess oder -Kontext. Tabs, Navigation, semantische Extraktion, Eingabe, Screenshots, Downloads, Uploads, Verwaltung des Zwischenkopiers, Dialoge sowie Browser-Ereignisse laufen alle über ihn. Playwright übernimmt den größten Teil der Automatisierung, und einige nur zum Lesen bestimmte Operationen können eingeschränkte CDP-Funktionen aktivieren. Ein unbegrenzter CDP-Zugriff wird niemals als Allheilmittel bereitgestellt.
Diese Einschränkung ist wichtig, denn der rohe CDP-Zugriff kann auf Cookies, Speicher, Debugging-Ziele, beliebige Auswertungen sowie interne Browserkomponenten zugreifen. Ein sicheres Produkt stellt nur die geringsten Funktionen bereit, die eine Aufgabe benötigt.
Der Sitzungsmanager
Der Sitzungsmanager besitzt die Autoritätskette:
tenant
-> principal
-> task
-> session
-> tab
-> operation
Opaque Identifikatoren sind auf diese Kette beschränkt. Ein Tab-Identifikator, der unter einer Aufgabe ausgestellt wird, kann von keiner anderen Aufgabe verwendet werden, selbst wenn beide zufällig denselben zugrunde liegenden Browser-Prozess teilen. Der Manager kümmert sich außerdem um Leasing-Verträge, Inaktivitätszeitlimits, Kontrollzustände, gespeicherte Tabs sowie um den Lebenszyklus und die Abschlussverarbeitung der Profile.
Browserprofile und Persistenz
Es gibt drei Arten von Profilen. Ein vorübergehendes Profil existiert nur für eine kurze Sitzung und verschwindet, wenn die Aufgabe beendet ist – dies gewährleistet standardmäßig die stärkste Isolation. Ein Aufgabenprofil hält so lange an wie eine bestimmte Aufgabe und bleibt von allen anderen Aufgaben getrennt. Ein persistentes Profil ermöglicht es demselben Benutzer, Cookies sowie angemeldete Website-Sitzungen von einer Aufgabe zur nächsten beizubehalten.
Chrome erlaubt pro Profildateiordner nur einen aktiven Prozess, sodass Aufgaben derselben Person denselben Browserprozess teilen können, während jede Aufgabe ihre eigenen Tabellen, Auswahlmöglichkeiten, Live-Fenster, Zwischenablagezustand sowie Steuerungsrechte beibehält.
Persistente Profile erfordern strengere Betriebskontrollen:
- Der Profildateiordner ist nur für seinen Besitzer lesbar.
- Der zugrunde liegende Datenträger oder Speicherdienst sollte die Daten im Ruhezustand verschlüsseln.
- Benutzer benötigen eine Möglichkeit, sich abzumelden und das gespeicherte Profil zu löschen.
- Der Zugriff ist auf den genauen Nutzer und das jeweilige Konto beschränkt.
- Das Lesen der Suchhistorie erfordert ausdrückliche Genehmigung.
- Arbeitnehmer geben niemals Roh-Cookies oder Authentifizierungstoken an einen Agenten zurück.
Das Leben eines Befehls
Jede Aktion folgt derselben vorhersehbaren Abfolge:
- Der Anrufer des Services wird authentifiziert.
Falls nach einem Transportfehler der Browser bereits gehandelt hat, antwortet das Gateway mit outcome_unconfirmed. Der Client muss dann den aktuellen Browserzustand abgleichen, anstatt den Schritt blind zu wiederholen. Das ist besonders wichtig bei der Buchung einer Reservierung, dem Absenden eines Formulars oder des Versendens einer Nachricht, wo ein automatischer Neversuch zu doppelten Auswirkungen in der Realität führen kann.
Echtzeitansicht über WebRTC
Es ist schwierig, einem Cloud-Browser zu vertrauen, den niemand sehen kann, daher bietet Cloud Browser eine interaktive Echtzeitansicht über WebRTC. Das Video fließt als Medienspur, während Zeiger-, Tastatur-, Zwischenablage-, Status-, Genehmigungs- und Übertragungsevents über einen geordneten DataChannel übertragen werden. HTTP wird nur für begrenzte Angebot- und Antwort-Signale verwendet, und es gibt keinen sekundären WebSocket-Bildstrom.
Das wiederholte Senden von Screenshotn über ein Agentenprotokoll wäre langsamer, daher verringert der WebRTC-Weg die Latenz und verhindert eine schnelle Abfolge von Interaktionen im Vergleich zu normalen Tool-Antworten. Die Zeigerkoordinaten werden innerhalb der tatsächlichen Grenzen des Videos abgebildet, einschließlich der Letterbox-Balken. Mausereignisse werden normalisiert und zusammengefasst, Tastenkürzel richten sich nach der Plattform des Betrachters, und Bestätigungen unterscheiden zwischen in der Warteschlange befindlichen, übermittelten, geänderten, abgelehnten sowie noch ausstehenden Eingaben.
Wechsel des Kontrollübergangs
Der Betrachter beginnt im Beobachtungsmodus, während der Agent die Kontrolle hat. Eine Person beantragt die Kontrolle, indem sie auf die Browseroberfläche klickt oder die Kontrolltaste drückt. Die Zustandsmaschine ist eindeutig definiert:
Agent control
-> handoff pending
-> user control
-> release pending
-> agent control
Any state
-> finalized
Obwohl der Benutzer die Kontrolle hat, wird die Eingabe des Agenten blockiert. Die Kontrolle ist auf die Aufgabe beschränkt und wechselt bei Öffnen eines neuen Fensters durch eine Website auf das ausgewählte Popup. Ein veraltetes Videoframe kann keine Kontrolle übertragen, und eine verzögerte Nachricht kann die Kontrolle nicht leise an den Agenten zurückgeben, da das Gateway weiterhin für den aktuellen Zustand zuständig bleibt.
Schutz des Viewers selbst
Der Live-View-Link ist eine kurzlebige, mit HMAC signierte Funktion, die an einen einzigen Mieter, Benutzer, Auftrag, Sitzung und Tab gebunden ist und beim Ende der Aufgabe erlischt. Framing ist standardmäßig deaktiviert. Um den Viewer in einer zuverlässigen Agentenanwendung einzubetten, listet die Bereitstellung jede genaue übergeordnete Herkunftsadresse in ihrer Content Security Policy auf; Wildcards, Pfade, Anmeldeinformationen, Abfragen und Fragmente werden als Framing-Herkünfte abgelehnt.
All das schützt davor, dass eine feindliche Website den Viewer einbettet, eine unsichtbare Schicht darüber legt und den Benutzer dazu bringt, auf Kontrollen wie „Kontrolle übernehmen“ oder „Genehmigen“ zu klicken.
Sicheres Anmelden
Ein Passwort darf niemals zurück zum Modell gelangen, in einer Aktionstimeline landen oder im Audit-Log erscheinen. Zwei Anmeldeverfahren halten dieses Versprechen ein.
Eines dieser Verfahren ist die manuelle Steuerung: Der Agent gibt den Browser an den Benutzer weiter, der sich direkt auf der Website anmeldet, und anschließend kehrt die Kontrolle zum Agenten zurück.
Das andere Muster ist eine spezielle secure-auth-Challenge. Hier sucht der Worker nach den konkreten sichtbaren Feldern im aktuellen Dokument, und der vertrauenswürdige Anzeigeeinrichtung wird ein maskiertes Anmeldeformular angezeigt, das den genauen Zielort angibt. Was der Benutzer eingibt, gelangt direkt vom Anzeigeeinrichtung zum Formularausfülldienst und in die validierten Browserfelder. Eine Challenge wird mit dem Origin, der Aufgabe, der Sitzung und dem Tab, der Dokumentgenerierung, dem Frame-Pfad, dem Selektor, dem erwarteten Feldtyp sowie einem kurzen Ablaufzeitfenster verknüpft. Nur nicht-geheime Statusdetails sind für das Modell sichtbar.
Auch das anmeldungsbasierte Verfahren mit QR-Codes kann sicher umgesetzt werden. Der Worker erfasst das sichtbare QR-Bild, überprüft, ob es decodiert werden kann, vernichtet die decodierte Nutzlast und zeigt das Bild ausschließlich im sicheren Live-Anzeigeeinrichtung. Der Inhalt des QR-Codes erreicht niemals den Agenten.
Zustimmungen vor folgenschweren Aktionen
Dass jemand auf eine Website zugreifen darf und dass ihm eine daraus resultierende Aktion gestattet wird, sind zwei getrennte Entscheidungen. Dass ein Agent die Seite eines Restaurants öffnen darf, berechtigt nicht zur Buchung, und der Zugang zu einem Online-Shop berechtigt nicht zum Kauf. Cloud Browser bewertet das Risiko, wenn die Aktion ausgeführt wird. Für Dinge wie folgende kann eine Genehmigung erforderlich sein:
- die Reservierung eines Tisches oder eines Termins
- den Kauf von Waren oder das Bezahlen
- die Bearbeitung von Konten oder Berechtigungen
- das Löschen von Inhalten
- das Versenden von Nachrichten im Namen des Benutzers
- die Speicherung von Anmeldedaten
- das Hochladen von Dateien
- die Gewährung von Browserberechtigungen
- die Übermittlung sensibler Daten
Jede Freigabe ist an eine bestimmte Aktion, ein Ziel, einen Bestimmungsort, ein Dokument sowie eine bestimmte Gruppe von Datenkategorien gebunden, wodurch sie nach einer Änderung der Seite oder bei Verwendung eines anderen Buttons nutzlos wird. Der Versand sensibler Daten wird unabhängig von der endgültigen Aktion geprüft. Das Eingeben einer E-Mail-Adresse in ein Formular eines Drittanbieters könnte eine Freigabe, die an diesen Bestimmungsort gebunden ist, erfordern, bevor der abschließende „Senden“-Klick eine weitere Bestätigung anfordert. Der Benutzer bleibt derjenige, der die Freigabe erteilt; Cloud Browser sorgt für die Durchsetzung, und die Agentenanwendung formuliert die Entscheidung.
Screenshots, Artefakte und Wiedergabe
Screenshots helfen bei schnellem Verständnis, liefern nachhaltige Beweise und dienen der Fehlerdiagnose. Ein Screenshottestrom gibt ein Bild zur sofortigen Anzeige sowie eine undurchsichtige Artefakt-ID zurück, wobei kein Server-Dateisystempfad jemals beim Agenten ankommt. Artefakte gehören zur zugehörigen Aufgabe, verfallen schnell, haben Größen- und Anzahlengrenzen, werden über signierte Routen übertragen, können nur in konfigurierte lokale Verzeichnisse heruntergeladen werden und werden mit ausschließlich für den Eigentümer gültigen Berechtigungen geschrieben, ohne dass eine vorhandene Datei überschrieben wird.
Ein erfolgreicher Surfbetrieb kann außerdem eine begrenzte Screenshottimeline erstellen. Jeder Eintrag enthält ein Zeitstempel, den Hostnamen, die Herkunft, eine Zusammenfassung der Aktion sowie optional ein Screenshott Artefakt. Ein Slider ermöglicht es dem Benutzer, einen früheren Browserzustand anzusehen, und die Auswahl von LIVE führt zurück zur aktuellen WebRTC-Sitzung.
Sensible Schritte erhalten eine spezielle Behandlung. Die Eingabe von Zugangsdaten wird niemals aufgezeichnet, und wenn eine Aktion sensible Informationen überträgt, enthält die Zeitachse nur minimale Metadaten und weist absichtlich auf Screenshots hin.
Replay geht über eine rein visuelle Ergänzung hinaus, denn es beantwortet praktische Fragen:
- Was war auf dem Bildschirm des Agents unmittelbar vor dem Klick?
- Isste unterwegs ein Pop-up aufgetaucht?
- Könnte ein anderes Element über dem Zielobjekt gelegen haben?
- Hat sich danach etwas auf der Seite sichtbar verändert?
- Ist die Aufgabe auf der Website stecken geblieben oder wartete sie auf die Genehmigung des Benutzers?
Pop-ups, Umleitungen und unhandliche Seiten
Reale Arbeitsabläufe bleiben selten in einem einzigen Tab. Ein Buchungsprozess kann ein Pop-up öffnen, ein Identitätsanbieter kann über mehrere Quellen hinweg wechseln, ein Bürodokument kann versuchen, eine Desktop-Anwendung zu starten, und eine Meeting-Seite kann sowohl einen App-Link als auch eine Web-Alternative anbieten. Cloud Browser behandelt solche Übergänge als erstklassige Ereignisse.
Falls eine Aktion ein Fenster öffnet, meldet die Plattform den neuen Tab, wählt ihn für die Aufgabe aus und integriert ihn in den Live-View; sobald der Benutzer die Kontrolle übernimmt, wechselt diese auch auf diesen Tab. Versucht eine Seite beispielsweise, ein natives Protokoll wie eine Meeting-App zu starten, gibt der Browser an, dass die externe Anwendung nicht verfügbar ist, anstatt einen erfolgreichen Klick vorzutäuschen. Falls die Website eine sichere Browser-Alternative bietet, kann der Agent oder der Benutzer diese absichtlich auswählen.
Nichts auf der Plattform umgeht CAPTCHAs, Sicherheitsfenster im Browser, Paywalls, Anforderungen an Gerätevertrauen oder ähnliche Schutzmaßnahmen. Wenn eines dieser Elemente auftaucht, wird es als Einschränkung gemeldet oder direkt an den Benutzer weitergeleitet.
Netzwerksicherheit und SSRF
Da ein entfernter Browser auch als Netzwerkclient fungiert, könnte eine unkontrollierte Navigation dazu führen, dass er zu einem SSRF-Tool wird. Die Zieladressen werden vor der Verbindung des Workers aufgelöst und überprüft. Standardmäßig werden folgende Adressen abgelehnt:
- Loopback-Ziele
- Link-Local-Ziele
- Der Cloud-Metadaten-Dienst
- Private Adressbereiche im RFC1918-Stil
- Multicast- sowie sonstige reservierte Adressbereiche
- Jedes URL-Schema außerhalb der unterstützten Liste
Per-Mietner erstellte Allowlists und Blocklisten können diese Sicherheitsmaßnahmen weiter verschärfen.
Bei bestimmten Unternehmenskonfigurationen werden geteilte DNS-Systeme oder sichere Web-Gateways eingesetzt, die genehmigte interne Hostnamen auf private oder carrier-grade NAT-Adressen verweisen. Solche Ausnahmen müssen explizit definiert sein, eng gefasst, auf vertrauenswürdige Domains beschränkt und über die Bereitstellungskonfiguration festgelegt werden, damit ein passender Hostname niemals zu einer allgemeinen Verbindung zum privaten Netzwerk wird. Umleitungen, Popups, Iframes, Service-Worker-Anfragen sowie DNS-Rebinding fallen weiterhin unter dieselbe Netzwerkpolicy, da eine Überprüfung nur der ersten URL unzureichend ist.
Schnell injizierte Befehle und unzuverlässiger Seiteninhalt
Der Browser-Worker behandelt den Seiteninhalt als Daten und niemals als Anweisungen. Eine Seite kann „Ihre vorherigen Anweisungen ignorieren“ anzeigen oder eine Toolbeschreibung veröffentlichen, die behauptet, eine bestimmte Aktion sei sicher – doch keiner dieser Angaben verleiht irgendeine Autorität.
Die über WebMCP von einer Seite beworbenen Tools sind an die Seite-URL, die Dokumentenerstellung, einen Registrierungsidentifikator sowie das beobachtete Schema gebunden, und ihre Beschreibungen dürfen niemals als zuverlässig angesehen werden. Ein von der Seite bereitgestellter readOnlyHint kann die Freigabeprozesse nicht umgehen, es sei denn, die Bereitstellung hat ausdrücklich genau diesen Ursprung zu diesem Zweck als vertrauenswürdig eingestuft. Semantische Snapshots folgen derselben Regel: Die Beurteilung des Inhalts obliegt dem Agenten, doch die Gewährung von Berechtigungen für den Browser liegt ausschließlich beim Gateway.
Downloads, Uploads und der Zwischenablage
Heruntergeladene Dateien werden als dem Auftrag zugehörige Artefakte aufbewahrt, sodass der Pfad des Arbeitsprozesses nicht offenbart wird. Für ein Hochladen ist ein Dateiauswähler erforderlich, der an ein Ereignis gebunden ist, sowie ein Quellpfad innerhalb einer konfigurierten Hochladeroot-Struktur. Symbolische Verknüpfungen werden aufgelöst und abgelehnt, wenn sie auf einen Ort außerhalb des genehmigten Verzeichnisses verweisen. Bevor die Dateien gesetzt werden, prüft der Arbeitsprozess, ob der Dateiauswähler eine oder mehrere Dateien auswählt.
Jeder Auftrag verfügt über seinen eigenen Zwischenablagezustand. Texte sowie begrenzte binäre MIME-Elemente können über den Live-Viewer synchronisiert werden, wobei die Browserberechtigungen streng eingeschränkt erteilt und danach wieder entzogen werden. In einem persistenten Browserkontext darf eine dem einen Auftrag erteilte Zwischenablageberechtigung nicht weiterhin für einen anderen Auftrag gültig sein.
Laufzeitzyklus und Aufräumen
Die Aufräumarbeiten müssen auch dann ausgeführt werden, wenn der Agent niemals sauber abschließt. Der Dienst erwartet ein explizites Signal zum Ende des Schritts, das abgeschlossene, unterbrochene, gestoppte sowie durch einen Unteragenten gestoppte Schritte unterscheidet, und die dadurch initiierten Aufräumarbeiten sind begrenzt und idempotent. Jede Karteikarte kann eine von drei Markierungen aufweisen:
- eine aktive Karteikarte, die am Ende des Schritts geschlossen wird
- ein Ergebnis, das für den Benutzer aufbewahrt wird
- eine Weiterleitung, die offen bleibt, damit der Benutzer fortfahren kann
Markierungen, die auf einen bestimmten Schritt beschränkt sind, werden nach ihrer Bearbeitung gelöscht, weshalb eine Karteikarte in einem späteren Schritt absichtlich erneut gespeichert werden muss. Weitere Aufräumarbeiten erfolgen durch Sitzungsverträge, Inaktivitätszeitlimits, Ablaufdaten von Artefakten, Aufräumen verlorener Profile sowie einen reibungslosen Abschaltvorgang des Gateways.
Beobachtbarkeit ohne Leckage privater Daten
Das Gateway protokolliert begrenzte Betriebsereignisse, die die Erstellung von Sitzungen, Navigation, Richtlinienentscheidungen, Kontrollübergaben, Änderungen, Fehler sowie Aufräumarbeiten umfassen. Ein Prüfprotokoll sollte Identifikatoren und Ergebnisse enthalten, statt Anmeldeinformationen oder Seiteninhalte. URLs werden soweit wie möglich auf sichere Teile gekürzt, und Abfragen, Formularwerte, Passwörter, Tokens sowie personenbezogene Daten werden maskiert oder weggelassen.
Nützliche Betriebssignale umfassen:
- Verzögerungen am Gateway und bei den Worker-Prozessen
- Anzahl der vorhandenen Sitzungen und Browser
- Vernetzte WebRTC-Partner
- Welche Kategorien von Richtlinienverweigerungen auftreten
- Wie oft Ziele veralten
- Ausgebnisse, die nicht bestätigt wurden
- Worker-Prozesse, die nicht gestartet werden können
- Ob Verbindungen für die Live-Ansicht erfolgreich sind
- Erschaffene und abgelaufene Artefakte
- Aufräumarbeiten, die fehlschlagen
Der Betrachter meldet, wann das Video tatsächlich den Wiedergabezustand erreicht, denn allein die Erstellung einer signierten URL beweist nicht, dass der Benutzer etwas sehen kann.
Toverlässigkeit und Belastungstests
Die problematischsten Fehler bei der Browser-Automatisierung sind die stillen: Ein Klick, der nichts bewirkt, Eingaben, die zweimal übermittelt werden, ein Pop-up, das niemand sieht, oder eine Aktion, die nach Ablauf der Frist erneut ausgeführt wird. Eine umfassende Testsuite geht daher weit über die normale Navigation hinaus. Cloud Browser prüft folgende Bereiche:
- viele Benutzer und Sitzungen gleichzeitig
- Trennung zwischen Aufgaben und Artefakten
- Mutationen, die idempotent sein müssen
- Verweise auf veraltete Dokumente
- Verfolgung von Pop-ups
- Ziele innerhalb von Iframes und Shadow Roots
- WebRTC-Neuverbindungen
- Konflikte während des Übergangs der Kontrolle
- Seiten, die beschäftigt sind oder kurz eingefroren werden
Stresstests sollten echte Chromium-Worker mit mehreren WebRTC-Zuschauern gleichzeitig kombinieren. Unit-Tests decken die Richtlinien- und Protokolllogik gut ab, doch Konflikte beim Browser-Start, Video-Streaming, Fokussierung, Auswahl von Popups und Eingabenzustellung treten nur unter realistischer Last auf.
Implementierungsmodell
Die Referenzarchitektur kann als ein einziger Knoten laufen, obwohl ihre Schnittstellen für ein größeres Produktionskontrollsystem vorgesehen sind. Eine grundlegende Implementierung verknüpft diese Komponenten miteinander:
TLS ingress
-> Cloud Browser gateway
-> isolated browser workers
-> encrypted profile and artifact volume
Der Browser sollte als Benutzer ohne besondere Rechte unter einem geeigneten seccomp-Profil laufen, wobei die CPU- und Speicherkapazitäten begrenzt sind sowie ausreichend gemeinsamer Speicher für Chromium vorhanden ist. Container bieten einen praktischen Ausgangspunkt, und in Umgebungen mit höherem Risiko kann man für jede Browser-Worker-Prozessgruppe eine MicroVM wählen, um eine stärkere Isolation zu erreichen.
In Unternehmensumgebungen werden häufig folgende Elemente hinzugefügt:
- OIDC-Anmeldemethode für die eigenständige Konsole
- Maschine-zu-Maschine-Authentifizierung für Agenten
- Die Identität des Endbenutzers, die über vertrauenswürdige Backend-Systeme übermittelt wird
- Redis zur Speicherung von verteilten Lizenzinformationen und Idempotenzschlüsseln
- PostgreSQL oder eine spezielle Prüfplattform für dauerhafte Ereignisse
- Verschlüsselter Objektspeicher für Artefakte
- Ein Scheduler zur Zuweisung von Worker-Prozessen
- TURN-Server, die kurzlebige WebRTC-Zertifikate ausstellen
- Ein Geheimnismanager mit Schlüsselrotation
- Regionales Routing sowie Kontrollmechanismen zur Datenspeicherung
Die Gateway sollte von außen nur über HTTPS erreichbar sein. Einfaches HTTP eignet sich ausschließlich für explizite Loopback-Entwicklungen.
Konfiguration, Variable für Variable
Eine env-Datei legt die Netzwerkidentität des Gateways, das Verhalten des Browsers, die Speicherung, die Isolierung sowie die Richtlinien fest. Sie sollte als Bereitstellungskonfiguration und nicht als Quelle der Anwendung betrachtet werden. Das untenstehende Beispiel kann sicher gezeigt werden, da seine Werte nur illustrativ sind und keine echten Token oder Signaturgeheimnisse enthalten:
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
Dies ist die Netzwerkschnittstelle, auf der das Gateway lauscht.
CB_HOST=127.0.0.1
Mit 127.0.0.1 antwortet der Dienst nur auf den lokalen Rechner – die sicherste Wahl beim Entwickeln mit der Agent-UI, dem MCP-Adapter und dem Gateway auf einem Computer. Ein Container benötigt möglicherweise 0.0.0.0, damit sein Netzwerk oder ein Ingress-Proxy sich verbinden kann, doch das ist kein Grund, den Port ins Internet freizugeben; Produktionsgateways bleiben hinter authentifizierten TLS-Ingress-Verbindungen, Firewall-Regeln und servicebezogener Autorisierung verborgen. Beachten Sie außerdem, dass CB_HOST bestimmt, wo der Prozess lauscht, nicht die URLs in den Live-View-Links, die von CB_PUBLIC_URL gesteuert werden.
CB_PORT
Dies ist die TCP-Portnummer, die vom Gateway verwendet wird.
CB_PORT=8787
Jede Zahl von 1 bis 65535 ist geeignet, wobei der Standardwert in der Entwicklung 8787 ist. Dieser Wert muss auf der gewählten Schnittstelle nicht verwendet werden. Wenn ein Reverse-Proxy oder Container einen anderen externen Port freigibt, bleibt CB_PORT der interne Hörrport, während CB_PUBLIC_URL die Adresse angibt, die Außenstehende sehen.
CB_PUBLIC_URL
Die öffentliche Basis-URL ist die, die das Gateway verwendet, um signierte Live-View-Links zu erstellen.
CB_PUBLIC_URL=http://127.0.0.1:8787
Es handelt sich dabei um mehr als nur ein Label, da die Benutzeroberfläche die daraus abgeleiteten Funktionen des Anzeigenden erhält und daher vom Browser, der die Live-Ansicht zeigt, erreichbar sein muss. Die lokale Entwicklung unterstützt Loopback-HTTP:
CB_PUBLIC_URL=http://127.0.0.1:8787
Eine entfernte Bereitstellung erfordert eine extern erreichbare HTTPS-Quelle:
CB_PUBLIC_URL=https://browser.example.com
Lassen Sie Pfade, Abfragen, eingebettete Benutzernamen, Passwörter sowie Rohdaten mit Geheiminformationen aus dieser URL heraus und beenden Sie den TLS-Verkehr an einem vertrauenswürdigen Eingangspunkt oder direkt am Gateway. Noch eine Fallstrick: 127.0.0.1 bezeichnet immer das Gerät, auf dem Sie sich befinden. Angenommen, die Agent-UI läuft auf einem Laptop und das Gateway befindet sich auf einem Server irgendwo anders. Ein Anzeigelink, der mit 127.0.0.1 erstellt wird, führt somit zurück zum Laptop und erreicht niemals das Gateway.
CB_TOKENS
Diese Variable listet die Dienstanmeldeinformationen auf, die vom Gateway akzeptiert werden. Jeder Eintrag folgt einem bestimmten Format:
<bearer-token>:<tenant-id>:<service-principal>[:scope]
Eine delegierte Backend-Zugangsdaten sieht so aus:
CB_TOKENS=replace-with-a-long-random-token:tenant-example:agent-service:delegate
Kommas trennen die einzelnen Einträge. Das erste Feld ist das Token des Benutzers, das im HTTP-Header Authorization übermittelt wird; es sollte mindestens 20 Zeichen lang sein, mit einer kryptografisch sicheren Zufallsquelle generiert werden und in einem Geheimnismanager gespeichert werden. Die Tenant-ID bildet die äußerste Trennlinie, sodass Sessions, Aufgaben, Profile, Tabellen und Artefakte diese niemals überschreiten. Der Principal gibt den Dienst an, der die Zugangsdaten enthält, und ohne Delegation laufen die Sessions unter diesem Principal.
Der optionale delegate-Bereich ermöglicht es einem vertrauenswürdigen Backend, einen X-Cloud-Browser-Principal-Header zu senden, der den tatsächlichen Endnutzer benennt. Die Sitzung gehört anschließend diesem Benutzer, während die Audit-Trail separat aufzeichnet, welches Backend im Auftrag dieses Benutzers gehandelt hat. Nur vertrauenswürdige Serverseit-Anwendungen sollten Delegation erhalten; Desktop-Clienten oder gewöhnliche Benutzer-Token sollten dies nicht, da sie sonst die Identität eines anderen Benutzers innerhalb des Tenants vortäuschen könnten.
Sowohl konfigurierte als auch angezeigte Token werden vor einem Vergleich mit konstanter Zeitdauer gehässelt, was Leckagen durch die Länge des Tokens verringert, aber ein geleaktetes Token nicht sicher macht. Wechseln Sie ein Token umgehend aus, falls es in einem Screenshot, einer Versionsverwaltung, einer Terminalaufzeichnung oder in einem Support-Ticket auftaucht. Verwenden Sie es auch nicht erneut als CB_LIVEVIEW_SECRET, da die beiden unterschiedliche Funktionen schützen und eine unabhängige Erstellung erfordern.
CB_MAX_SESSIONS_PER_PRINCIPAL
Dies begrenzt die Anzahl der gleichzeitigen Sitzungen, die ein aktiver Benutzer halten kann.
CB_MAX_SESSIONS_PER_PRINCIPAL=8
Die zulässigen Werte reichen von 1 bis 128, wobei der Standardwert 8 ist. Diese Beschränkung schützt vor versehentlichen Angriffen durch Browser sowie unkontrolliertem Verhalten von Agenten und verhindert, dass ein einzelner Benutzer die gesamte Kapazität aufbraucht; sie ergänzt die pro Gateway festgelegte Sitzungsgrenze. Der ideale Wert hängt von der Arbeitsspeicherkapazität des Prozesses, der CPU-Leistung, dem Profilmodus sowie der erwarteten Konkurrenz ab. Selbst wenn ein persistentes Profil einen Browserprozess über mehrere Aufgaben eines Benutzers teilt, verbrauchen alle Aufgaben weiterhin Ressourcen für Tabseiten, Streaming, Artefakte und das Gateway.
CB_LIVEVIEW_SECRET
Es handelt sich um den HMAC-Schlüssel, mit dem die Funktionen der Live-Ansicht signiert werden.
CB_LIVEVIEW_SECRET=replace-with-a-separate-random-signing-secret
Jeder Wert im signierten Token (Tenant, Principal, Task, Session, Tab, Ablaufdatum) wird durch die Signatur abgedeckt, wodurch eine Änderung diese ungültig macht. Eine von außen erreichbare Deployment-Methode benötigt ein eigenes Geheimnis mit mindestens 32 Zeichen; in der Praxis bedeutet das mindestens 32 zufällige Bytes im Hex- oder Base64-Format, die aus einem Geheimnismanager geladen werden. Ein durchgesickertes Geheimnis würde es einem Angreifer mit ausreichenden Sitzungsmetadaten ermöglichen, Ansichtenfunktionen zu fälschen. Die Rotation macht neu verifizierte Signaturen, die mit dem alten Schlüssel erstellt wurden, ungültig – daher muss sie auf das Ablaufdatum der Live-View-Sitzung abgestimmt werden. Bewahren Sie den Wert vor Agenten, Browserseiten, Client-Paketen, Protokollen und Repositorien auf.
CB_LIVEVIEW_FRAME_ANCESTORS
Dies legt fest, welche vertrauenswürdigen Webanwendungen den signierten Anzeigemodus in einem iframe einbetten dürfen.
CB_LIVEVIEW_FRAME_ANCESTORS=http://localhost:8088,http://127.0.0.1:8088
Die Gateway-Software wandelt die Liste in die frame-ancestors-Anweisung der Content Security Policy des Viewers um. Ist der Wert leer, sendet der Viewer frame-ancestors 'none' sowie X-Frame-Options: DENY, wodurch die Seite als eigenständige Seite funktioniert, aber ein Einbetten verweigert wird. Wenn Quellen aufgelistet sind, dürfen sie nur genau diese einbetten, und X-Frame-Options: DENY wird weggelassen, da dieser ältere Header nicht mehrere Quellen angeben kann und somit die Allowlist ungültig machen würde.
Die Einträge müssen exakte HTTP- oder HTTPS-Quellen sein; Pfade, URL-Zertifikate, Abfragen, Fragmente sowie Wildcards werden abgelehnt. Schema, Host und Port sind alle relevant, weshalb die folgenden drei als unterschiedliche Quellen gelten:
http://localhost:8088
http://127.0.0.1:8088
https://agent.example.com
Diese Einstellung hat nichts mit CORS zu tun. Sie schützt die leistungsstarke Anzeigeseite vor Clickjacking, sodass nur jene Schnittstellen aufgeführt werden sollten, die tatsächlich den Live-Browser anzeigen müssen.
CB_HEADLESS
Diese Einstellung bestimmt, ob der Worker den Browser ohne ein natives Desktop-Fenster startet.
CB_HEADLESS=true
Mit true läuft Chromium oder Chrome headless, und die Benutzer überwachen sowie steuern die Darstellung über den WebRTC-Live-View anstelle eines lokalen Chrome-Fensters. Server und Container wünschen sich dies in der Regel, da dadurch weniger Desktop-Ressourcen verbraucht werden und die Automatisierung unabhängig von einer nativen Anzeigesitzung bleibt. Mit false wird der Browser mit Anzeige gestartet und benötigt eine funktionierende Anzeige – in der Regel eine virtuelle wie Xvfb oder ein Desktop-Streaming-Worker-Bild unter Linux; unter macOS wird ein separates Browserfenster geöffnet, es sei denn, die Worker-Architektur unterscheidet sich. Das Ändern dieses Flags bewirkt niemals, dass der Cloud Browser ein bereits geöffnetes persönliches Chrome-Fenster übernimmt. Es beeinflusst lediglich die Art und Weise, wie der eigene vom Worker verwaltete Browser gestartet wird.
CB_SERVICE_WORKERS
Dies bestimmt, ob Webseiten Service Workers registrieren und ausführen dürfen.
CB_SERVICE_WORKERS=allow
Wählen Sie allow oder block; block ist die sichere Standard-Einstellung. Progressive Web Apps, Videokonferenz-Tools, Büroanwendungen sowie stark gekachelte Websites sind oft auf Service Workers angewiesen und können ohne sie nicht funktionieren, bei einem Ladebildschirm stecken bleiben oder eingefroren erscheinen. Ihre Aktivierung verbessert die Kompatibilität, erhöht aber auch die Netzwerk- und Speicherkapazitäten des Browsers. Überprüfen Sie daher im Voraus, ob die Service-Worker-Anfragen weiterhin die Navigationsschutzregeln, Ausgangsregeln, Maßnahmen zur Verhinderung von Datenverlusten sowie die Richtlinien einhalten. Wählen Sie allow nur für validierte Anwendungen, die sie benötigen – niemals als allgemeine Lösung.
CB_BROWSER_CHANNEL
Diese Einstellung wählt einen systemseitig installierten Browser-Channel anstelle des von Playwright mitgelieferten Chromiums aus.
CB_BROWSER_CHANNEL=chrome
Vier Kanäle sind zulässig: chrome, chrome-beta, chrome-dev und msedge. Lassen Sie dieses Feld leer, um die konfigurierte Chromium-Exekutabel oder das Playwright-Bundle zu verwenden. Echte Chrome- oder Edge-Versionen sind manchmal notwendig, wenn ein Unternehmen die Vertrauenswürdigkeit von Geräten überprüft, Browser zentral verwaltet, Richtlinien durchsetzt oder Client-Zertifikate ausstellt. Die Auswahl von chrome lädt das normale Chrome-Profil des Benutzers nicht herunter, da die Profile weiterhin aus CB_PROFILE_MODE und CB_PROFILE_DIR stammen; daher kann Cloud Browser sich nicht unbemerkt an eine persönliche Interaktionssession anschließen. Der Kanal muss auf dem Worker-Host installiert sein, und für das Gerätevertrauen können außerdem das richtige Profil, eine OS-Registrierung, Zertifikate, Richtlinien oder Erweiterungen erforderlich sein; die Einstellung selbst schafft kein Unternehmensvertrauen.
CB_EXTENSION_PATHS
Eine mit Kommas getrennte Liste der entpackten Verzeichnisse von Browser-Erweiterungen.
CB_EXTENSION_PATHS=
Lassen Sie dieses Feld leer, um keine entpackten Erweiterungen zu laden. Die aufgelisteten Pfade werden über Flags zur Laden von Erweiterungen an den verwalteten Browser weitergegeben, was nur bei CB_HEADLESS=false sowie einem CB_PROFILE_MODE von task oder persistent funktioniert; vorübergehende Kontexte sowie reine headless-Ausführungen können dies nicht sicher hosten. Das Laden entpackter Erweiterungen dient der Entwicklung und kontrollierten Tests. Produktionsumgebungen sollten genehmigte Erweiterungen über Chrome- oder Edge-Richtlinien erzwingend installieren, Identifikatoren festlegen und Quellen aktualisieren sowie Berechtigungen prüfen. Da eine Erweiterung mit Browserberechtigungen läuft und Webaktivitäten beobachten oder ändern kann, gehören ihre Herkunft, Aktualisierungsroute, Berechtigungen sowie der Eigentümer alle in die Sicherheitsprüfung.
CB_PROFILE_MODE
Dies bestimmt, wie der Browserzustand isoliert wird und wie lange der Anmeldezustand bestehen bleibt.
CB_PROFILE_MODE=persistent
Die Einstellung kann ephemeral, task oder persistent sein. Im ephemeral-Modus wird ein temporärer Browserkontext ohne wiederverwendbaren Profildatenträger erstellt – dies bietet die stärkste Standardisolation und eignet sich für anonymes Surfen oder Arbeiten, bei denen keine Anmeldespuren hinterlassen werden sollen. Im task-Modus wird ein Profildatenträger nur für eine bestimmte Aufgabe erstellt: Cookies und Zustandsdaten bestehen solange wie die Aufgabe, danach wird der Profildatenträger gelöscht. Im persistent-Modus wird ein Profildatenträger zwischen Aufgaben desselben Benutzers und des gleichen effektiven Benutzers geteilt, sodass Cookies und Website-Sitzungen auch nach neuen Aufgaben oder Neustarts des Gateways weiterbestehen – allerdings behält jede Aufgabe ihre eigenen Tab-Eigentumsverhältnisse, ausgewählten Tab, Zwischenablage, Live-Streams sowie Kontrollmechanismen bei. Der persistente Modus ist am praktischsten, aber auch am risikoreichsten; verwenden Sie verschlüsselten Speicher, strenge Verzeichnisrechte, explizite Abmeldefunktionen sowie Prozesse zum Löschen des Profils und begrenzen Sie die Inaktivitätszeit.
CB_PROFILE_DIR
Der Wurzelverzeichnis, in dem die vom Profil gestützten Browserdaten gespeichert sind.
CB_PROFILE_DIR=./var/profiles
Ein relativer Pfad bezieht sich auf den Arbeitsverzeichnis des Gateway-Prozesses. In Containern sollte hier ein geschütztes Volume montiert werden, falls Profile auch nach dem Ersetzen des Containers erhalten bleiben müssen. Das Gateway erstellt selbst Unterverzeichnisse, die sich nach Tenant und Benutzer richten, und übernimmt niemals Profilepfade, die von Agenten ausgewählt wurden. Die Verzeichnisse sollten nur für den Eigentümer zugänglich sein und niemals zur Herunterladung angeboten werden. Richten Sie die Einstellung nicht auf das Chrome-Profil einer echten Person aus; das Kopieren oder gleichzeitige Öffnen eines aktiven Profils kann es beschädigen und unverwandte Surfen-Daten dem Worker aussetzen.
CB_ARTIFACT_DIR
Ort, an dem Screenshots, Downloads, exportierte Inhalte, Wiedergabebilder sowie andere begrenzte Artefakte gespeichert werden.
CB_ARTIFACT_DIR=./var/artifacts
Relative Pfade werden erneut vom Arbeitsverzeichnis des Gateways gelöst. Die Agenten erhalten statt von Pfaden unsichtbare Artefakt-IDs, und jede Abfrage überprüft Tenant, Principal, Aufgabe, Ablaufdatum und Eigentumsverhältnisse. Stellen Sie sicher, dass das Verzeichnis nur für das Servicekonto des Cloud Browsers schreibbar ist, begrenzen Sie die Lebensdauer sowie die Anzahl und Größe der Artefakte, löschen Sie abgelaufene Dateien, verschlüsseln Sie die darunterliegende Speicherung und vermeiden Sie es, temporäre Artefakte endlos in Backups zu speichern. Profile und Artefakte dienen unterschiedlichen Zwecken: Ein Screenshot kann einem Benutzer zugesendet werden, während ein Browserprofil niemals als herunterladbares Artefakt behandelt werden darf.
CB_AUDIT_FILE
Der Pfad zum begrenzten JSON Lines-Audit-Log.
CB_AUDIT_FILE=./var/audit.log
Jede Zeile stellt ein strukturiertes Ereignis dar – beispielsweise für die Erstellung einer Sitzung, die Ausführung eines Befehls, eine Ablehnung aufgrund einer Richtlinie, den Übergang der Steuerung, das Ergebnis einer Live-View-Verbindung, die Zerstörung einer Sitzung oder einen Fehler bei der Bereinigung. Erfassen Sie, wer und was passiert ist – nicht die Werte von Formularen oder den Inhalt von Seiten – und entfernen oder verschleiern Sie Anmeldedaten, Tokens, Abfragen sowie sensible Benutzerdaten. In der Produktion sollten lokale JSONL-Dateien als Entwicklungs- oder Transportformat betrachtet werden, und die Ereignisse sollten auf eine langlebige Prüfplattform übertragen werden, die eine Aufbewahrungsrichtlinie, Zugriffskontrolle, Integritätsschutz, Benachrichtigungen sowie untersuchungsorientierte Funktionen für verschiedene Nutzergruppen bietet.
CB_USER_AGENT
Eine optionale Überschreibung für den User-Agent-String des Browsers.
CB_USER_AGENT=
Besser leer lassen. Der Worker erstellt eine normale Chrome-Identität aus der Browserversion und liefert entsprechende Client-Hinweise, um Uneinigkeiten zwischen dem Anfrage-Header, navigator.userAgent und navigator.userAgentData zu vermeiden. Ein benutzerdefinierter String überschreibt nur den User-Agent, ohne dass entsprechende Hinweise erstellt werden, und einige Identitätsanbieter sowie Bot-Scanner erkennen diese Abweichung. Verwenden Sie ihn nicht, um einen alten Browser als neuer darzustellen oder die Sicherheitsrichtlinien einer Website zu umgehen; nutzen Sie ihn ausschließlich für dokumentierte Kompatibilitätsanforderungen und überprüfen Sie anschließend die vollständige Browser-Identität.
CB_ALLOW_ORIGINS
Die Allowlist für die Navigation des Mieters.
CB_ALLOW_ORIGINS=
Falls die Liste leer ist, werden öffentliche HTTP- und HTTPS-Ziele durchgelassen, es sei denn, eine andere Richtlinie tritt in Kraft; private-Netzwerk-, Metadaten-, Link-Local-, reservierte sowie nicht unterstützte Ziele unterliegen weiterhin der Netzwerkschutzregel. Sobald die Liste Einträge enthält, muss jede Navigation mindestens einer Regel entsprechen – entweder als exakter Ursprung wie https://portal.example.com, mit einem Wildcard-Suffix wie *.example.com oder als reiner Hostnamen wie portal.example.com. Wenn Schema oder Port relevant sind, sollte ein exakter Ursprung verwendet werden. Ein Wildcard umfasst den Basis-Hostnamen sowie seine Subdomänen, daher sollte man bei deren Verwendung vorsichtig sein. Ein Eintrag in der Allowlist berechtigt keinen privaten IP-Adressen, da die DNS-Klassifizierung sowie die Richtlinie für vertrauenswürdige private Ursprünge separat bewertet werden.
CB_BLOCK_ORIGINS
Die explizite Ablehnungsliste für Navigationen.
CB_BLOCK_ORIGINS=
Die Regeln verwenden dieselben drei Formate wie die Allowlist, und diese Liste wird zuerst abgefragt, sodass alles, was in beiden Listen vorkommt, blockiert wird. Typische Anwendungsgebiete sind sensible Admin-Endpunkte, nicht unterstützte Anwendungen, bekannte gefährliche Zieladressen oder Subdomänen, die aus einer umfassenderen Allowlist entfernt werden müssen. Die Netzwerkklassifizierung gilt auch dann, wenn die Liste leer ist.
CB_TRUSTED_PRIVATE_ORIGINS
Enthält die Hostnamen von Unternehmen, die auf private oder CGNAT-Adressen auflösen können.
CB_TRUSTED_PRIVATE_ORIGINS=*.company.example
Der Grund für seine Existenz sind Split-DNS-Einrichtungen, bei denen ein von der Organisation genehmigter Hostname im VPN oder im internen Netzwerk unterschiedlich aufgelöst wird. Die Regeln verwenden die Syntax der Navigationsliste. Beschränken Sie sie auf Domains, die der Organisation gehören, und vermeiden Sie es, allgemeine Wildcards oder Hostnamen hinzuzufügen, nur weil eine Anwendung sich falsch verhält. Ein vertrauenswürdiger Abgleich darf RFC1918- oder CGNAT-Ziele zulassen, aber niemals Loopback-, Link-Local-, Cloud-Metadaten-, Multicast- oder reservierte Adressen. Prüfen Sie diese Regel genauso wie die SSRF-Ausnahme – die Plattform benötigt Kontrolle über das DNS, den Ausgangsverkehr sowie das Eigentum an jedem vertrauenswürdigen Suffix.
CB_ALLOW_CGNAT_NAVIGATION
Erlaubt die Navigation in den Carrier-Grade-NAT-Bereich 100.64.0.0/10.
CB_ALLOW_CGNAT_NAVIGATION=true
Der Standardwert ist false. In einigen Unternehmensnetzwerken stellen VPNs oder sichere Web-Gateways öffentliche oder interne Dienste unter Adressen im CGNAT-Bereich bereit. Das Aktivieren dieses Schalters ermöglicht diesen Diensten den Zugriff und kann die Beschränkungen des Browsers bezüglich des lokalen Netzwerkzugriffs deaktivieren, die sonst verhindern würden, dass eine Seite die synthetische Adresse erreicht. Dies umfasst mehr als nur das Vertrauen in eine Hostname – verwenden Sie daher CB_TRUSTED_PRIVATE_ORIGINS, wenn nur bekannte Unternehmensdomänen benötigt werden. RFC1918-, Loopback-, Link-Local-, Metadaten-, Multicast- sowie reservierte Adressbereiche bleiben weiterhin gesperrt, doch der Netzwerkzugriff erweitert sich dennoch erheblich; aktivieren Sie diese Einstellung daher nur in einem kontrollierten Unternehmensumfeld.
CB_REQUIRE_APPROVAL
Aktiviert das allgemeine Genehmigungsverfahren des Gateways für Befehle, die als von großer Bedeutung eingestuft werden.
CB_REQUIRE_APPROVAL=false
Mit true werden konsequente Befehle zurückgehalten, bis eine genaue Genehmigung zum Ausführungzeitpunkt vorliegt. Mit false wird die Schutzbarriere aufgehoben, was sinnvoll ist, wenn eine zuverlässige Agentenanwendung bereits strengere Regeln durchsetzt. Die Sicherheit wird jedoch nicht deaktiviert. Erkannte Risiken wie die Übertragung sensibler Daten, Löschvorgänge, Zahlungen, Reservierungen, Nachrichten im Namen anderer Personen, Änderungen von Konten oder Berechtigungen, Zugriff auf Historie sowie Tools für unklassifizierte Seiten erfordern weiterhin eine Genehmigung. Die Kontrolle betrifft einen anderen Aspekt: Agentenaktionen bleiben blockiert, solange der Benutzer den Browser bedient. Bei einem eigenständigen Produkt, das von mehreren Agenten genutzt wird, ist es in der Regel klüger, die Schutzmaßnahmen beizubehalten, da die Sicherheit dann nicht davon abhängt, dass jeder Client die Richtlinien korrekt umsetzt.
CB_ALLOW_LOOPBACK_NAVIGATION
Ein Entwicklungs-Schalter, der es dem Worker-Browser ermöglicht, Loopback-Adressen (localhost, 127.0.0.1 oder ::1) aufzurufen.
CB_ALLOW_LOOPBACK_NAVIGATION=true
Standardmäßig ist der Wert false. Automatisierte Tests sowie lokale Webanwendungen auf derselben Maschine wie der Worker profitieren davon. Es ermöglicht es keinem entfernten Browser, auf den Laptop eines Benutzers zuzugreifen, da bei einem entfernten Worker 127.0.0.1 die entfernte Umgebung darstellt. Aktivieren Sie es in der Produktion nicht leichtfertig – Loopback-Zugriff kann interne Admin-Ports, Entwicklungsserver, Debugging-Schnittstellen sowie Dienste offenbaren, die unter der Annahme erstellt wurden, dass unzuverlässiger Webinhalt nicht darauf zugreifen kann. Selbst wenn es aktiviert ist, muss der Hostname nur auf Loopback-Adressen verweisen, damit eine gemischte DNS-Antwort die Ausnahme nicht in einen allgemeinen Umgehungsweg umwandeln kann.
CB_SYNTHETIC_MEDIA_DEVICES
Gibt dem verwalteten Browser ein künstliches Mikrofon und eine Kamera.
CB_SYNTHETIC_MEDIA_DEVICES=true
Daher false standardmäßig. Headless-Browser zeigen häufig keine Mediengeräte an, und einige Meeting- sowie Aufnahmeseiten überprüfen vor dem Weitermachen einen Mikrofon- oder Kameraverbindungsstatus; daher scheint die Seite blockiert zu sein, wenn keine Geräte gefunden werden. Künstliche Geräte sorgen dafür, dass diese Überprüfungen erfolgreich sind: Das Mikrofon ist stumm und die Kamera zeigt ein Testmuster anstelle von echtem Video. Hier wird weder das physische Mikrofon noch die Kamera irgendeiner Person aufgezeichnet, und das sollte auch niemals so beschrieben werden. Wenn der Worker an einem echten Meeting teilnimmt, sollte die Kamera ausgeschaltet bleiben, es sei denn, das Testmuster soll übertragen werden. Die Seite kann dennoch eine Genehmigung anfordern, und deren Gewährung ist eine eigene Entscheidung hinsichtlich der Richtlinien – unabhängig davon, ob ein Gerät bereitgestellt wird.
Das Beispiel als eine einzige Implementierung lesen
Insgesamt beschreibt die Beispielkonfiguration eine lokale Entwicklungsumgebung:
- Die Gateway akzeptiert nur lokale Verbindungen über Port
8787.
8088 unter beliebigem Hostnamen bereitgestellt wird.Dies funktioniert als lokales Integrationprofil, ist aber keine Produktionsbasis. Vor dem Start: Verschieben Sie die öffentliche URL auf HTTPS, wechseln Sie alle Geheimnisse aus und lagern Sie sie außerhalb der Datei ab, deaktivieren Sie Loopback, beschränken Sie die CGNAT- und Private-Origin-Ausnahmen, überprüfen Sie den Zugriff des Service-Werkers, aktivieren Sie die Gateway-Approvals-Policy, speichern Sie Profile und Artefakte auf verschlüsseltem verwaltetem Speicher und leiten Sie Auditeevorfälle an eine dauerhafte Plattform weiter.
Anbindung eines Agents
Ein MCP-fähiger Agent kann den Adapter als lokalen Prozess starten und ihn auf das Gateway ausrichten. Reale Anmeldeinformationen bleiben außerhalb des Source-Controls, daher verwenden Sie Platzhalter wie diese:
{
"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"
}
}
}
}
Eine typische Interaktion verläuft dann wie folgt:
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
Wie sich dies von einem Browser-Tool innerhalb eines Agents unterscheidet
Viele Agent-Produkte liefern ihr eigenes Browser-Tool mit. Cloud Browser soll die Browserplattform für viele Agents sein, und sein Wert ergibt sich aus einer Kombination von Eigenschaften:
- er bleibt unabhängig davon, welches Modell verwendet wird
- Sitzungen werden remote gespeichert
- die Interaktion ist sowohl semantisch als auch visuell
- WebRTC ermöglicht Beobachtung und Steuerung
- Anmeldedaten werden sicher verarbeitet
- der Gateway stellt Genehmigungen durch
- Screenshots liefern Beweise und ermöglichen Wiedergabe
- Artefakte sind auf Aufgaben beschränkt
- die Bereinigung folgt einem deterministischen Lebenszyklus
- Unternehmensidentität, Richtlinien und Prüfungsmechanismen sind integriert
Im Grunde kommt es darauf hinaus:
Demonstrieren Sie einen Workflow einmal, und führen Sie ihn anschließend über jeden AI-Agenten aus, wobei ein Mensch weiterhin in der Lage sein sollte, folgende Schritte zu stoppen.
Lektionen aus der Entwicklung
Der Browser ist nicht der schwierige Teil – die Autorisierung schon. Aus der Gestaltung ergaben sich sechs Lektionen.
Eine Live-Ansicht stellt eine Sicherheitsfläche dar und nicht nur einen Video-Player: Sie enthält Steuerelemente, Genehmigungen, Zugangsdaten sowie die Absichten der Benutzer. Daher benötigen ihre URL, die Framing-Policy, die Gültigkeitsdauer sowie der Kontrollzustand dieselbe Sorgfalt wie die Funktionalitäten einer API.
Eine Nachricht zu übermitteln ist nicht dasselbe wie die Interaktion abzuschließen. Ein Klick kann eintreffen, während die Seite ihn einfach ignoriert – deshalb benötigt eine Eingabe eine Bestätigung, ein anschließender Blick auf die Seite sowie getrennte Kennzeichnungen für „übermittelt“, „geändert“ und „noch in Wartestand“.
Blinde Wiederholungsversuche sind riskant. Wo immer eine Browseraktion reale Folgen haben kann, sind Idempotenz und Abstimmung erforderlich.
Persistente Sessions machen das Produkt zugleich nützlicher und riskanter. Isolieren Sie sie durch Identifikation und verknüpfen Sie sie mit Kontrollen für Anmeldelöschen, Aufbewahrung, Historie und Bereinigung.
Betrachten Sie die Seiteninhalte sowie von der Seite bereitgestellte Tools als unzuverlässig. Eine Website mag eine Aktion beschreiben, doch sie hat keine Befugnis, diese zu genehmigen.
Zuletzt macht begrenztes Nachweismaterial die Automatisierung vertrauenswürdiger. Mit einer Zeitachse von Screenshoten und Zusammenfassungen der Aktionen können Nutzer, Entwickler und Betreiber einen Fehler verstehen.
Was davon übrig bleibt
Agenten benötigen Browser, doch Unternehmen wollen mehr als nur Skripte. Sie wünschen eine Plattform mit klarem Eigentumsverhältnis, ablaufender Autorität, sicheren Übergaben an Menschen, geschütztem Anmelden, Genehmigung vor jeglichem Einfluss sowie nachvollziehbaren Ergebnissen und zuverlässiger Bereinigung.
Cloud Browser verwandelt Playwright und Chromium in genau diese Plattform, indem er Planung von Ausführung, Agenten von Zugangsdaten sowie Browserfunktionen von Benutzerrechten trennt. Genau diese Trennung macht das Design wiederverwendbar: Man kann den Agenten, das Modell oder die Benutzeroberfläche austauschen, ohne dass die Sicherheitsgrenzen um den Browser verändert werden. Das ist die Grundlage, die benötigt wird, damit Menschen der Browserautomatisierung wirklich vertrauen können.