Navigateur cloud : une plateforme de navigateur à distance sécurisée pour tout agent IA
Un modèle de conception de référence pour un service navigateur à distance neutre en termes de modèle : passerelle, travailleurs, vue en direct WebRTC, validations, mécanismes de protection contre le SSRF, fonction de réexécution, ainsi que toutes les paramétrisations possibles.
Les agents d’IA sont devenus assez compétents pour raisonner sur les pages web, mais faire fonctionner un vrai navigateur reste plus difficile qu’il n’y paraît. Cliquer sur des boutons, c’est la partie facile. Un agent navigateur sur lequel on peut compter doit maintenir les sessions actives, gérer les fenêtres pop-up et les redirections, comprendre les interfaces dynamiques, s’occuper des téléchargements et des mises à jour, permettre à un humain de reprendre le contrôle, protéger les identifiants, demander l’autorisation avant de prendre des décisions importantes, et enfin indiquer ce qui s’est réellement passé.
Cloud Browser est une solution conçue pour résoudre l’ensemble de ces problèmes : un service d’exécution de navigateur autonome qui ne se soucie pas du modèle utilisé de l’autre côté.
Un agent de bureau, un assistant de codage en ligne de commande, un client MCP ou une application personnalisée peuvent tous l’utiliser. Le service ne contient absolument aucun LLM. C’est l’agent qui décide de ce qui doit se produire, tandis que Cloud Browser gère le navigateur, les limites de sécurité, l’exécution, la vue en temps réel, le suivi des preuves ainsi que le nettoyage.
Cette séparation constitue la décision architecturale la plus importante du système. En changeant l’agent, la plateforme de navigateur reste inchangée. En mettant à jour un travailleur de navigateur, l’agent n’a pas besoin d’être réécrit. La politique de sécurité fonctionne de la même manière, quel que soit le client qui fait appel.
Ce qui suit aborde l’architecture, les limites de confiance, le modèle d’interaction ainsi que les choix techniques qui permettent de transformer l’automatisation des navigateurs en une solution pouvant être exploitée par une entreprise.
Le tableau d’ensemble
Un agent d’IA utilise un navigateur à distance, tandis qu’une personne peut observer, intervenir, approuver des actions sensibles, examiner les captures d’écran et rejouer la tâche par la suite. Le flux de haut niveau est délibérément simple :
User
|
v
AI agent or agent application
|
| HTTPS API or MCP
v
Cloud Browser gateway
|
v
Isolated browser worker
|
v
Website
La personne observe et guide l’opérateur à travers une vue en direct WebRTC signée.
Pourquoi Playwright ne suffit pas
Playwright est un moteur d’automatisation excellent, mais ce n’est pas un produit de navigateur multi-utilisateurs. Un service en production doit répondre à de nombreuses questions que Playwright ne pose jamais :
- Qui possède un navigateur donné ?
- Quelle tâche est associée à une fenêtre donnée ?
- Un deuxième agent pourrait-il réutiliser un identifiant de fenêtre qui ne lui a pas été attribué ?
- Que se passe-t-il lorsqu’un clic est effectué mais que la réponse réseau disparaît ?
- Comment quelqu’un peut-il se connecter sans que le mot de passe n’atteigne jamais le modèle ?
- Qu’est-ce qui empêche le navigateur d’accéder aux points de terminaison de métadonnées cloud ou à des réseaux privés ?
- Qui a le contrôle lorsque l’agent et la personne sont tous deux connectés ?
- Comment les captures d’écran peuvent-elles être stockées et téléchargées en toute sécurité ?
- Quelles preuves restent disponibles lorsque une action échoue ?
En encadrant le moteur par une frontière de service explicite, la plateforme peut répondre à toutes ces questions de la même manière à chaque fois.
Exécution sans planification
Le service exécute les demandes sans jamais planifier. Il ne décidera pas de son propre chef qu’une transaction doit avoir lieu ou qu’un message doit être envoyé. Cela permet de le rendre utile avec différents agents et d’établir une distinction claire entre deux ensembles de tâches.
Du côté de l’agent :
- comprendre ce que souhaite l’utilisateur
- déterminer la prochaine étape
- interpréter ce que l’interface affiche actuellement
- demander des précisions à l’utilisateur lorsque l’intention n’est pas claire
Du côté du navigateur cloud :
- authentifier la personne qui appelle
- isoler les sessions et les onglets les uns des autres
- appliquer la politique de navigation
- valider chaque cible
- exécuter les actions
Cibles et références obsolètes
Les cibles préférées sont sémantiques : un bouton, un champ de texte, une case à cocher, un élément de menu ou un nœud d’accessibilité présent dans le document actuel. Les applications Canvas et les interfaces fortement personnalisées nécessitent encore des coordonnées, qui sont moins stables. Dans ce cas, le Cloud Browser effectue des tests de collision sur la position et fournit des détails précis concernant l’élément qui se trouve réellement sous le pointeur.
Un agent peut également indiquer le rôle ou le texte visible qu’il attend. Si l’élément cible ne correspond pas, l’action échoue sans cliquer sur un élément inattendu.
Les pages changent constamment. Un modal peut apparaître entre l’observation et l’action, une navigation peut remplacer tout le document, et une fenêtre pop-up peut devenir la continuation active. Pour y faire face, les références sémantiques sont liées à une révision du document. Toute mutation ou navigation rend les références précédentes invalides, et l’utilisation d’une ancienne référence provoque une erreur stale_target. Le résultat est ainsi un boucle sécurisée :
Observe -> choose one action -> validate -> execute -> observe again
Où se trouvent les politiques
L’approbation et les règles de réseau ne peuvent pas être contenues uniquement dans une seule interface utilisateur, sinon un autre client pourrait se connecter directement et les contourner. Le gateway constitue le point d’application officiel de ces règles. Les applications d’agent peuvent ajouter des politiques plus strictes par-dessus, mais aucune ne peut assouplir celles définies par le service lui-même.
Architecture du système
L’implémentation de référence comprend trois paquets principaux ainsi que quelques services d’appui.
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
Le gateway
Le gateway expose un contrat HTTPS versionné. Il authentifie l’appelant, détermine l’identité réelle de l’utilisateur, vérifie la propriété de la tâche, applique les quotas, met en œuvre les politiques et transmet la commande au bon travailleur. Les commandes voyagent dans une enveloppe corrélée contenant la version du protocole, un ID de demande, un ID de tâche, un ID de session facultatif, le nom de la commande ainsi que des paramètres définis. Les commandes qui modifient l’état nécessitent également une clé d’idempotence.
Les résultats et les erreurs sont renvoyés de manière structurée. Il est interdit que des informations internes du navigateur fuient à travers des traces d’erreur aléatoires ou des pannes brutes du fournisseur.
L’adaptateur MCP
Les agents qui prennent en charge MCP se connectent via un adaptateur délibérément minimal. Chromium ne s’exécute jamais à l’intérieur de celui-ci et il ne contient aucune politique de navigateur. Sa seule fonction est de mapper les appels des outils aux requêtes du gateway : ouvrir une page (browser_open_tab), lire l’état, cliquer, prendre une capture d’écran ou finaliser une session à l’aide des outils browser_* correspondants. Plusieurs produits d’agents peuvent ainsi partager un même gateway, sans que rien de spécifique au fournisseur ne pénètre dans le processus d’exécution.
Les URL de vue en direct signées sont bloquées pour le modèle par l’adaptateur. Ce que reçoit l’agent, ce sont des données de présentation inoffensives : l’existence d’une vue en direct, la page qu’elle affiche, le utilisateur qui en a le contrôle et la date d’expiration. Seule l’interface utilisateur de confiance reçoit jamais la capacité de visualisation signée.
Le processus du navigateur
Chaque travailleur gère le processus ou le contexte du navigateur réel. Les onglets, la navigation, l’extraction sémantique, les entrées, les captures d’écran, les téléchargements, les mises à jour, la gestion du presse-papiers, les dialogues et les événements du navigateur passent tous par lui. Playwright s’occupe de la majeure partie de l’automatisation, et certaines opérations en lecture seule peuvent activer des fonctionnalités CDP restreintes. Un accès CDP illimité n’est jamais fourni de manière générale.
Ces restrictions sont importantes car le CDP brut peut accéder aux cookies, au stockage, aux cibles de débogage, à des évaluations arbitraires ainsi qu’aux composants internes du navigateur. Un produit sûr ne expose que les fonctionnalités minimales nécessaires à une tâche.
Le gestionnaire de session
Le gestionnaire de session détient la chaîne d’autorité :
tenant
-> principal
-> task
-> session
-> tab
-> operation
Les identifiants opaques sont limités à cette chaîne. Un identifiant de onglet émis dans le cadre d’une tâche ne peut être utilisé par une autre, même si les deux partagent par hasard le même processus navigateur. Le gestionnaire s’occupe également des baux d’utilisation, des délais de timeout en veille, de l’état de contrôle, des onglets conservés, du cycle de vie du profil ainsi que de sa finalisation.
Profils navigateurs et persistance
Il existe trois types de profils. Un profil éphémère est conçu pour une session de courte durée et disparaît à la fin de la tâche, offrant ainsi l’isolation la plus stricte par défaut. Un profil de tâche dure aussi longtemps que cette dernière et reste séparé de toutes les autres tâches. Un profil persistant permet à un même utilisateur de conserver des cookies et des sessions de site web activées d’une tâche à l’autre.
Chrome ne permet qu’un processus actif par répertoire de profil, de sorte que les tâches appartenant à la même personne peuvent partager un processus de navigateur, tandis que chaque tâche conserve ses propres onglets, sélection, fenêtres en temps réel, état du presse-papiers et contrôles associés.
Les profils persistants exigent des contrôles opérationnels plus stricts :
- Le répertoire de profil n’est lisible que par son propriétaire.
- Le volume ou le service de stockage sous-jacent doit chiffrer les données au repos.
- Les utilisateurs ont besoin d’un moyen de se déconnecter et de supprimer le profil stocké.
- L’accès est limité au locataire et à l’entité concernés.
- La lecture de l’historique de navigation nécessite une autorisation explicite.
- Les travailleurs ne restituent jamais de cookies bruts ou de tokens d’authentification à un agent.
La vie d’une commande
Chaque action suit la même séquence prévisible :
- L’appelant du service est authentifié.
Lorsqu’une panne de transmission se produit après que le navigateur a déjà pu agir, le gateway répond par outcome_unconfirmed. Le client doit alors concilier l’état réel du navigateur au lieu de répéter aveuglément cette étape. Cela est particulièrement important pour la réservation de places, le soumission d’un formulaire ou l’envoi d’un message, où une tentative automatique de répétition peut entraîner des effets doubles dans le monde réel.
Vue en direct via WebRTC
Il est difficile de faire confiance à un navigateur cloud que personne ne peut voir, c’est pourquoi Cloud Browser offre une vue en direct interactive via WebRTC. La vidéo s’affiche sous forme de piste multimédia, tandis que les événements liés au pointeur, au clavier, à la zone de copie, à l’état, à l’approbation et au transfert sont transmis via un DataChannel ordonné. L’HTTP n’apparaît que pour la signalisation limitée entre offre et réponse, et il n’y a pas de flux d’images secondaire via WebSocket.
Envoyer des captures d’écran à travers un protocole d’agent encore et encore ralentirait le processus, c’est pourquoi la solution WebRTC réduit la latence et permet des interactions rapides sans avoir recours aux réponses habituelles des outils. Les coordonnées du pointeur sont mappées selon les limites réelles de la vidéo, y compris les bandes noires. Les événements liés à la roue de la souris sont normalisés et regroupés, les raccourcis clavier suivent la plateforme de l’utilisateur, et les confirmations permettent de distinguer les entrées en file d’attente, celles qui ont été livrées, modifiées, rejetées ou qui sont encore en attente.
Transfert alterné du contrôle
L’utilisateur commence en mode observation tandis que l’agent détient le contrôle. Une personne peut demander le contrôle en cliquant sur l’interface du navigateur ou en appuyant sur le bouton de contrôle. La machine à états est explicite :
Agent control
-> handoff pending
-> user control
-> release pending
-> agent control
Any state
-> finalized
Tandis que l’utilisateur conserve le contrôle, les entrées de l’agent sont bloquées. Le contrôle est limité à la tâche et suit la fenêtre contextuelle sélectionnée si un site ouvre une nouvelle fenêtre. Une image vidéo obsolète ne peut pas conférer le contrôle, et un message retardé ne peut pas le restituer discrètement à l’agent, car le passerelle reste l’autorité sur l’état actuel.
Protéger le visionneur lui-même
Le lien de visualisation en direct est une capacité signée par HMAC à durée de vie courte, liée à un seul locataire, principal, tâche, session et onglet, et elle expire lorsque la tâche se termine. Le encadrement est désactivé par défaut. Pour intégrer le visionneur dans une application d’agent fiable, la configuration de déploiement indique chaque origine parente exacte dans sa politique de sécurité du contenu ; les wildcards, chemins, identifiants, requêtes et fragments sont refusés en tant qu’origines de encadrement.
Tout ceci permet de se prémunir contre un site hostile qui intégrerait l’afficheur, y ajoutant une couche invisible pour tromper l’utilisateur et le pousser à cliquer sur des commandes telles que « Prendre le contrôle » ou « Approuver ».
Se connecter en toute sécurité
Un mot de passe ne doit jamais revenir au modèle, se retrouver dans un chronogramme d’actions ou figurer dans un journal d’audit. Deux modèles de connexion respectent cette exigence.
L’un d’eux repose sur un contrôle manuel : l’agent transmet le navigateur à l’utilisateur, qui se connecte directement sur le site, avant que le contrôle ne revienne à l’agent.
L’autre modèle consiste en un défi de authentification sécurisée dédié. Dans ce cas, l’agent localise les champs visibles spécifiques dans le document actuel, et l’afficheur de confiance affiche un formulaire de identifiants masqués indiquant l’origine exacte de destination. Ce que l’utilisateur tape est transmis directement depuis l’afficheur au service de remplissage du formulaire, puis dans les champs du navigateur validés. Un défi est associé à l’origine, à la tâche, à la session et à l’onglet, ainsi qu’à la génération du document, au chemin de la fenêtre, au sélecteur, au type de champ attendu et à une courte période de validité. Seuls les détails d’état non secrets sont visibles pour le modèle.
La connexion par QR code peut également être gérée en toute sécurité. L’agent capture l’image QR visible, prouve qu’elle peut être décodée, jette le contenu décodé et n’affiche l’image que dans l’afficheur en direct sécurisé. La valeur associée au QR code n’atteint jamais l’agent.
Autorisations avant toute action ayant des conséquences
Être autorisé à accéder à un site web et être autorisé à effectuer une action sur celui-ci sont deux décisions distinctes. Permettre à un agent d’ouvrir la page d’un restaurant ne donne pas l’autorisation de faire une réservation, et l’accès à un magasin en ligne ne permet pas de passer une commande. Cloud Browser évalue le risque au moment où l’action est exécutée. Une approbation peut être requise pour des actions telles que :
- réserver une table ou un rendez-vous
- acheter quelque chose ou effectuer un paiement
- modifier des comptes ou des permissions
- supprimer des éléments
- envoyer des messages au nom de l’utilisateur
- stocker des identifiants
- telecharger des fichiers
- accorder des permissions au navigateur
- transmettre des données sensibles
Chaque approbation est liée à une action, une cible, une destination, un document et un ensemble de catégories de données précis, de sorte qu’elle devient inutile après modification de la page ou pour un autre bouton. L’envoi de données sensibles est évalué indépendamment de l’action finale. Saisir une adresse e-mail dans un formulaire tiers pourrait nécessiter une approbation liée à cette destination avant que le clic final « Soumettre » ne demande une confirmation distincte. C’est l’utilisateur qui approuve ; Cloud Browser assure le respect des règles, tandis que l’application d’agent encadre la décision.
Captures d’écran, artefacts et rejeu
Les captures d’écran permettent une compréhension rapide, fournissent des preuves durables et aident au diagnostic des pannes. Une demande de capture d’écran renvoie une image à afficher immédiatement ainsi qu’un ID d’artefact opaque, et aucun chemin de système de fichiers serveur n’atteint l’agent. Les artefacts appartiennent à la tâche qui les a générés, expirent rapidement, sont soumis à des limites de taille et de nombre, passent par des routes signées, ne peuvent être téléchargés que dans des racines locales configurées, et sont écrits avec des permissions réservées au propriétaire sans écraser un fichier existant.
Une navigation réussie peut également créer une chronologie de captures d’écran limitée dans le temps. Chaque entrée comprend une date et heure, un nom d’hôte, l’origine, un résumé de l’action et éventuellement un artefact de capture d’écran. Un curseur permet à l’utilisateur d’examiner un état précédent du navigateur, et le choix de « LIVE » ramène à la session WebRTC en cours.
Les étapes sensibles bénéficient d’un traitement spécial. La saisie des identifiants n’est jamais enregistrée, et lorsque une action transmet des informations sensibles, le chronogramme ne conserve que des métadonnées minimales tout en omettant délibérément l’image d’écran.
La fonction de rejouement va au-delà d’une simple touche esthétique, car elle répond à des questions pratiques :
- Qu’y avait-il à l’écran pour l’agent juste avant le clic ?
- Un pop-up est-il apparu en cours de route ?
- Un autre élément aurait-il pu se superposer à l’élément cible ?
- Quelque chose sur la page a-t-il changé visiblement par la suite ?
- La tâche a-t-elle été bloquée sur le site ou en attente de l’approbation de l’utilisateur ?
Pop-ups, redirections et pages complexes
Les flux de travail réels ne restent rarement dans une seule fenêtre. Un processus de réservation peut afficher une boîte de dialogue, un fournisseur d’identité peut passer par plusieurs origines, un document de bureau peut tenter de lancer une application desktop, et une page de réunion peut proposer à la fois un lien vers une application et une alternative en ligne. Cloud Browser traite de telles transitions comme des événements de premier ordre.
Lorsqu’une action ouvre une nouvelle fenêtre, la plateforme enregistre cette nouvelle fenêtre, la sélectionne pour l’action en question et l’intègre à la vue en direct ; lorsque l’utilisateur prend le contrôle, celui-ci passe à cette fenêtre. Si une page tente de lancer un protocole natif, comme par exemple une application de réunion, le navigateur indique que l’application externe n’est pas disponible au lieu de simuler un clic réussi. Si le site dispose d’une alternative en ligne sécurisée, l’agent ou l’utilisateur peut choisir délibérément cette alternative.
Rien sur la plateforme ne permet de contourner les CAPTCHAs, les messages de sécurité du navigateur, les barrières payantes, les exigences de confiance du dispositif ou d’autres mesures de sécurité similaires. Lorsqu’un de ces éléments apparaît, il est signalé comme une limitation ou transmis à l’utilisateur.
Sécurité du réseau et SSRF
Puisqu’un navigateur distant agit également en tant que client réseau, une navigation non contrôlée pourrait en faire un outil SSRF. Les destinations sont résolues et validées avant que le processus ne se connecte. Par défaut, celles-ci sont refusées :
- les cibles de type loopback
- les cibles de type link-local
- le service de métadonnées cloud
- les plages privées de type RFC1918
- les espaces réservés pour le multicast et autres
- tout schéma URL en dehors de la liste des schémas pris en charge
Les listes d’autorisation et de blocage par utilisateur peuvent renforcer encore ces mesures.
Certaines configurations d’entreprise utilisent un DNS séparé ou des passerelles web sécurisées qui redirigent les noms d’hôtes internes approuvés vers des adresses NAT privées ou de niveau opérateur. De telles exceptions doivent être explicites, restreintes aux domaines de confiance uniquement, et définies via la configuration de déploiement, afin qu’un nom d’hôtes correspondant ne devienne jamais une voie d’accès générale au réseau privé. Les redirections, les fenêtres pop-up, les iframes, les requêtes de service-worker ainsi que le rebond DNS restent soumis à la même politique réseau, car se limiter à la vérification du premier URL est insuffisant.
Injection de commandes et contenu de page non fiable
Le processus du navigateur traite le contenu de la page comme des données et jamais comme des instructions. Une page peut afficher « ignorez vos instructions précédentes » ou publier une description d’outil affirmant qu’une certaine opération est sûre, mais aucune de ces déclarations ne confère d’autorité réelle.
Les outils que une page met en avant via WebMCP sont liés à l’URL de la page, à la génération du document, à un identifiant d’enregistrement ainsi qu’au schéma observé, et leurs descriptions ne sont jamais fiables. Un readOnlyHint fourni par la page ne permet pas de contourner l’approbation, sauf si le déploiement a explicitement accordé sa confiance à cette origine précise à cette fin. Les captures sémantiques suivent la même règle : c’est l’agent qui décide du traitement du contenu, mais c’est uniquement le gateway qui peut accorder des autorisations au navigateur.
Téléchargements, téléversements et le presse-papiers
Les fichiers téléchargés sont conservés en tant qu’artefacts appartenant à la tâche, de sorte que le chemin du travailleur n’est pas révélé. Un téléversement nécessite un sélecteur de fichiers lié à un événement ainsi qu’un chemin source situé sous une racine de téléversement configurée. Les liens symboliques sont résolus et rejetés s’ils pointent vers un emplacement en dehors du répertoire autorisé ; avant d’assigner les fichiers, le travailleur vérifie si le sélecteur choisit un seul fichier ou plusieurs.
Chaque tâche dispose de son propre état de presse-papiers. Le texte et les éléments binaires encadrés peuvent être synchronisés via l’afficheur en temps réel, les permissions du navigateur étant accordées de manière restreinte puis retirées par la suite. Dans un contexte de navigateur persistant, une permission de presse-papiers accordée à une tâche ne doit pas rester active pour une autre.
Cycle de vie et nettoyage
Le nettoyage doit être exécuté même si l’agent ne termine jamais proprement sa tâche. Le service reçoit un signal explicite de fin de tour qui distingue les tours terminés, interrompus, arrêtés ou arrêtés par un sous-agent, et le nettoyage qu’il déclenche est limité et idempotent. Chaque onglet peut porter l’une de trois marques :
- un onglet en cours d’utilisation, fermé à la fin du tour
- un résultat à fournir, conservé pour l’utilisateur
- une transmission en attente, laissée ouverte pour que l’utilisateur puisse continuer
Les marques liées à un tour sont effacées une fois leur action accomplie, ce qui oblige à conserver délibérément l’onglet lors d’un tour ultérieur. D’autres étapes de nettoyage proviennent des baux de session, des délais d’inactivité, de l’expiration des artefacts, du nettoyage des profils orphelins et de la fermeture progressive du gateway.
Observabilité sans fuite de données privées
Les journaux du gateway enregistrent les événements opérationnels liés à la création de sessions, à la navigation, aux décisions de politique, aux transferts de contrôle, aux mutations, aux pannes et aux opérations de nettoyage. Un enregistrement d’audit doit contenir des identifiants et des résultats, plutôt que des identifiants de connexion ou le contenu des pages. Les URL sont raccourcies autant que possible pour ne conserver que leurs parties sûres, et les requêtes, les valeurs de formulaire, les mots de passe, les tokens ainsi que les données personnelles sont masqués ou supprimés.
Les signaux opérationnels utiles incluent :
- la latence au niveau du gateway et des workers
- le nombre de sessions et de navigateurs existants
- les pairs WebRTC connectés
- les catégories de refus de politique qui se produisent
- la fréquence à laquelle les cibles deviennent obsolètes
- les résultats non confirmés
- les workers qui échouent à démarrer
- le succès des connexions en vue en direct
- les artefacts créés et expirés
- les opérations de nettoyage qui échouent
L’utilisateur signale le moment précis où la vidéo atteint réellement l’état de lecture, car la simple génération d’une URL signée ne prouve pas que l’utilisateur peut voir quoi que ce soit.
Fiabilité et tests de charge
Les échecs les plus insidieux liés à l’automatisation des navigateurs sont ceux qui restent silencieux : un clic sans effet, une saisie effectuée deux fois, une fenêtre contextuelle invisible, ou une action réexécutée après expiration du délai. Une série de tests sérieuse doit donc aller bien au-delà d’une navigation sans problème. Cloud Browser teste ces aspects :
- de nombreux utilisateurs et sessions en même temps
- séparation entre les tâches et entre les éléments générés
- mutations qui doivent être idempotentes
- références à des documents obsolètes
- suivi des fenêtres contextuelles
- cibles à l’intérieur d’iframes et de racines d’ombre
- reconnexion via WebRTC
- conflits lors du changement de contrôle
- pages en cours d’exécution ou temporairement figées
Les tests de charge devraient associer des workers Chromium réels à de nombreux viewers WebRTC en même temps. Les tests unitaires couvrent bien la logique des politiques et des protocoles, mais les conflits lors du démarrage du navigateur, de la diffusion vidéo, du focus, du choix des popups et de la livraison des entrées ne se manifestent qu’avec une charge réelle.
Modèle de déploiement
L’architecture de référence peut fonctionner en tant que nœud unique, bien que ses interfaces soient conçues pour un plan de contrôle de production plus étendu. Un déploiement de base relie ces éléments entre eux :
TLS ingress
-> Cloud Browser gateway
-> isolated browser workers
-> encrypted profile and artifact volume
Le navigateur doit fonctionner en tant qu’utilisateur non privilégié au sein d’un profil seccomp adapté, avec des ressources CPU et mémoire limitées ainsi que suffisamment de mémoire partagée pour Chromium. Les conteneurs constituent un point de départ pratique, tandis que les environnements à plus haut risque peuvent choisir une microVM par processus du navigateur afin d’obtenir une isolation plus forte.
Les déploiements d’entreprise ajoutent généralement :
- un authentification OIDC pour la console autonome
- une authentification machine à machine pour les agents
- l’identité de l’utilisateur final transmise par des backends fiables
- Redis, afin de stocker des contrats distribués et des clés d’idempotence
- PostgreSQL ou une plateforme d’audit dédiée pour enregistrer les événements permanents
- un stockage d’objets chiffré pour les artefacts
- un planificateur chargé de placer les processus
- des serveurs TURN émettant des identifiants WebRTC à durée de vie courte
- un gestionnaire de secrets avec rotation des clés
- un routage régional ainsi que des contrôles de résidence des données
Le gateway ne doit être accessible depuis l’extérieur qu’via HTTPS. Le HTTP simple n’est adapté qu’à des développements en boucle locale explicite.
Configuration, variable par variable
env définit l’identité réseau du gateway, le comportement du navigateur, les paramètres de stockage, l’isolation ainsi que les limites des politiques. Il doit être considéré comme une configuration de déploiement et non comme le code source de l’application. L’exemple ci-dessous peut être affiché sans risque, car ses valeurs sont indicatives et ne contiennent aucun jeton réel ni secret de signature :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
C’est l’interface réseau sur laquelle le routeur écoute.
CB_HOST=127.0.0.1
Avec 127.0.0.1, le service ne répond qu’à la machine locale, ce qui représente le choix le plus sûr lors du développement de l’interface utilisateur de l’agent, de l’adaptateur MCP et du gateway sur un seul ordinateur. Un conteneur peut avoir besoin de 0.0.0.0 afin que son réseau ou un proxy d’entrée puisse se connecter, mais cela ne justifie pas pour autant de publier ce port sur Internet ; les gateways en environnement de production restent protégés par des connexions TLS authentifiées, des règles de pare-feu et une autorisation au niveau du service. Notez également que CB_HOST détermine l’endroit où le processus écoute, et non les URLs des liens en vue en direct, ce qui est géré par CB_PUBLIC_URL.
CB_PORT
C’est le port TCP utilisé par le gateway.
CB_PORT=8787
Tout nombre allant de 1 à 65535 est acceptable, et la valeur par défaut pour le développement est 8787. Ce numéro ne doit pas être utilisé sur l’interface choisie. Si un proxy inversé ou un conteneur expose un autre port externe, CB_PORT reste le port d’écoute interne tandis que CB_PUBLIC_URL indique l’adresse visible par les utilisateurs extérieurs.
CB_PUBLIC_URL
URL de base publique : c’est celle que le gateway utilise pour créer des liens signés permettant une visualisation en direct.
CB_PUBLIC_URL=http://127.0.0.1:8787
C’est plus qu’une simple étiquette, car l’interface utilisateur reçoit les capacités de l’utilisateur dérivées d’elle, et elle doit donc être accessible depuis le navigateur qui affiche la vue en direct. Le développement local prend en charge HTTP loopback :
CB_PUBLIC_URL=http://127.0.0.1:8787
Un déploiement à distance nécessite une origine HTTPS accessible depuis l’extérieur :
CB_PUBLIC_URL=https://browser.example.com
Évitez d’inclure des chemins, des requêtes, des noms d’utilisateurs intégrés, des mots de passe et des secrets bruts dans cette URL, et mettez fin au TLS à un point d’entrée fiable ou directement sur le gateway. Un autre piège : 127.0.0.1 désigne toujours la machine sur laquelle vous vous trouvez. Supposons que l’interface utilisateur de l’agent fonctionne sur un ordinateur portable tandis que le gateway se trouve sur un serveur ailleurs. Un lien destiné à un utilisateur, construit avec 127.0.0.1, mènera alors directement au portable et n’atteindra jamais le gateway.
CB_TOKENS
Ce paramètre liste les identifiants de service que le gateway accepte. Chaque entrée suit un format précis :
<bearer-token>:<tenant-id>:<service-principal>[:scope]
Une identité de backend déléguée a cet aspect :
CB_TOKENS=replace-with-a-long-random-token:tenant-example:agent-service:delegate
Les virgules servent à séparer les différentes entrées. Le premier champ correspond au jeton de porteur, qui se trouve dans l’en-tête HTTP Authorization ; il doit faire au moins 20 caractères, être généré à l’aide d’une source aléatoire cryptographiquement sécurisée et stocké dans un gestionnaire de secrets. L’ID du locataire constitue la limite d’isolation la plus externe, de sorte que les sessions, les tâches, les profils, les onglets et les artefacts ne la franchissent jamais. Le principal désigne le service qui détient les identifiants, et en l’absence de délégation, les sessions s’exécutent sous ce principal.
La portée optionnelle delegate permet à un backend de confiance d’envoyer l’en-tête X-Cloud-Browser-Principal indiquant le véritable utilisateur final. La session appartient alors à cet utilisateur, tandis que le journal d’audit enregistre séparément quel backend a agi en son nom. Seules les applications côté serveur de confiance devraient disposer de cette délégation. Un client desktop ou un jeton d’utilisateur ordinaire ne devrait pas en bénéficier, car ils pourraient sinon revendiquer l’identité d’un autre utilisateur au sein du tenant.
Tant les jetons configurés que ceux présentés sont hachés avant une comparaison en temps constant, ce qui réduit les fuites liées à la longueur du jeton, mais ne rend pas un jeton divulgué sûr pour autant. Renouvelez immédiatement un jeton s’il apparaît dans une capture d’écran, un dépôt, une enregistrement de terminal ou un ticket de support. Et n’utilisez pas à nouveau ce même jeton comme CB_LIVEVIEW_SECRET, car les deux protègent des fonctionnalités différentes et nécessitent une génération indépendante.
CB_MAX_SESSIONS_PER_PRINCIPAL
Ce paramètre fixe le nombre maximal de sessions simultanées qu’un utilisateur actif peut avoir.
CB_MAX_SESSIONS_PER_PRINCIPAL=8
Les valeurs autorisées vont de 1 à 128, avec une valeur par défaut de 8. Cette limite empêche les attaques accidentelles provenant des navigateurs ainsi que le fonctionnement anormal des agents, et empêche un utilisateur d’épuiser la capacité globale ; elle s’ajoute à la limite de sessions définie au niveau du gateway. La valeur idéale dépend de la mémoire et du CPU des travailleurs, du mode de profil ainsi que du niveau de concurrence attendu. Même si un profil persistant partage un processus navigateur entre les différentes tâches d’un utilisateur, chaque tâche consomme néanmoins des ressources liées aux onglets, au streaming, aux artefacts et au gateway.
CB_LIVEVIEW_SECRET
C’est la clé HMAC qui signe les fonctionnalités de visualisation en direct.
CB_LIVEVIEW_SECRET=replace-with-a-separate-random-signing-secret
Chaque champ présent dans le jeton signé (tenant, principal, task, session, tab, expiry) est couvert par la signature ; par conséquent, modifier l’un d’eux la rend invalide. Une déploiement accessible depuis l’extérieur nécessite son propre secret de 32 caractères ou plus ; en pratique, cela signifie au moins 32 octets aléatoires en format hexadécimal ou Base64, chargés depuis un gestionnaire de secrets. La fuite d’un secret permettrait à un attaquant disposant des métadonnées de session nécessaires de falsifier les capacités du visualiseur. La rotation invalide les signatures récemment vérifiées utilisant l’ancienne clé, il convient donc de la synchroniser avec l’expiration des sessions en mode visionnage en direct. Gardez cette valeur à l’écart des agents, des pages navigateur, des bundles clients, des journaux et des dépôts.
CB_LIVEVIEW_FRAME_ANCESTORS
Ce paramètre détermine quels applications web fiables peuvent intégrer le visualiseur signé dans un iframe.
CB_LIVEVIEW_FRAME_ANCESTORS=http://localhost:8088,http://127.0.0.1:8088
Le gateway convertit cette liste en la directive frame-ancestors de la politique de sécurité des contenus du navigateur. Si cette valeur est vide, le navigateur envoie frame-ancestors 'none' ainsi que X-Frame-Options: DENY, ce qui permet à la page de fonctionner en tant que page indépendante tout en refusant d’être incrustée. Lorsque des origines sont listées, seules celles-ci peuvent l’incarner, et X-Frame-Options: DENY n’est pas inclus car cet ancien en-tête ne peut pas spécifier plusieurs origines et annulerait ainsi l’effet de la liste d’autorisation.
Les entrées doivent correspondre à des origines HTTP ou HTTPS exactes ; les chemins, les identifiants URL, les requêtes, les fragments et les wildcards sont rejetés. Le schéma, l’hôte et le port comptent tous, de sorte que les trois exemples suivants représentent des origines distinctes :
http://localhost:8088
http://127.0.0.1:8088
https://agent.example.com
Cette configuration n’a pas trait à CORS. Elle protège la page d’affichage puissante contre le clickjacking, il faut donc ne lister que les interfaces qui ont réellement besoin d’afficher le navigateur en temps réel.
CB_HEADLESS
Ce paramètre détermine si le processus secondaire lance le navigateur sans fenêtre de bureau native.
CB_HEADLESS=true
Avec true, Chromium ou Chrome s’exécute en mode sans interface graphique, et les utilisateurs observent et contrôlent l’affichage en direct via WebRTC plutôt qu’à travers une fenêtre locale de Chrome. Les serveurs et les conteneurs préfèrent généralement ce mode, car il consomme moins de ressources du poste de travail et permet à l’automatisation de fonctionner indépendamment d’une session d’affichage native. Avec false, le navigateur s’exécute avec une interface graphique et a besoin d’un écran fonctionnel, généralement virtuel comme Xvfb ou une image de travail pour la diffusion sur le bureau sous Linux ; sous macOS, il ouvre une fenêtre de navigateur distincte, sauf si l’architecture du travailleur diffère. Changer cette valeur ne fait jamais en sorte que le Cloud Browser prenne le contrôle d’une fenêtre personnelle de Chrome déjà ouverte. Cela affecte uniquement la manière dont le navigateur géré par le travailleur démarre.
CB_SERVICE_WORKERS
Ce paramètre détermine si les sites web peuvent enregistrer et exécuter des service workers.
CB_SERVICE_WORKERS=allow
Choisissez allow ou block ; block est la valeur par défaut sûre. Les applications web progressives, les applications de visioconférence, les logiciels de bureau et les sites fortement mis en cache dépendent souvent des service workers et peuvent ne pas fonctionner, rester bloqués sur une page de chargement ou sembler figés sans eux. Activer ces derniers améliore la compatibilité, mais augmente également les capacités de réseau et de stockage du navigateur ; vérifiez donc au préalable que les demandes des service workers respectent toujours les règles de navigation, les règles de sortie, les mesures de prévention de perte de données et les politiques en vigueur. Choisissez allow uniquement pour une application validée qui en a besoin, et jamais comme solution universelle.
CB_BROWSER_CHANNEL
Ce paramètre sélectionne un canal de navigateur installé système plutôt que le Chromium intégré à Playwright.
CB_BROWSER_CHANNEL=chrome
Quatre canaux sont acceptés : chrome, chrome-beta, chrome-dev et msedge. Laissez ce champ vide pour utiliser l’exécutable Chromium configuré ou le bundle Playwright. Des versions réelles de Chrome ou Edge sont parfois nécessaires lorsque l’entreprise vérifie la fiabilité du dispositif, gère les navigateurs de manière centralisée, applique des politiques ou délivre des certificats clients. Le choix de chrome ne charge pas le profil normal de Chrome de l’utilisateur, car les profils proviennent toujours de CB_PROFILE_MODE et CB_PROFILE_DIR ; ainsi, Cloud Browser ne peut pas s’associer silencieusement à une session interactive personnelle. Le canal doit être installé sur l’hôte du travailleur, et la fiabilité du dispositif peut également nécessiter le bon profil, l’inscription au système d’exploitation, des certificats, des politiques ou des extensions ; cette configuration en soi ne crée pas de confiance d’entreprise.
CB_EXTENSION_PATHS
Une liste séparée par des virgules des dossiers des extensions de navigateur déballées.
CB_EXTENSION_PATHS=
Laissez ce champ vide pour ne pas charger d’extensions non déballées. Les chemins indiqués sont transmis au navigateur géré via des paramètres de chargement d’extensions, ce qui ne fonctionne que si CB_HEADLESS=false et que le CB_PROFILE_MODE est réglé sur task ou persistent ; les contextes éphémères et les exécutions headless classiques ne permettent pas un fonctionnement sécurisé. Le chargement d’extensions non déballées est destiné au développement et aux tests contrôlés. Les entreprises en environnement de production doivent installer de force les extensions approuvées via des politiques Chrome ou Edge, fixer leurs identifiants et mettre à jour leurs sources, ainsi que vérifier les permissions. Comme une extension s’exécute avec les privilèges du navigateur et peut observer ou modifier l’activité sur le web, son origine, son chemin de mise à jour, ses permissions et son propriétaire font tous l’objet d’une analyse de sécurité.
CB_PROFILE_MODE
Ce paramètre détermine comment l’état du navigateur est isolé et pendant combien de temps l’état de connexion reste valide.
CB_PROFILE_MODE=persistent
Le mode peut être ephémère, tâche ou persistent. En mode ephémère, un contexte de navigateur temporaire est créé sans répertoire de profil reutilisable, offrant ainsi l’isolation la plus stricte par défaut, idéale pour une navigation anonyme ou des travaux ne devant laisser aucune trace d’identification. Le mode tâche crée un répertoire de profil pour une seule tâche : les cookies et l’état persistent tant que dure la tâche, puis le répertoire est supprimé lors du nettoyage. Le mode persistent partage un seul profil entre les tâches appartenant au même utilisateur et principal actif, de sorte que les cookies et les sessions de site survivent aux nouvelles tâches et aux redémarrages du pare-feu, bien que chaque tâche conserve sa propre gestion des onglets, l’onglet sélectionné, le presse-papiers, les flux en direct, les artefacts et les contrats de gestion. Le mode persistant est le plus pratique mais aussi le plus risqué ; il faut utiliser un stockage chiffré, des permissions de répertoire strictes, des processus d’identification et de suppression explicites du profil, ainsi qu’une limitation du temps d’inactivité.
CB_PROFILE_DIR
Dossier racine dans lequel se trouvent les données du navigateur basées sur des profils.
CB_PROFILE_DIR=./var/profiles
Un chemin relatif est résolu par rapport au répertoire de travail du processus de passerelle. Dans les conteneurs, montez un volume protégé ici si les profils doivent survivre au remplacement du conteneur. La passerelle crée elle-même des sous-dossiers spécifiques aux utilisateurs et aux principaux, et n’accepte jamais de chemins de profils choisis par les agents. Les dossiers doivent être réservés au propriétaire uniquement et ne doivent jamais être mis à disposition pour téléchargement. Ne ciblez pas cette configuration sur le profil Chrome d’une personne réelle ; copier ou ouvrir simultanément un profil en cours d’utilisation peut le endommager et exposer des données de navigation non liées au travailleur.
CB_ARTIFACT_DIR
Lieu où sont stockées les captures d’écran appartenant aux tâches, les téléchargements, le contenu exporté, les images de rejeu et d’autres artefacts définis.
CB_ARTIFACT_DIR=./var/artifacts
Les chemins relatifs sont résolus à partir du répertoire de travail du gateway. Les agents reçoivent des identifiants d’artefacts opaques au lieu de chemins, et chaque récupération vérifie le locataire, l’entité principale, la tâche, la date d’expiration et le propriétaire. Rendez le répertoire écrivable uniquement pour le compte de service Cloud Browser, fixez la durée de vie des artefacts, comptez leur nombre et leur taille, supprimez les fichiers expirés, chiffrer le stockage sous-jacent et évitez de conserver indéfiniment des artefacts temporaires dans les sauvegardes. Les profils et les artefacts ont des finalités différentes : une capture d’écran peut parvenir à un utilisateur, tandis qu’un profil de navigateur ne doit jamais être traité comme un artefact téléchargeable.
CB_AUDIT_FILE
Le chemin du journal d’audit JSON Lines limité.
CB_AUDIT_FILE=./var/audit.log
Chaque ligne représente un événement structuré lié à des actions telles que la création d’une session, l’exécution d’une commande, un refus de politique, un transfert de contrôle, le résultat d’une connexion en vue en direct, la destruction d’une session ou une échec de nettoyage. Enregistrez qui et ce qui s’est passé, sans inclure les valeurs des formulaires ou le contenu des pages, et masquez ou omettez les identifiants, tokens, requêtes ainsi que les données sensibles des utilisateurs. En environnement de production, considérez le JSONL local comme un format de développement ou de transport et envoyez les événements vers une plateforme d’audit fiable offrant des politiques de conservation, un contrôle d’accès, une protection de l’intégrité, des alertes et des investigations adaptées aux différents utilisateurs.
CB_USER_AGENT
Une valeur facultative permettant de modifier la chaîne User-Agent du navigateur.
CB_USER_AGENT=
Mieux vaut le laisser vide. Le moteur de rendu crée une identité Chrome normale à partir de la version du navigateur et fournit des indications correspondantes, évitant tout désaccord entre l’en-tête de requête, navigator.userAgent et navigator.userAgentData. Une chaîne personnalisée ne remplace que l’User-Agent, sans création d’indications correspondantes, et certains fournisseurs d’identité ainsi que des détecteurs de bots repèrent cette incohérence. Ne l’utilisez pas pour présenter un navigateur ancien comme étant plus récent ou pour contourner la politique de sécurité d’un site ; conservez-le uniquement pour une exigence de compatibilité documentée et vérifiez par la suite l’identité complète du navigateur.
CB_ALLOW_ORIGINS
La liste des origines autorisées pour la navigation de l’utilisateur.
CB_ALLOW_ORIGINS=
Si la liste est vide, les destinations HTTP et HTTPS publiques sont autorisées à moins qu’une autre politique ne s’interpose, tandis que les destinations réseau privé, métadonnées, link-local, réservées et non prises en charge continuent d’être bloquées par le pare-feu réseau. Une fois que la liste contient des entrées, chaque navigation doit correspondre à au moins une règle, écrite sous forme d’adresse originale exacte telle que https://portal.example.com, d’un suffixe wildcard comme *.example.com ou d’un nom de hôte simple comme portal.example.com. Lorsque le protocole ou le port est important, il convient d’utiliser une adresse originale exacte. Un wildcard couvre le nom de hôte principal ainsi que ses sous-domaines, il faut donc en utiliser avec prudence. Être présent sur la liste des autorisations ne donne pas d’autorisation pour une IP privée, car la classification DNS et la politique des origines privées fiables sont évaluées séparément.
CB_BLOCK_ORIGINS
La liste noire explicite des navigations interdites.
CB_BLOCK_ORIGINS=
Les règles utilisent les mêmes trois formes que la liste d’autorisation, et c’est cette dernière qui est consultée en premier ; tout élément correspondant aux deux listes est bloqué. Les utilisations typiques concernent des points d’accès administratifs sensibles, des applications non prises en charge, des destinations connues comme dangereuses, ou un sous-domaine qui doit être exclu d’une liste d’autorisation plus large. La classification du réseau s’applique même si la liste est vide.
CB_TRUSTED_PRIVATE_ORIGINS
Noms de hôtes d’entreprise qui peuvent résoudre en adresses privées ou CGNAT.
CB_TRUSTED_PRIVATE_ORIGINS=*.company.example
Il existe pour gérer les configurations DNS séparées, où un nom de hôte d’entreprise approuvé se résout différemment sur le VPN ou le réseau interne. Les règles suivent la syntaxe de liste de navigation. Restreignez-les aux domaines appartenant à l’organisation, et évitez d’ajouter des wildcards génériques ou des noms de hôte simplement parce qu’une application se comporte mal. Une correspondance fiable peut autoriser des cibles RFC1918 ou CGNAT, mais jamais du routage en boucle, des adresses locales de lien, des métadonnées cloud, du multicast ou des adresses réservées. Examinez-le comme une exception SSRF : la plateforme doit avoir un contrôle total sur le DNS, les sorties réseau et la propriété de chaque suffixe fiable.
CB_ALLOW_CGNAT_NAVIGATION
Permet la navigation vers la plage NAT de niveau opérateur, 100.64.0.0/10.
CB_ALLOW_CGNAT_NAVIGATION=true
La valeur par défaut est false. Dans certains réseaux d’entreprise, un VPN ou une passerelle web sécurisée expose des services publics ou internes à des adresses situées dans l’espace CGNAT. Activer ce paramètre les autorise et peut désactiver les restrictions d’accès au réseau local du navigateur qui empêcheraient une page d’atteindre l’adresse synthétique. Cela va au-delà de la simple confiance en un nom d’hôte ; utilisez donc CB_TRUSTED_PRIVATE_ORIGINS si seuls des domaines d’entreprise connus en ont besoin. Les plages RFC1918, loopback, link-local, métadonnées, multicast et réservées restent fermées, mais la portée du réseau augmente considérablement ; activez-le uniquement dans un environnement d’entreprise contrôlé.
CB_REQUIRE_APPROVAL
Active le mécanisme d’approbation général de la passerelle pour les commandes classées comme importantes.
CB_REQUIRE_APPROVAL=false
Avec true, les commandes conséquentes sont bloquées jusqu’à ce qu’une approbation précise au moment de l’exécution soit reçue. Avec false, le verrou est levé, ce qui est judicieux si une application d’agent fiable applique déjà des règles plus strictes. Cependant, la sécurité n’est pas désactivée. Les risques reconnus tels que la transmission de données sensibles, leur suppression, les paiements, les réservations, l’envoi de messages au nom de quelqu’un, les modifications de compte ou de permissions, l’accès à l’historique ainsi que les outils de pages non classées nécessitent toujours une approbation. Le contrôle relève d’un autre axe : les actions de l’agent restent bloquées tant que l’utilisateur tient le navigateur. Pour un produit autonome partagé par plusieurs agents, il est généralement plus judicieux de maintenir l’application des règles de sécurité, car la sécurité ne dépend alors pas du fait que chaque client mette en œuvre correctement les politiques.
CB_ALLOW_LOOPBACK_NAVIGATION
Un commutateur de développement permettant au navigateur de l’opérateur d’accéder aux adresses loopback (localhost, 127.0.0.1 ou ::1).
CB_ALLOW_LOOPBACK_NAVIGATION=true
La valeur par défaut est false. Les tests automatisés et les applications web locales sur la même machine que le processus bénéficient de cette fonctionnalité. Elle ne permet pas à un navigateur distant d’accéder au ordinateur portable de l’utilisateur, car sur un environnement distant 127.0.0.1 représente l’environnement distant. Évitez d’activer cette fonctionnalité à la légère en production : l’accès par boucle locale peut révéler des ports administratifs internes, des serveurs de développement, des interfaces de débogage ainsi que des services conçus en supposant que du contenu web non fiable ne pourrait pas y accéder. Même lorsqu’elle est activée, l’adresse hôte doit se résoudre uniquement en adresses de boucle locale, afin qu’une réponse DNS mixte ne permette pas d’étendre cette exception en un contournement général.
CB_SYNTHETIC_MEDIA_DEVICES
Fournit au navigateur géré un micro et une caméra synthétiques.
CB_SYNTHETIC_MEDIA_DEVICES=true
De même, la valeur par défaut est false. Les navigateurs headless affichent souvent aucun appareil média, et certains sites de réunions et d’enregistrement vérifient la présence d’un micro ou d’une caméra avant de poursuivre, ce qui fait que la page semble bloquée en l’absence d’appareil détecté. Des appareils synthétiques permettent à ces vérifications de réussir : le micro reste silencieux et la caméra affiche un motif de test au lieu d’une vidéo réelle. Rien dans ce système ne capte le micro ou la caméra physique de quiconque, et il ne faut jamais le décrire de cette manière. Si l’application rejoint une réunion réelle, désactivez sa caméra à moins que le motif de test ne doive être diffusé. Le site peut toujours demander l’autorisation, et l’accord à cette demande relève d’une décision de politique distincte de la simple mise à disposition d’un appareil.
Interprétation de l’exemple comme une seule déploiement
Dans son ensemble, la configuration de exemple décrit un environnement de développement local :
- Le gateway n’accepte que des connexions locales, sur le port
8787.
8088 sous n’importe quel nom de hôte.Ce profil fonctionne comme un profil d’intégration locale, mais il ne constitue pas de référence pour la production. Avant le lancement : transférez l’URL publique vers HTTPS, mettez à jour régulièrement tous les secrets et conservez-les en dehors du fichier, désactivez le loopback, restreignez les exceptions liées aux CGNAT et aux origines privées, examinez l’accès du service-worker, activez la politique d’approbation du gateway, stockez les profils et les artefacts dans un stockage géré chiffré, et acheminez les événements d’audit vers une plateforme fiable.
Connexion d’un agent
Un agent compatible MCP peut lancer l’adaptateur en tant que processus local et le diriger vers le gateway. Les identifiants réels restent hors du contrôle de version, il convient donc d’utiliser des placeholders tels que ceux-ci :
{
"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"
}
}
}
}
Une interaction typique se déroule alors de la manière suivante :
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
En quoi cela diffère d’un outil de navigateur intégré à un agent
De nombreux produits d’agents intègrent leur propre outil de navigateur. Cloud Browser vise à servir de plateforme de navigation pour de nombreux agents, et sa valeur provient d’une combinaison de caractéristiques :
- il reste neutre quant au modèle utilisé
- les sessions persistent à distance
- l’interaction est à la fois sémantique et visuelle
- WebRTC permet l’observation et le contrôle
- les identifiants sont gérés de manière sécurisée
- le gateway impose les validations nécessaires
- les captures d’écran fournissent des preuves et permettent de rejouer les actions
- les artefacts sont liés aux tâches spécifiques
- le nettoyage suit un cycle de vie déterministe
- l’identité d’entreprise, les politiques et les mécanismes d’audit sont intégrés
En résumé, l’idée principale est la suivante :
Démonstratez un flux de travail une seule fois, puis exécutez-le via n’importe quel agent IA, tout en permettant à un humain d’arrêter les étapes ultérieures.
Leçons tirées de sa création
Le navigateur n’est pas la partie difficile ; c’est l’autorité qui l’est. Six leçons ont émergé de la conception.
Une vue en direct constitue une surface de sécurité et non simplement un lecteur vidéo : elle contient des contrôles, des validations, des identifiants et l’intention de l’utilisateur, ce qui exige que son URL, sa politique de mise en cadre, son expiration et son état de contrôle soient traités avec autant d’attention que les fonctionnalités API.
Faire parvenir un message n’est pas la même chose que mener à bien une interaction. Un clic peut arriver tandis que la page l’ignore simplement, c’est pourquoi les entrées nécessitent une confirmation, un examen de la page par la suite, ainsi que des étiquettes distinctes pour « livré », « modifié » et « en attente ».
Les tentatives automatiques sans contrôle sont risquées. Lorsque toute action effectuée par un navigateur peut avoir des conséquences réelles, l’idempotence et la réconciliation deviennent indispensables.
Les sessions persistantes rendent le produit à la fois plus utile et plus dangereux. Il convient de les isoler en fonction de leur identité et de les accompagner de mécanismes de déconnexion, de conservation des données, d’historique et de nettoyage.
Considérez le contenu des pages ainsi que les outils fournis par celles-ci comme non fiables. Un site peut décrire une action, mais il n’a aucun pouvoir pour l’approuver.
Finalement, disposer d’éléments de preuve clairs facilite la confiance envers l’automatisation. Grâce à un chronologique des captures d’écran et à des résumés des actions, les utilisateurs, les développeurs et les opérateurs peuvent tous comprendre une panne.
Où cela nous mène
Les agents ont besoin de navigateurs, mais les entreprises souhaitent plus que des scripts. Elles veulent une plateforme avec une responsabilité clairement définie, des autorisations temporaires, un transfert sécurisé entre utilisateurs, une connexion protégée, une approbation avant toute action ayant un impact, des résultats observables et un nettoyage fiable.
Cloud Browser transforme Playwright et Chromium en cette plateforme, en séparant la planification de l’exécution, les agents des identifiants, ainsi que les fonctionnalités du navigateur de l’autorité de l’utilisateur. C’est cette séparation qui permet à la conception d’être réutilisable : en changeant l’agent, le modèle ou l’interface, les limites de sécurité entourant le navigateur restent inchangées. C’est la base nécessaire avant que l’on puisse vraiment faire confiance à l’automatisation des navigateurs.