OpenBot: arquitectura, controles y límites de sus agentes de navegador
Evaluación documental de OpenBot: aislamiento, políticas, registros de auditoría, intervención humana y límites que debes probar antes de conectar cuentas reales.
Guía basada en documentación pública. Los ejemplos propuestos no son resultados de clientes. No se realizaron pruebas de uso para este artículo.
OpenBot: arquitectura, controles y límites de sus agentes de navegador
Respuesta rápida
OpenBot es un proyecto de colaboradores de IA de código abierto. Cada Bot dispone de navegador, archivos y herramientas; sus acciones pasan por una pasarela que evalúa políticas y escribe un registro de auditoría. El diseño contempla la seguridad, pero sigue en desarrollo. La conclusión razonable es examinar sus controles, no asumir seguridad para producción. Empieza con un entorno desechable, permisos limitados y una persona capaz de intervenir o detener el trabajo.
CopilotKit describe perfiles de navegador, espacios de trabajo y herramientas concedidas. Un servidor Hono gestiona autenticación, políticas, auditoría, plugins y canales, mientras el ordenador del agente es otro componente. Estas fronteras son señales de diseño, no pruebas de seguridad.
Esta evaluación se basa en documentos. No clonamos el repositorio, ejecutamos Docker o Podman, inspeccionamos la base de datos, probamos evasiones de políticas ni medimos fiabilidad.
Cómo funciona la arquitectura
Comprobación del 7 de octubre: v0.1.1
Las notas de v0.1.1 lo señalan como la versión más reciente, sustituyendo a v0.0.15 como referencia actual. Describen correcciones en la ocultación de secretos de comandos registrados, restricciones de nombres de host de loopback, tratamiento de hosts públicos en modo de usuario único y comportamiento de Stop/cancelación. También mencionan restricciones de direcciones de metadatos de nube y TLS de bases de datos gestionadas. Son afirmaciones de los mantenedores, no pruebas realizadas por nosotros.
Tras actualizar, repite las comprobaciones de redacción de logs, destinos privados prohibidos, autenticación y detención de tareas en curso. Revisa los registros antes de enviarlos a soporte: podrían contener credenciales. Una versión nueva no garantiza una instalación segura.
Contexto anterior: v0.0.15
Las notas anteriores describen acceso opcional a modelos mediante OAuth de Google o xAI, mejoras de instalación de escritorio y correcciones de arranque en Windows. Las conexiones por clave API seguían disponibles. No es una afirmación de que v0.0.15 siga siendo la última versión ni de que hayamos probado esas funciones.
OAuth requiere un archivo de credenciales configurado; sin él, la opción no aparece. Google también requiere el cliente de escritorio registrado y un proyecto de cuota. Descargar la app no proporciona todos esos requisitos. Las notas incluyen selección automática de puerto local, Bun fijado y una corrección de la ruta Compose en Windows.
El reinicio de escritorio descrito elimina el volumen de base de datos de la instalación anterior. Conserva los registros necesarios y obtén autorización del propietario antes de usarlo. Fija la versión probada y repite pruebas de rechazo, intervención y auditoría tras actualizar. Las mejoras de instalación no demuestran aislamiento ni preparación para producción.
El README presenta interfaz, servidor pasarela, ordenador del agente con Chromium, perfil y archivos, y servicios Bot o supervisor. La pasarela resuelve el destino, comprueba la política, registra la decisión y llama al ordenador. Los endpoints inferiores deben permanecer privados para evitar atajos alrededor de ese control.
| Capa | Función descrita | Evidencia que debe aportar el piloto |
|---|---|---|
| Identidad y permisos | Accesos explícitos para Bots y usuarios | Revocarlos bloquea acciones por cualquier ruta |
| Pasarela | Destino, política y auditoría antes de ejecutar | El registro coincide con destino, argumentos y resultado |
| Ordenador | Perfil, archivos y espacio propio | No accede a producción ni a archivos de otro Bot |
| Control humano | El Bot pausa cuando una persona interviene | También se detienen cambios de shell, archivos y segundo plano |
| Operaciones | Documentación de Compose, Kubernetes y secretos | Hay responsables de actualizaciones, backups, logs y red |
Puntos sólidos del diseño documentado
Política antes de actuar
Las notas describen reglas CEL que fallan de forma cerrada: una regla inválida o desconocida debería denegar, no permitir silenciosamente. Una sugerencia del modelo se convierte en una solicitud que un control separado puede examinar. Compruébalo rechazando navegación, comandos, escritura de archivos y llamadas a plugins. El registro debe identificar la regla sin revelar secretos.
Ordenadores y perfiles por Bot
Separar espacios puede reducir accesos accidentales entre tareas. No elimina el riesgo de una credencial real: un perfil conectado a un panel de producción sigue teniendo acceso de producción aunque cambie el nombre del contenedor.
Auditoría de rechazos y fallos
Registrar acciones permitidas, rechazadas y fallidas es mejor que guardar solo clics exitosos. Incluye usuario iniciador, Bot, destino, decisión, argumentos redactados, resultado y hora. Define quién puede leer y exportar el registro.
Intervención humana
“Take the wheel” permite conducir el navegador mientras el Bot pausa, incluso para iniciar sesión. No equivale a una aprobación completa. Verifica que también se interrumpen shell, archivos y tareas programadas, y que la persona conoce la cuenta y sus permisos.
Lo que todavía no está demostrado
La documentación no acredita madurez para producción, certificación, sandbox garantizado ni rendimiento estable. No deduzcas de un diagrama que:
Son pruebas para tu entorno, no hechos demostrados por el README.
- el Bot resiste toda inyección de instrucciones;
- el navegador no puede acceder a servicios internos;
- la auditoría está completa durante fallos de red;
- el contenedor cumple tus requisitos de aislamiento o normativos;
- cada nueva herramienta queda cubierta por una regla;
- un timeout hará que el agente pare en lugar de reintentar.
Un primer piloto controlado
Elige tareas reversibles: clasificar un buzón sintético, etiquetar tickets de prueba o recopilar información pública en un archivo. No empieces con banca, nóminas, eliminación de clientes, despliegues de producción ni correo sensible.
- 1. Inventaría todas las rutas: perfil, shell, archivos, MCP, plugins, salida de red y tareas programadas. Anota el impacto máximo de cada acceso. Una ruta desconocida impide dar el piloto por preparado.
- 2. Deniega primero: sin envíos externos, comandos destructivos, credenciales de producción ni metadatos internos. Añade permisos estrechos uno a uno; versiona y revisa las políticas como código.
- 3. Prueba rechazo, interrupción y recuperación: dominio prohibido, archivo ajeno, comando no autorizado y repetición después de timeout. Intervén durante el login, detén la tarea, revoca permisos y reinicia. Guarda resultados reconstruibles mediante auditoría.
- 4. Comprueba el estado real: contrasta captura, URL, registro final y fila de auditoría. Una respuesta de herramienta exitosa no demuestra el cambio esperado. Si hay timeout, inspecciona la cuenta antes de reintentar para evitar duplicados.
Del pedido a la acción registrada
Flujo de aceptación propuesto, no una ejecución de OpenBot. Ejemplo: cola de soporte sintética.
- 1. Define el límite: cuenta desechable, cola de prueba, una acción de lectura/escritura y propietario identificado. Permite etiquetas y notas, no correo ni facturación. Detente si exige sesión de producción o una ruta de red no documentada.
- 2. Ejecuta por la pasarela: comprueba destino, política y registro previo. Una etiqueta se permite; exportar tickets ajenos se rechaza con la regla identificada. Detente si se puede acceder directamente al ordenador o falta la auditoría.
- 3. Interrumpe con seguridad: toma el control, detén y revoca mientras observas navegador y shell. Tras completar el login humano, el Bot sigue pausado hasta devolverle el control explícitamente. Detente si continúan escrituras o tareas programadas.
- 4. Concilia evidencia: compara auditoría, navegador, diff y cuenta final. Debe haber una sola etiqueta, la nota correspondiente, secretos ocultos y recuperación registrada. Detente si el timeout deja un resultado desconocido o no puedes exportar el registro.
Preguntas de seguridad
¿Es más seguro que un script de navegador normal?
Tiene controles de política, auditoría e intervención más explícitos. Solo ayudan si todas las rutas los respetan. Compara acciones permitidas, rechazadas, intervención y recuperación, no solo un éxito aislado.
¿Puedo usar mis sesiones existentes?
El proyecto contempla perfiles y login humano. Compatibilidad con una cuenta, MFA o política empresarial depende del entorno. Usa una cuenta dedicada con privilegios mínimos y comprueba almacenamiento, rotación y retirada de credenciales antes de importar sesiones.
¿Está listo para producción?
El repositorio muestra un proyecto activo, no una certificación. Revisa y fija código, imágenes, dependencias y configuración. Haz tu propio análisis de amenazas, prueba de backup y simulacro de incidente antes de conectar sistemas financieros o clientes.
¿Qué debería probar una pequeña empresa estadounidense o india?
Un flujo principalmente de lectura con datos sintéticos: páginas públicas, clasificación de pruebas o borradores para aprobación. Minimiza datos, confirma consentimiento cuando proceda, propietario, retención local y quién puede detenerlo.
Conclusión
La idea valiosa es colocar políticas y auditoría entre el modelo y el ordenador real. Puede ser una base para un piloto acotado. Mantén fuera las credenciales de producción hasta probar todas las rutas, rechazo, interrupción, recuperación y registros.
Fuentes
- Notas v0.1.1
- Notas v0.0.15
- README oficial
- Versiones oficiales
- Arquitectura
- Actualización CopilotKit v0.0.5
- OWASP: seguridad de agentes
Fuentes
Estas son las fuentes oficiales del artículo original. Muchas de sus páginas están en inglés.