Navegador en la nube: Una plataforma de navegador remoto segura para cualquier agente de IA
Un diseño de referencia para un servicio de navegador remoto neutral con respecto a los modelos: gateway, workers, vista en vivo por WebRTC, aprobaciones, protecciones contra SSRF, reproducción y todos los parámetros de configuración.
Los agentes de IA han mejorado considerablemente en su capacidad para razonar sobre páginas web, pero hacer que un navegador real funcione sigue siendo más difícil de lo que parece. Hacer clic en botones es la parte sencilla. Un agente de navegador en el que la gente pueda confiar debe mantener las sesiones activas, lidiar con ventanas emergentes y redirecciones, comprender interfaces dinámicas, gestionar descargas y subidas, permitir que un humano tome el control, proteger las credenciales, solicitar permiso antes de realizar acciones importantes y, posteriormente, mostrar qué ocurrió realmente.
Cloud Browser es una solución para todo este problema: un servicio independiente de ejecución de navegadores que no se preocupa por el modelo que se encuentre al otro lado.
Un agente de escritorio, un asistente de codificación en línea de comandos, un cliente MCP o una aplicación personalizada pueden utilizarlo todos. El servicio no contiene ningún LLM en absoluto. El agente decide qué debe ocurrir, mientras que Cloud Browser se encarga del navegador, de los límites de seguridad, de la ejecución, de la vista en tiempo real, del registro de evidencias y de la limpieza posterior.
Esa separación constituye la decisión arquitectónica más importante del sistema. Si se cambia el agente, la plataforma del navegador permanece igual. Si se actualiza un proceso del navegador, el agente no necesita ser reescrito. La política de seguridad funciona de la misma manera independientemente de qué cliente se utilice.
Lo que sigue aborda la arquitectura, los límites de confianza, el modelo de interacción y las decisiones técnicas que permiten convertir la automatización de navegadores en algo que una empresa pueda utilizar.
La visión general
Un agente de IA opera un navegador remoto mientras una persona puede observar, intervenir, aprobar acciones sensibles, revisar capturas de pantalla y reproducir la tarea posteriormente. El flujo de nivel superior está diseñado intencionadamente de forma sencilla:
User
|
v
AI agent or agent application
|
| HTTPS API or MCP
v
Cloud Browser gateway
|
v
Isolated browser worker
|
v
Website
La persona observa y dirige al trabajador a través de una vista en vivo de WebRTC firmada.
Por qué Playwright no es suficiente
Playwright es un excelente motor de automatización, pero no es un producto de navegador multiusuario. Un servicio en producción debe responder a muchas preguntas que Playwright nunca plantea:
- ¿Quién es el propietario de un navegador determinado?
- ¿Qué tarea está asociada a una pestaña concreta?
- ¿Podría un segundo agente reutilizar un identificador de pestaña que no le fue asignado?
- ¿Qué sucede cuando se realiza un clic pero la respuesta de la red desaparece?
- ¿Cómo puede alguien iniciar sesión sin que la contraseña llegue nunca al modelo?
- ¿Qué impide que el navegador acceda a los puntos finales de metadatos en la nube o a redes privadas?
- ¿Quién tiene el control cuando tanto el agente como la persona están conectados?
- ¿Cómo se almacenan y descargan de forma segura las capturas de pantalla?
- ¿Qué pruebas quedan cuando una acción falla?
Al delimitar el motor dentro de un límite de servicio explícito, la plataforma puede responder a todas estas situaciones de la misma manera en cada ocasión.
Ejecución sin planificación
El servicio procesa las solicitudes sin planificar nada. No decide por sí mismo si una compra debe realizarse o si se debe enviar un mensaje. Esto permite que sea útil en diferentes agentes y establece una línea clara entre dos conjuntos de funciones.
Por parte del agente:
- comprender qué quiere el usuario
- determinar el siguiente paso
- interpretar lo que muestra actualmente el navegador
- preguntar al usuario cuando la intención no está clara
Por parte del Navegador en la nube:
- autenticar a quien realiza la llamada
- aislar las sesiones y pestañas entre sí
- aplicar la política del navegador
- validar cada destino
- ejecutar las acciones
Objetivos y referencias obsoletas
Los objetivos preferidos son semánticos: un botón, un campo de texto, una casilla de verificación, un elemento de menú o un nodo de accesibilidad visible en el documento actual. Las aplicaciones Canvas e interfaces altamente personalizadas siguen requiriendo coordenadas, las cuales son menos estables. En ese caso, Cloud Browser realiza pruebas de colisión en la ubicación e informa detalles sobre el elemento que realmente se encuentra debajo del puntero.
Un agente también puede indicar el rol o texto visible que espera. Si el elemento en el objetivo no coincide, la acción falla de forma controlada en lugar de hacer clic en algo no deseado.
Las páginas cambian constantemente. Un modal puede aparecer entre la observación y la acción, una navegación puede reemplazar todo el documento, y un popup puede convertirse en la continuación activa. Para hacer frente a esto, las referencias semánticas están vinculadas a una revisión del documento. Cualquier mutación o navegación invalida las referencias anteriores, y al intentar usar una antigua se genera un error stale_target. El resultado es un bucle seguro:
Observe -> choose one action -> validate -> execute -> observe again
Dónde se encuentran las políticas
La aprobación y las reglas de red no pueden residir únicamente dentro de una única interfaz de usuario, ya que de lo contrario otro cliente podría conectarse directamente y omitirlas. La pasarela es el punto autorizado para su aplicación. Las aplicaciones de agente pueden añadir políticas más estrictas, pero ninguna puede relajar las del servicio en sí.
Arquitectura del sistema
La implementación de referencia cuenta con tres paquetes principales además de algunos servicios de soporte.
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
La pasarela
La pasarela expone un contrato HTTPS versionado. Autentica al solicitante, determina la identidad efectiva del usuario, verifica la propiedad de la tarea, aplica cuotas, hace cumplir las políticas y envía la orden al trabajador adecuado. Las órdenes se transmiten en un sobre correlacionado que contiene la versión del protocolo, un ID de solicitud, un ID de tarea, un ID de sesión opcional, el nombre de la orden y parámetros delimitados. Las órdenes que modifican el estado también necesitan una clave de idempotencia.
Los resultados y los errores se devuelven de forma estructurada. No se permite que la información interna del navegador se filtre a través de rastros de pila aleatorios o fallos brutos del proveedor.
El adaptador MCP
Los agentes que soportan MCP se conectan a través de un adaptador deliberadamente sencillo. Chromium nunca se ejecuta en su interior y no contiene ninguna política de navegador. Su única función es mapear las llamadas de la herramienta a solicitudes al gateway: abrir una pestaña (browser_open_tab), leer el estado, hacer clic, tomar una captura de pantalla o finalizar la sesión mediante las herramientas browser_* correspondientes. De este modo, varios productos de agentes pueden compartir un mismo gateway, sin que nada específico del proveedor ingrese al worker.
El adaptador impide que el modelo acceda a las URLs de vista en vivo firmadas. Lo que recibe el agente son datos de presentación inofensivos: si existe una vista en vivo, qué pestaña muestra, quién tiene el control y cuándo vence. Solo la interfaz de usuario de confianza recibe la capacidad para ver contenido firmado.
El worker del navegador
Cada trabajador gestiona el proceso o contexto del navegador real. Las pestañas, la navegación, la extracción semántica, las entradas, las capturas de pantalla, las descargas, las subidas, el manejo del portapapeles, los diálogos y los eventos del navegador pasan por él. Playwright se encarga de la mayor parte de la automatización, y algunas operaciones de solo lectura pueden activar capacidades restringidas de CDP. El acceso ilimitado a CDP nunca se proporciona como solución universal.
Esta restricción es importante porque CDP en su forma bruta puede acceder a cookies, almacenamiento, objetivos de depuración, evaluaciones arbitrarias e información interna del navegador. Un producto seguro expone solo las capacidades mínimas que necesita una tarea.
El gestor de sesiones
El gestor de sesiones es quien controla la cadena de autoridad:
tenant
-> principal
-> task
-> session
-> tab
-> operation
Los identificadores opacos están limitados a esa cadena específica. Un identificador de pestaña emitido bajo una tarea no puede ser utilizado por otra, incluso cuando ambas comparten el mismo proceso del navegador subyacente. El administrador también se encarga de los arrendamientos, los tiempos de inactividad, el estado de control, las pestañas retenidas, el ciclo de vida del perfil y su finalización.
Perfiles de navegador y persistencia
Existen tres tipos de perfiles. Un perfil efímero se crea para sesiones de corta duración y desaparece cuando termina la tarea, lo que ofrece el nivel más alto de aislamiento por defecto. Un perfil de tarea dura todo el tiempo que dura esa tarea y permanece separado de todas las demás tareas. Un perfil persistente permite que el mismo usuario mantenga cookies y sesiones de sitios web iniciadas desde una tarea a otra.
Chrome permite solo un proceso activo por directorio de perfil, por lo que las tareas pertenecientes a la misma persona pueden compartir un proceso del navegador, mientras cada tarea mantiene sus propias pestañas, selección, marcos en tiempo real, estado del portapapeles y permisos de control.
Los perfiles persistentes requieren controles operativos más estrictos:
- El directorio del perfil solo es legible por su propietario.
- El volumen subyacente o el servicio de almacenamiento debe cifrar los datos en reposo.
- Los usuarios necesitan una forma de cerrar sesión y borrar el perfil almacenado.
- El acceso está limitado al inquilino y al principal específicos.
- La lectura del historial de navegación requiere aprobación explícita.
- Los trabajadores nunca devuelven cookies en bruto ni tokens de autenticación a un agente.
La vida útil de una orden
Cada acción sigue la misma secuencia predecible:
- Se autentica al solicitante del servicio.
Cuando ocurre un fallo de transporte después de que el navegador ya haya podido actuar, la pasarela responde con outcome_unconfirmed. El cliente entonces debe reconciliar el estado actual del navegador en lugar de repetir ciegamente ese paso. Esto es especialmente importante al reservar un lugar, enviar un formulario o transmitir un mensaje, ya que un intento automático de repetición puede generar efectos duplicados en el mundo real.
Vista en tiempo real a través de WebRTC
Es difícil confiar en un navegador en la nube que nadie puede ver, por lo que Cloud Browser ofrece una vista interactiva en tiempo real a través de WebRTC. El video fluye como una pista de medios, mientras que los eventos relacionados con el puntero, el teclado, la portapapeles, el estado, la aprobación y la transferencia se transmiten mediante un DataChannel ordenado. HTTP solo se utiliza para la señalización limitada de oferta y respuesta, y no existe un flujo de imagen secundario por WebSocket.
Enviar capturas de pantalla una y otra vez a través de un protocolo de agente sería más lento, por lo que la ruta WebRTC reduce la latencia y evita que las interacciones rápidas se confundan con las respuestas de herramientas normales. Las coordenadas del puntero se mapean dentro de los límites reales del video, incluidas las barras de letterbox. Los eventos del ratón se normalizan y se agrupan, los atajos de teclado siguen las especificaciones de la plataforma del espectador, y las confirmaciones distinguen entre entradas en cola, entregadas, modificadas, rechazadas y aún pendientes.
Intercambio de control
El espectador comienza en modo de observación mientras el agente mantiene el control. Una persona puede solicitar el control haciendo clic en la superficie del navegador o presionando el botón de control. La máquina de estados es explícita:
Agent control
-> handoff pending
-> user control
-> release pending
-> agent control
Any state
-> finalized
Mientras el usuario mantiene el control, la entrada del agente está bloqueada. El control se limita a la tarea y sigue el menú emergente seleccionado si un sitio abre una nueva ventana. Un frame de video obsoleto no puede otorgar el control, y un mensaje retrasado no puede devolverlo silenciosamente al agente, ya que la pasarela sigue siendo la autoridad sobre el estado actual.
Protegiendo al propio visor
El enlace de visualización en vivo es una capacidad con firma HMAC de corta duración vinculada a un único inquilino, principal, tarea, sesión y pestaña, y expira cuando finaliza la tarea. El encuadre está desactivado por defecto. Para incrustar el visor en una aplicación de agente de confianza, la implementación debe listar cada origen padre exacto en su Política de Seguridad de Contenido; los comodines, rutas, credenciales, consultas y fragmentos se rechazan como orígenes de encuadre.
Todo esto sirve para evitar que un sitio web hostil incruste el visor, coloque una capa invisible encima y engañe al usuario para que haga clic en controles como “Tomar el control” o “Aprobar”.
Iniciar sesión de forma segura
La contraseña nunca debe volver al modelo, quedar en una línea de tiempo de acciones ni terminar en un registro de auditoría. Dos patrones de inicio de sesión cumplen con esta promesa.
Un patrón es el control manual: el agente pasa el navegador al usuario, quien inicia sesión directamente en el sitio, y luego el control vuelve al agente.
Otro patrón es un desafío de autenticación segura dedicado. En este caso, el proceso localiza los campos visibles específicos en el documento actual, y el visualizador de confianza muestra un formulario de credenciales enmascarado que indica con exactitud el origen de destino. Lo que escribe el usuario va directamente desde el visualizador al servicio de llenado de formularios y a los campos del navegador validados. Un desafío se asocia al origen, tarea, sesión y pestaña, a la generación del documento, a la ruta del marco, al selector, al tipo de campo esperado y a un breve período de vencimiento. Solo los detalles de estado no confidenciales son visibles para el modelo.
También se puede gestionar de forma segura el inicio de sesión basado en QR. El proceso captura la imagen QR visible, verifica que se puede decodificar, descarta el contenido descodificado y muestra la imagen únicamente en el visualizador en tiempo real seguro. El valor del portador nunca llega al agente.
Aprobaciones antes de acciones con consecuencias
El hecho de permitir el acceso a un sitio web y el de permitir realizar una acción en él son decisiones separadas. Permitir que un agente abra la página de un restaurante no autoriza una reserva, y el acceso a una tienda en línea no autoriza una compra. Cloud Browser evalúa el riesgo cuando se ejecuta la acción. Puede ser necesaria la aprobación para cosas como:
- reservar una mesa o una cita
- comprar algo o realizar un pago
- editar cuentas o permisos
- eliminar cualquier contenido
- enviar mensajes en nombre del usuario
- almacenar credenciales
- subir archivos
- conceder permisos al navegador
- transmitir datos sensibles
Cada aprobación está vinculada a una acción, destino, destino final, documento y conjunto de categorías de datos específicos, por lo que resulta inútil después de que cambie la página o al usarse con otro botón. El envío de datos sensibles se evalúa por sí mismo, independientemente de la acción final. Ingresar una dirección de correo electrónico en un formulario de un tercero podría requerir una aprobación vinculada a ese destino antes de que el botón “Enviar” solicite una confirmación separada. El usuario sigue siendo quien aprueba; Cloud Browser se encarga de hacer cumplir las reglas, y la aplicación de agente enmarca la decisión.
Capturas de pantalla, artefactos y reproducción
Las capturas de pantalla sirven para una comprensión rápida, como evidencia duradera y para el diagnóstico de fallos. Una llamada que incluye una captura de pantalla devuelve una imagen para mostrarla de inmediato además de un ID de artefacto opaco, y nunca se transmite ninguna ruta del sistema de archivos del servidor al agente. Los artefactos pertenecen a la tarea que los genera, caducan rápidamente, tienen límites de tamaño y cantidad, se envían a través de rutas firmadas, solo pueden descargarse en las ubicaciones locales configuradas y se escriben con permisos exclusivos para el propietario sin sobrescribir un archivo existente.
Una navegación exitosa también permite crear una línea de tiempo limitada de capturas de pantalla. Cada entrada cuenta con una marca de tiempo, nombre del host, origen, resumen de la acción y un artefacto de captura de pantalla opcional. Un deslizador permite al usuario inspeccionar un estado anterior del navegador, y seleccionando LIVE se vuelve a la sesión WebRTC actual.
Las acciones sensibles reciben un trato especial. La introducción de credenciales nunca se registra, y cuando una acción transmite información sensible, el cronograma puede conservar solo los metadatos mínimos mientras se omite deliberadamente la captura de pantalla.
La reproducción va más allá de una simple comodidad visual, ya que responde a preguntas prácticas:
- ¿Qué había en la pantalla para el agente justo antes del clic?
- ¿Apareció algún pop-up en el proceso?
- ¿Podría haber otro elemento encima del objetivo?
- ¿Algo en la página cambió visiblemente después?
- ¿La tarea se detuvo en el sitio o a la espera de la aprobación del usuario?
Popups, redirecciones y páginas problemáticas
Los flujos de trabajo reales rara vez permanecen en una sola pestaña. Un flujo de reserva puede abrir un popup, un proveedor de identidad puede pasar por varios orígenes, un documento de oficina puede intentar iniciar una aplicación de escritorio y una página de reuniones puede ofrecer tanto un enlace a la app como una opción alternativa en la web. Cloud Browser trata tales transiciones como eventos de primera categoría.
Si una acción abre una ventana, la plataforma registra la nueva pestaña, la selecciona para la tarea y la integra en la vista en tiempo real; cuando el usuario toma el control, este se traslada a ella. Si una página intenta iniciar un protocolo nativo, como por ejemplo una app de reuniones, el navegador indica que la aplicación externa no está disponible en lugar de simular un clic exitoso. Si el sitio cuenta con una opción alternativa segura en el navegador, el agente o el usuario pueden elegirla intencionadamente.
Nada en la plataforma permite eludir los CAPTCHAs, los mensajes de seguridad del navegador, las barreras de pago, los requisitos de confianza del dispositivo o medidas de protección similares. Cuando aparece alguno de ellos, se informa como una limitación o se transfiere el problema al usuario.
Seguridad de red y SSRF
Dado que un navegador remoto también funciona como cliente de red, una navegación no controlada podría convertirlo en una herramienta de SSRF. Las direcciones de destino se resuelven y validan antes de que el proceso se conecte. Por defecto, se deniegan las siguientes:
- destinos de tipo loopback
- destinos de tipo link-local
- el servicio de metadatos en la nube
- rangos privados al estilo RFC1918
- espacios reservados para multidifusión u otros fines
- cualquier esquema de URL fuera del conjunto soportado
Las listas de permisos y bloqueos específicos para cada usuario pueden reforzar aún más esta seguridad.
Ciertas configuraciones empresariales utilizan DNS dividido o pasarelas web seguras que dirigen nombres de hosts internos aprobados a direcciones NAT privadas o de nivel operador. Dichas excepciones deben ser explícitas, específicas, limitarse a dominios de confianza y establecerse mediante la configuración de despliegue, para que un nombre de host correspondiente no se convierta en un acceso general a la red privada. Las redirecciones, ventanas emergentes, iframes, solicitudes de service-worker y el reenlazamiento DNS permanecen bajo la misma política de red, ya que verificar solo la primera URL resulta insuficiente.
Inyección de comandos y contenido de página no confiable
El proceso del navegador trata el contenido de la página como datos y nunca como instrucciones. Una página puede mostrar “ignora tus instrucciones anteriores” o publicar una descripción de una herramienta afirmando que alguna operación es segura, pero ninguna de estas afirmaciones otorga autoridad alguna.
Las herramientas que una página anuncia a través de WebMCP están vinculadas a la URL de la página, a la generación del documento, a un identificador de registro y al esquema observado, y sus descripciones nunca se consideran fiables. Un readOnlyHint proporcionado por la página no puede omitir la aprobación a menos que el despliegue haya confiado explícitamente en ese origen específico con dicho propósito. Los snapshots semánticos siguen la misma regla: el razonamiento sobre el contenido corresponde al agente, pero otorgar autoridad al navegador depende únicamente de la pasarela.
Descargas, subidas y el portapapeles
Los archivos descargados se almacenan como artefactos propiedad de la tarea, por lo que no se revela ninguna ruta del trabajador. Para subir un archivo se necesita un selector de archivos vinculado a un evento y una ruta de origen dentro de la raíz de subida configurada. Los enlaces simbólicos se resuelven y se rechazan si apuntan fuera del directorio aprobado; además, antes de establecer los archivos, el trabajador verifica si el selector selecciona un archivo o varios.
Cada tarea tiene su propio estado de portapapeles. El texto y los elementos binarios MIME delimitados pueden sincronizarse a través del visor en tiempo real, con permisos del navegador otorgados de forma restringida y revocados posteriormente. En un contexto de navegador persistente, el permiso del portapapeles concedido a una tarea no debe permanecer activo para otra.
Ciclo de vida y limpieza
La limpieza debe ejecutarse incluso si el agente nunca finaliza de manera ordenada. El servicio recibe una señal explícita de fin de turno que distingue entre turnos completados, interrumpidos, detenidos o detenidos por subagentes, y la limpieza que inicia es limitada e idempotente. Cada pestaña puede tener una de tres marcas:
- una pestaña en uso, que se cierra al finalizar el turno
- un resultado entregable, que se conserva para el usuario
- una tarea en tránsito, que se deja abierta para que el usuario continúe
Las marcas relacionadas con un turno se eliminan una vez que se han procesado, por lo que una pestaña debe conservarse deliberadamente en un turno posterior. Otros niveles de limpieza provienen de los contratos de sesión, los tiempos de inactividad, la expiración de archivos, la eliminación de perfiles huérfanos y el cierre ordenado de los gateways.
Observabilidad sin filtrar datos privados
Los registros del gateway registran los eventos operativos relacionados con la creación de sesiones, la navegación, las decisiones de política, los traspasos de control, las mutaciones, los fallos y las tareas de limpieza. Un registro de auditoría debe contener identificadores y resultados, en lugar de credenciales o contenido de páginas. Las URLs se reducen a sus partes seguras cuando es posible, y las consultas, los valores de formularios, las contraseñas, los tokens y los datos personales se enmascaran o eliminan.
Las señales operativas útiles incluyen:
- la latencia en el gateway y en los workers
- cuántas sesiones y navegadores existen
- los pares WebRTC conectados
- qué categorías de denegaciones de política ocurren
- con qué frecuencia los destinos se vuelven obsoletos
- resultados que no han sido confirmados
- workers que no logran iniciarse
- sí las conexiones de visualización en vivo tienen éxito
- artefactos creados y vencidos
- tareas de limpieza que fallan
El espectador informa cuando el video realmente llega al estado de reproducción, ya que simplemente generar una URL firmada no demuestra que el usuario pueda ver algo.
Fiabilidad y pruebas de estrés
Los fallos más problemáticos en la automatización de navegadores son aquellos silenciosos: un clic que no logra nada, datos ingresados dos veces, una ventana emergente que nadie ve, o una acción reproducida después de un tiempo de espera. Por lo tanto, un conjunto de pruebas serio va mucho más allá de la navegación por el camino óptimo. Cloud Browser evalúa estas áreas:
- varios usuarios y sesiones al mismo tiempo
- separación entre tareas y entre elementos generados
- mutaciones que deben ser idempotentes
- referencias a documentos obsoletos
- seguimiento de ventanas emergentes
- objetivos dentro de iframes y raíces sombra
- vuelvas a conectarse de WebRTC
- concurrentes mientras cambia el control
- páginas que están ocupadas o temporalmente congeladas
Las pruebas de estrés deben combinar trabajadores reales de Chromium con muchos visualizadores WebRTC al mismo tiempo. Las pruebas unitarias cubren bien la lógica de políticas y protocolos, pero los problemas relacionados con el inicio del navegador, la transmisión de video, el enfoque, la selección de ventanas emergentes y la entrega de entrada solo se manifiestan bajo una carga realista.
Modelo de despliegue
La arquitectura de referencia puede funcionar como un único nodo, aunque sus interfaces están diseñadas para un plano de control de producción más amplio. Un despliegue básico conecta estas partes:
TLS ingress
-> Cloud Browser gateway
-> isolated browser workers
-> encrypted profile and artifact volume
El navegador debe ejecutarse como un usuario sin privilegios bajo un perfil seccomp adecuado, con límites en CPU y memoria, además de suficiente memoria compartida para Chromium. Los contenedores constituyen un punto de partida práctico, y los entornos de mayor riesgo podrían optar por una microVM por cada proceso del navegador para lograr una aislación más estricta.
Las implementaciones empresariales suelen incluir:
- Autenticación OIDC para la consola independiente
- Autenticación máquina a máquina para los agentes
- Identidad del usuario final transmitida por servidores backend de confianza
- Redis, para almacenar contratos distribuidos y claves de idempotencia
- PostgreSQL o una plataforma de auditoría dedicada para registrar eventos permanentes
- Almacenamiento de objetos encriptado para los archivos generados
- Un programador que asigna las tareas a los procesos
- Servidores TURN que emiten credenciales WebRTC de corta duración
- Un gestor de secretos con rotación de claves
- Ruteo regional además de controles de residencia de datos
La pasarela solo debe ser accesible desde el exterior a través de HTTPS. HTTP puro no sirve para nada más que para desarrollo con bucle local explícito.
Configuración, variable por variable
Un archivo env establece la identidad de red de la pasarela, el comportamiento del navegador, el almacenamiento, el aislamiento y los límites de las políticas. Considérelo como una configuración de despliegue y no como el código fuente de la aplicación. El ejemplo a continuación es seguro de mostrar, ya que sus valores son ilustrativos y no contienen tokens reales ni secretos de firma:
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
Esta es la interfaz de red en la que escucha la pasarela.
CB_HOST=127.0.0.1
Con 127.0.0.1, el servicio responde únicamente a la máquina local, siendo la opción más segura al desarrollar con la interfaz de usuario del agente, el adaptador MCP y la pasarela en una misma computadora. Un contenedor puede necesitar 0.0.0.0 para que su red o un proxy de entrada pueda conectarse, pero eso no es motivo para publicar el puerto en Internet; las pasarelas de producción permanecen detrás de conexiones TLS autenticadas, reglas de firewall y autorización a nivel de servicio. Tenga también en cuenta que CB_HOST determina dónde escucha el proceso, no las URLs de los enlaces de vista en vivo, que son gestionadas por CB_PUBLIC_URL.
CB_PORT
Este es el puerto TCP que utiliza la pasarela.
CB_PORT=8787
Cualquier número desde 1 hasta 65535 funciona, y el valor predeterminado en el desarrollo es 8787. Este número no debe estar en uso en la interfaz elegida. Si un proxy inverso o contenedor expone algún otro puerto externo, CB_PORT seguirá siendo el puerto interno de escucha, mientras que CB_PUBLIC_URL indica la dirección que ven los usuarios externos.
CB_PUBLIC_URL
La URL base pública es la que utiliza el gateway al crear enlaces firmados para la vista en vivo.
CB_PUBLIC_URL=http://127.0.0.1:8787
Es más que una etiqueta, ya que la interfaz de usuario recibe las capacidades del espectador derivadas de ella, por lo que debe ser accesible desde el navegador que muestra la vista en vivo. El desarrollo local admite HTTP de bucle local:
CB_PUBLIC_URL=http://127.0.0.1:8787
Una implementación remota necesita un origen HTTPS al que se pueda acceder desde el exterior:
CB_PUBLIC_URL=https://browser.example.com
Excluya de esta URL rutas, consultas, nombres de usuario incrustados, contraseñas y secretos en bruto, y termine el protocolo TLS en un punto de entrada confiable o directamente en la propia pasarela. Otro problema: 127.0.0.1 siempre se refiere a la máquina en la que se encuentra. Supongamos que la interfaz de usuario del agente funciona en una laptop y que la pasarela está ubicada en un servidor en algún lugar. Un enlace para visualizar contenido creado con 127.0.0.1 llevará de vuelta a la laptop y nunca llegará a la pasarela.
CB_TOKENS
Esta variable enumera las credenciales de servicio que acepta la pasarela. Cada entrada sigue un formato específico:
<bearer-token>:<tenant-id>:<service-principal>[:scope]
Una credencial de backend delegada se ve así:
CB_TOKENS=replace-with-a-long-random-token:tenant-example:agent-service:delegate
Los comas separan las entradas múltiples. El primer campo es el token de portador, que se encuentra en el encabezado HTTP Authorization; debe tener al menos 20 caracteres, generarse con una fuente aleatoria criptográficamente segura y almacenarse en un gestor de secretos. El ID del inquilino constituye el límite de aislamiento más externo, por lo que las sesiones, tareas, perfiles, pestañas y artefactos nunca lo cruzan. El principal es el nombre del servicio que alberga las credenciales, y sin delegación, las sesiones se ejecutan como ese principal.
El ámbito opcional delegate permite que un backend de confianza envíe un encabezado X-Cloud-Browser-Principal que indica el nombre del verdadero usuario final. La sesión pertenece entonces a ese usuario, mientras que el registro de auditoría anota por separado qué backend actuó en su nombre. Solo las aplicaciones del lado del servidor de confianza deberían tener permiso de delegación. Un cliente de escritorio o un token de usuario común no deberían tenerlo, ya que de lo contrario podrían hacerse pasar por otro usuario dentro del tenant.
Tanto los tokens configurados como los presentados se hashean antes de una comparación en tiempo constante, lo que reduce las fugas de información relacionadas con la longitud del token, pero no hace que un token filtrado sea seguro. Cambie el token de inmediato si aparece en una captura de pantalla, repositorio, grabación de terminal o ticket de soporte. Además, no lo reutilice como CB_LIVEVIEW_SECRET, ya que ambos protegen capacidades diferentes y requieren una generación independiente.
CB_MAX_SESSIONS_PER_PRINCIPAL
Esto establece el límite de sesiones simultáneas que puede tener un usuario activo.
CB_MAX_SESSIONS_PER_PRINCIPAL=8
Los valores permitidos van desde 1 hasta 128, con un valor predeterminado de 8. Este límite sirve para proteger contra ataques accidentales desde el navegador y agentes que operen sin control, además de evitar que un único usuario agote la capacidad global; se suma al límite de sesiones establecido a nivel del gateway. El valor óptimo depende de la memoria y CPU del proceso, del modo de perfil y de la concurrencia esperada. Incluso si un perfil persistente comparte el mismo proceso del navegador entre las tareas de un usuario, cada tarea sigue consumiendo recursos relacionados con pestañas, transmisiones en streaming, archivos y el gateway.
CB_LIVEVIEW_SECRET
Se trata de la clave HMAC que firma las funcionalidades de visualización en vivo.
CB_LIVEVIEW_SECRET=replace-with-a-separate-random-signing-secret
Cada campo del token firmado (tenant, principal, task, session, tab, expiry) está cubierto por la firma, por lo que cambiar alguno la invalida. Una implementación a la que se pueda acceder desde el exterior necesita su propio secreto de 32 caracteres o más; en la práctica, eso significa al menos 32 bytes aleatorios en formato hexadecimal o Base64, cargados desde un gestor de secretos. Una filtración de secretos permitiría a un atacante con suficientes metadatos de sesión falsificar capacidades de visualización. La rotación invalida las firmas recién verificadas realizadas con la clave antigua, por lo que debe sincronizarse con la fecha de vencimiento de las sesiones de visualización en tiempo real. Mantenga este valor alejado de agentes, páginas del navegador, paquetes del cliente, registros y repositorios.
CB_LIVEVIEW_FRAME_ANCESTORS
Esto determina qué aplicaciones web de confianza pueden incrustar el visualizador firmado en un iframe.
CB_LIVEVIEW_FRAME_ANCESTORS=http://localhost:8088,http://127.0.0.1:8088
La pasarela convierte la lista en la directiva frame-ancestors de la Política de Seguridad de Contenido del visor. Si el valor está vacío, el visor envía frame-ancestors 'none' y X-Frame-Options: DENY, por lo que funciona como una página independiente pero rechaza su incrustación. Si se enumeran orígenes, solo aquellos exactos pueden enmarcarla, y se omite X-Frame-Options: DENY porque ese encabezado más antiguo no puede expresar varios orígenes y anularía la lista de permisos.
Las entradas deben ser orígenes HTTP o HTTPS exactos; las rutas, credenciales de URL, consultas, fragmentos y comodines son rechazados. El esquema, el host y el puerto son importantes, por lo que los siguientes tres constituyen orígenes distintos:
http://localhost:8088
http://127.0.0.1:8088
https://agent.example.com
Esta configuración no está relacionada con CORS. Protege la potente página del visor contra el clickjacking, por lo que solo se deben listar las interfaces que realmente necesitan mostrar el navegador en tiempo real.
CB_HEADLESS
Esto controla si el proceso auxiliar inicia el navegador sin una ventana de escritorio nativa.
CB_HEADLESS=true
Con true, Chromium o Chrome se ejecutan sin interfaz gráfica, y los usuarios observan y controlan a través de la vista en vivo de WebRTC en lugar de una ventana local de Chrome. Los servidores y contenedores suelen preferir esto, ya que utiliza menos recursos del escritorio y mantiene la automatización independiente de una sesión de pantalla nativa. Con false el navegador se inicia con interfaz gráfica y necesita una pantalla funcional, generalmente una virtual como Xvfb o una imagen de trabajo para transmisión de escritorio en Linux; en macOS abre una ventana de navegador separada, a menos que la arquitectura del trabajo sea diferente. Cambiar este parámetro nunca hace que Cloud Browser tome el control de una ventana personal de Chrome ya abierta. Solo afecta la forma en que se inicia el propio navegador gestionado por el trabajo.
CB_SERVICE_WORKERS
Esto determina si los sitios web pueden registrar y ejecutar workers de servicio.
CB_SERVICE_WORKERS=allow
Elija allow o block; block es el valor predeterminado seguro. Las aplicaciones web progresivas, las aplicaciones de reuniones, las aplicaciones de oficina y los sitios con caché intensivo suelen depender de service workers y pueden dejar de funcionar, quedar atascadas en una pantalla de carga o parecer congeladas sin ellos. Habilitarlos ayuda a la compatibilidad, pero aumenta el volumen de trabajo de red y de persistencia del navegador, por lo que verifique con antelación que las solicitudes de service worker sigan respetando la protección de navegación, las reglas de salida, la prevención de pérdida de datos y la política del usuario. Elija allow solo para aplicaciones validadas que lo necesiten, nunca como solución general.
CB_BROWSER_CHANNEL
Esto selecciona un canal de navegador instalado en el sistema en lugar del Chromium incluido en Playwright.
CB_BROWSER_CHANNEL=chrome
Se aceptan cuatro canales: chrome, chrome-beta, chrome-dev y msedge. Deje este campo en blanco para utilizar el ejecutable de Chromium configurado o el paquete de Playwright. A veces son necesarias versiones reales de Chrome o Edge cuando una empresa verifica la confianza del dispositivo, gestiona los navegadores de forma centralizada, aplica políticas o emite certificados para clientes. Elegir chrome no carga el perfil normal de Chrome del usuario, ya que los perfiles provienen aún de CB_PROFILE_MODE y CB_PROFILE_DIR; por lo tanto, Cloud Browser no puede conectarse silenciosamente a una sesión interactiva personal. El canal debe estar instalado en el host del trabajador, y la confianza del dispositivo también puede requerir el perfil adecuado, registro en el sistema operativo, certificados, políticas o extensiones; la configuración en sí no crea confianza empresarial.
CB_EXTENSION_PATHS
Una lista separada por comas de los directorios de extensiones del navegador desempaquetadas.
CB_EXTENSION_PATHS=
Deje este campo en blanco para no cargar extensiones desempaquetadas. Las rutas indicadas se transmiten al navegador gestionado a través de indicadores de carga de extensiones, lo cual solo funciona con CB_HEADLESS=false y un CB_PROFILE_MODE de task o persistent; los contextos efímeros y las ejecuciones sin interfaz no pueden albergar esto de forma segura. La carga de extensiones desempaquetadas está destinada al desarrollo y a pruebas controladas. Las empresas en entorno de producción deben instalar por fuerza las extensiones aprobadas a través de las políticas de Chrome o Edge, fijar los identificadores y actualizar las fuentes, además de auditar los permisos. Dado que una extensión funciona con privilegios del navegador y puede observar o modificar la actividad en la web, su origen, ruta de actualización, permisos y propietario deben formar parte de la revisión de seguridad.
CB_PROFILE_MODE
Esto determina cómo se aísla el estado del navegador y cuánto tiempo dura el estado de inicio de sesión.
CB_PROFILE_MODE=persistent
La configuración puede ser ephemeral, task o persistent. En el modo ephemeral se crea un contexto del navegador temporal sin un directorio de perfil reutilizable, lo que ofrece la mayor isolación por defecto y es adecuado para navegación anónima o tareas que no deben dejar rastro de inicio de sesión. El modo task genera un directorio de perfil para una sola tarea: las cookies y el estado persisten mientras dure la tarea, y al finalizar se elimina el perfil. En el modo persistent se comparte un único perfil entre tareas del mismo propietario y principal efectivo, de modo que las cookies y sesiones de los sitios web sobreviven a nuevas tareas y reinicios del gateway, aunque cada tarea mantiene su propia pestaña seleccionada, portapapeles, transmisiones en vivo, archivos y permisos de control. El modo persistente es el más práctico pero también el más arriesgado; se debe utilizar almacenamiento encriptado, permisos estrictos para los directorios, flujos explícitos de cierre de sesión y eliminación de perfiles, además de un tiempo inactivo limitado.
CB_PROFILE_DIR
El directorio raíz en el que se almacenan los datos del navegador basados en perfiles.
CB_PROFILE_DIR=./var/profiles
Una ruta relativa se resuelve con respecto al directorio de trabajo del proceso de gateway. En los contenedores, monte un volumen protegido aquí si es necesario que los perfiles sobrevivan al reemplazo del contenedor. El gateway crea por sí mismo subdirectorios específicos para cada usuario y principal, y nunca utiliza rutas de perfiles elegidas por los agentes. Los directorios deben ser de acceso exclusivo del propietario y nunca ofrecerse para descarga. No dirija la configuración al perfil de Chrome de una persona real; copiar o abrir simultáneamente un perfil en uso puede dañarlo y exponer datos de navegación no relacionados al trabajador.
CB_ARTIFACT_DIR
Donde se almacenan las capturas de pantalla pertenecientes a tareas, descargas, contenido exportado, imágenes de reproducción y otros artefactos delimitados.
CB_ARTIFACT_DIR=./var/artifacts
Las rutas relativas se resuelven a partir del directorio de trabajo de la pasarela una vez más. Los agentes reciben IDs de artefactos opacos en lugar de rutas, y cada solicitud verifica al inquilino, al principal, la tarea, la fecha de vencimiento y la propiedad. Haga que el directorio sea escribible únicamente para la cuenta de servicio del Cloud Browser, limite la vida útil, el recuento y el tamaño de los artefactos, elimine los archivos vencidos, encripte el almacenamiento subyacente y evite conservar artefactos temporales en las copias de seguridad indefinidamente. Los perfiles y los artefactos tienen propósitos diferentes: una captura de pantalla puede llegar a un usuario, mientras que un perfil del navegador nunca debe tratarse como un artefacto descargable.
CB_AUDIT_FILE
Ruta del registro de auditoría en formato JSON Lines.
CB_AUDIT_FILE=./var/audit.log
Cada línea representa un evento estructurado relacionado con acciones como la creación de sesiones, la ejecución de comandos, el rechazo de políticas, la transferencia de control, el resultado de una conexión en tiempo real, la destrucción de sesiones o un fallo en las tareas de limpieza. Registre quién y qué ocurrió, no los valores de formularios ni el contenido de las páginas, y elimine u omita credenciales, tokens, consultas y datos sensibles del usuario. En entornos de producción, trate los archivos JSONL locales como un formato de desarrollo o de transporte y envíe los eventos a una plataforma de auditoría duradera que ofrezca políticas de retención, control de acceso, protección de integridad, alertas e investigaciones adaptadas a cada usuario.
CB_USER_AGENT
Una opción opcional para sobrescribir la cadena User-Agent del navegador.
CB_USER_AGENT=
Es mejor dejarlo vacío. El motor del navegador crea una identidad de Chrome normal a partir de su versión y proporciona indicaciones del cliente correspondientes, evitando discrepancias entre el encabezado de la solicitud, navigator.userAgent y navigator.userAgentData. Una cadena personalizada solo sobrescribe el User-Agent, sin crear indicaciones correspondientes, y algunos proveedores de identidad y detectores de bots detectan esta discrepancia. No lo utilice para presentar un navegador antiguo como uno más reciente ni para eludir la política de seguridad de un sitio; guárdelo para un requisito de compatibilidad documentado y verifique posteriormente la identidad completa del navegador.
CB_ALLOW_ORIGINS
Lista de permisos de navegación del inquilino.
CB_ALLOW_ORIGINS=
Si la lista está vacía, se permiten los destinos HTTP y HTTPS públicos a menos que interviniera alguna otra política, mientras que los destinos de red privada, metadatos, link-local, reservados y no soportados siguen siendo bloqueados por la protección de red. Una vez que cuenta con entradas, cada navegación debe coincidir al menos con una regla, escrita como un origen exacto como https://portal.example.com, un sufijo comodín como *.example.com o un nombre de host sin prefijo como portal.example.com. Cuando el esquema o el puerto son importantes, se debe utilizar un origen exacto. Un comodín abarca el nombre de host principal junto con sus subdominios, por lo que hay que ser cauteloso al usarlos. El hecho de aparecer en la lista de permisos no autoriza una IP privada, ya que la clasificación DNS y la política de origen privado confiable se evalúan por separado.
CB_BLOCK_ORIGINS
La lista negra explícita de navegaciones.
CB_BLOCK_ORIGINS=
Las reglas utilizan las mismas tres formas que la lista de permisos, y esta lista se consulta primero; por lo tanto, todo lo que coincida con ambas listas será bloqueado. Los usos típicos son endpoints administrativos sensibles, aplicaciones no compatibles, destinos conocidos como peligrosos o un subdominio que debe excluirse de una lista de permisos más amplia. La clasificación de la red se aplica incluso si la lista está vacía.
CB_TRUSTED_PRIVATE_ORIGINS
Indica los nombres de hosts corporativos que pueden resolverse a direcciones privadas o CGNAT.
CB_TRUSTED_PRIVATE_ORIGINS=*.company.example
La razón de su existencia son las configuraciones de DNS dividido, en las que un nombre de host de una empresa aprobada se resuelve de manera diferente en la VPN o en la red interna. Las reglas comparten la sintaxis de la lista de navegación. Restrinja su uso a los dominios que posee la organización y evite agregar un comodín genérico o un nombre de host simplemente porque una aplicación se comporta incorrectamente. Una coincidencia de confianza puede permitir destinos RFC1918 o CGNAT, pero nunca direcciones de bucle local, de enlace local, de metadatos en la nube, multicast o reservadas. Revíselo como lo que es: una excepción SSRF; la plataforma necesita control sobre el DNS, la salida de datos y la propiedad de cada sufijo de confianza.
CB_ALLOW_CGNAT_NAVIGATION
Permite la navegación hacia el rango de NAT de nivel operador, 100.64.0.0/10.
CB_ALLOW_CGNAT_NAVIGATION=true
Por defecto es false. En algunas redes empresariales, una VPN o un gateway web seguro ofrece servicios públicos o internos en direcciones dentro del espacio CGNAT. Activar este interruptor los permite y puede desactivar las restricciones de acceso a la red local del navegador que impedirían que una página llegue a la dirección sintética. Esto es más amplio que confiar únicamente en un nombre de host, por lo que utilice CB_TRUSTED_PRIVATE_ORIGINS si solo se necesitan dominios de la empresa conocidos. Los rangos RFC1918, loopback, link-local, metadata, multicast y reservados permanecen cerrados, pero el alcance de la red sigue aumentando considerablemente, así que úselo solo en un entorno corporativo controlado.
CB_REQUIRE_APPROVAL
Activa la puerta de aprobación general del gateway para comandos clasificados como de gran importancia.
CB_REQUIRE_APPROVAL=false
Con true, las órdenes con consecuencias se retienen hasta que se reciba una aprobación exacta en el momento de ejecutarla. Con false, se elimina esa restricción, lo cual es una opción adecuada si una aplicación de agente de confianza ya aplica medidas más estrictas. Sin embargo, la seguridad no se desactiva. Los riesgos reconocidos como la transmisión de datos sensibles, la eliminación de información, los pagos, las reservas, los mensajes en nombre de otra persona, los cambios en cuentas o permisos, el acceso al historial y las herramientas de páginas no clasificadas siguen requiriendo aprobación. El control es otro aspecto: las acciones del agente permanecen bloqueadas mientras el usuario tiene el control del navegador. Para un producto independiente compartido por varios agentes, suele ser más sensato mantener activa la aplicación de restricciones en la puerta de entrada, ya que así la seguridad no depende de que cada cliente aplique correctamente las políticas.
CB_ALLOW_LOOPBACK_NAVIGATION
Un conmutador de desarrollo que permite al navegador del trabajador visitar direcciones de bucle local (localhost, 127.0.0.1 o ::1).
CB_ALLOW_LOOPBACK_NAVIGATION=true
El valor predeterminado es false. Las pruebas automatizadas y las aplicaciones web locales en la misma máquina que el worker se benefician de esta opción. No permite que un navegador remoto acceda al portátil del usuario, ya que en un worker remoto 127.0.0.1 representa el entorno remoto. Evite activarla de forma casual en entornos de producción: el acceso por bucle local puede revelar puertos administrativos internos, servidores de desarrollo, interfaces de depuración y servicios diseñados bajo la premisa de que el contenido web no confiable no podría acceder a ellos. Incluso cuando está activada, el nombre del host debe resolverse únicamente a direcciones de bucle local, por lo que una respuesta DNS mixta no puede convertir esta excepción en un bypass general.
CB_SYNTHETIC_MEDIA_DEVICES
Proporciona al navegador gestionado un micrófono y una cámara sintéticos.
CB_SYNTHETIC_MEDIA_DEVICES=true
También es false por defecto. Los navegadores sin interfaz gráfica a menudo no muestran dispositivos multimedia, y algunos sitios de reuniones y grabación verifican la presencia de un micrófono o cámara antes de continuar, por lo que la página parece atascada cuando no se encuentra ninguno. Los dispositivos sintéticos hacen que esas verificaciones den resultado positivo: el micrófono permanece en silencio y la cámara muestra un patrón de prueba en lugar de video real. Nada aquí captura el micrófono o la cámara física de nadie, y nunca debería describirse de esa manera. Si el trabajador se une a una reunión real, mantenga su cámara apagada a menos que sea necesario transmitir el patrón de prueba. El sitio aún puede solicitar permiso, y otorgarlo es una decisión política distinta a ofrecer un dispositivo.
Interpretando el ejemplo como una única implementación
En conjunto, la configuración de ejemplo describe un entorno de desarrollo local:
- La pasarela solo acepta conexiones locales, en el puerto
8787.
8088 bajo cualquiera de los nombres de host.Esto funciona como un perfil de integración local, pero no constituye una línea base para producción. Antes del lanzamiento: cambie la URL pública a HTTPS, rotue cada credencial secreta y guárdela fuera del archivo, desactive el loopback, limite las excepciones de CGNAT y orígenes privados, revise el acceso del service-worker, active la política de aprobación del gateway, almacene los perfiles y artefactos en almacenamiento gestionado cifrado, y reenvíe los eventos de auditoría a una plataforma duradera.
Conectar un agente
Un agente con capacidad MCP puede iniciar el adaptador como un proceso local y dirigirlo hacia el gateway. Las credenciales reales permanecen fuera del control de código, por lo que utilice marcadores de posición como estos:
{
"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"
}
}
}
}
Una interacción típica se desarrolla de la siguiente manera:
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
Cómo esto difiere de una herramienta de navegador dentro de un agente
Muchos productos de agentes incluyen su propia herramienta de navegador. Cloud Browser está diseñado para ser la plataforma de navegador subyacente en numerosos agentes, y su valor proviene de una combinación de características:
- permanece neutral respecto al modelo utilizado
- las sesiones persisten de forma remota
- la interacción es tanto semántica como visual
- WebRTC permite la observación y el control
- las credenciales se gestionan de forma segura
- la pasarela aplica las aprobaciones necesarias
- las capturas de pantalla proporcionan pruebas y posibilidad de reproducir
- los artefactos están relacionados con tareas específicas
- la limpieza sigue un ciclo de vida determinista
- las identidades empresariales, políticas y límites de auditoría están integrados
En resumen, se trata de esto:
Demostrar un flujo de trabajo una sola vez y luego ejecutarlo a través de cualquier agente de IA, permitiendo que un humano pueda detener los pasos subsiguientes.
Lecciones de su desarrollo
El navegador no es la parte más complicada; lo es la autoridad. Se obtuvieron seis lecciones del diseño.
La vista en tiempo real es una superficie de seguridad y no solo un reproductor de video: contiene controles, aprobaciones, credenciales e intenciones del usuario, por lo que su URL, política de enmarcado, fecha de vencimiento y estado de control requieren la misma atención que una funcionalidad API.
Hacer llegar un mensaje no es lo mismo que completar la interacción. Puede haber un clic mientras la página simplemente lo ignora, por eso la entrada necesita una confirmación, una revisión posterior de la página y etiquetas separadas para “entregado”, “cambiado” y “todavía en espera”.
Los intentos ciegos son arriesgados. Dondequiera que una acción del navegador pueda tener consecuencias en el mundo real, se requieren propiedades de idempotencia y reconciliación.
Las sesiones persistentes hacen que el producto sea más útil, pero también más arriesgado al mismo tiempo. Aíslalas por identidad y únalas a controles de cierre de sesión, retención, historial y limpieza.
Trate el contenido de las páginas y las herramientas proporcionadas por ellas como no confiables. Un sitio puede describir una acción, pero no tiene poder para aprobarla.
Por último, contar con evidencia limitada facilita que se confíe en la automatización. Gracias a una línea de tiempo de capturas de pantalla y resúmenes de acciones, usuarios, desarrolladores y operadores pueden comprender una falla.
Donde deja esto a las cosas
Los agentes necesitan navegadores, pero las empresas quieren algo más que scripts. Desean una plataforma con un propietario claro, autoridad con fecha de vencimiento, transferencia segura entre personas, inicio de sesión protegido, aprobación antes de que cualquier acción tenga efecto, resultados observables y una limpieza fiable.
Cloud Browser convierte a Playwright y Chromium en esa plataforma, separando la planificación de la ejecución, los agentes de las credenciales, y las capacidades del navegador de la autoridad del usuario. Esa separación es la razón por la cual el diseño es reutilizable: se puede cambiar el agente, el modelo o la interfaz sin que cambie el límite de seguridad alrededor del navegador. Es la base necesaria para que las personas puedan confiar realmente en la automatización de navegadores.