Cómo protegemos los agentes persistentes como OpenClaw en OpenAI

Cuando OpenClaw salió al público hace casi un año, mostró al mundo lo que puede hacer un agente persistente. En una sesión habitual de Codex, una persona guía al agente hacia un objetivo definido. Los agentes persistentes, en cambio, funcionan las 24 horas del día, los 7 días de la semana, tienen un amplio margen de acción y pueden actuar por iniciativa propia sin que el usuario intervenga.

A pesar de sus capacidades, hasta ahora los agentes persistentes se han implementado poco en entornos reales. Su implementación plantea desafíos nuevos para quienes están acostumbrados al software tradicional. Con ese tipo de software, hemos podido contar con que el código y la configuración determinan el comportamiento y que las amenazas provienen, en su mayoría, de atacantes externos. Los agentes persistentes pueden cambiar su propia configuración y escribir código arbitrario para alcanzar un objetivo. Cuando actúan de una manera que se aparta de lo previsto, los ataques pueden originarse desde dentro.

En OpenAI ya tenemos agentes persistentes en toda la empresa, entre ellos cientos de agentes de OpenClaw. En este artículo describimos algunos de los controles que adoptamos para poder implementar OpenClaw en OpenAI.

Separar la ejecución de confianza de la que se considera no confiable

Para proteger los agentes persistentes, tuvimos que aislar la lógica determinista de confianza de la ejecución del LLM, que consideramos no confiable. La lógica de confianza incluye componentes críticos como los que gestionan la red, la identidad y el aislamiento mediante sandbox. Se trata de código estático tradicional que, salvo que haya errores de software, debería comportarse según su configuración. Consideramos que los agentes, el entorno donde se ejecutan y el código que escriben no son confiables. En ese entorno, los agentes pueden generar código de forma dinámica para lograr un objetivo, sin que haya garantías estrictas sobre su comportamiento.

Para que OpenClaw admitiera esta separación, incorporamos al proyecto de código abierto la posibilidad de ejecutar el arnés de ejecución de forma remota. Así, OpenClaw Gateway pudo ejecutarse en un contenedor distinto al del arnés de ejecución del agente y, en nuestro caso, también en otro clúster.

Una vez separados ambos componentes, pudimos tratar la puerta de enlace, que configura el agente, como código determinista de confianza y concentrarnos en aislar la carga de trabajo del agente en un sandbox como código no confiable.

Aplicar límites de seguridad estrictos

El sandbox impone límites de seguridad a las cargas de trabajo de los agentes al restringir las acciones que pueden realizar.

En nuestra implementación de OpenClaw usamos los siguientes controles del sandbox:

• Red: controlamos a qué puntos de acceso puede conectarse un agente. Usamos una lista de destinos permitidos administrada por la organización y bloqueamos explícitamente los puntos de acceso restringidos.
• Espacio de trabajo: controlamos a qué archivos puede acceder un agente. Solo permitimos la escritura en los directorios de trabajo de los agentes.
• Procesos: controlamos a qué procesos puede acceder un agente mediante el aislamiento de procesos que ofrece el sandbox de Codex para Linux.
• Secretos: controlamos a qué secretos puede acceder un agente. Los gestionamos mediante un intermediario de credenciales para que el agente no pueda verlos.

Para implementar OpenClaw, usamos el sandbox integrado en el arnés de ejecución de Codex. A continuación se muestran algunos de los ajustes que usamos en requirements.toml, que restringe las opciones disponibles al configurar Codex, y en config.toml, que contiene la configuración que usa Codex. También aplicamos otros controles de seguridad. Inhabilitamos el modo danger-full-access y usamos la búsqueda web en caché, que dirige las consultas al índice de búsqueda de OpenAI.

requirements.toml

# Exclude unrestricted "danger-full-access" sandbox mode.
allowed_sandbox_modes = ["read-only", "workspace-write"]

# Permit cached hosted search, but not live hosted search.
allowed_web_search_modes = ["cached"]

# Require the managed network proxy.
experimental_network.enabled = true

# Prevent user-level configuration from expanding the domain allowlist.
experimental_network.managed_allowed_domains_only = true

# Allow only these destinations; replace with the workload's required hosts.
experimental_network.allowed_domains = [
  "github.com",
  "api.github.com",
  "codeload.github.com",
]

# Explicitly block these destinations, including cloud metadata endpoints.
experimental_network.denied_domains = [
  "pastebin.com",
  "*.pastebin.com",
  "webhook.site",
  "metadata.google.internal",
  "169.254.169.254",
]

config.toml

# Select the permission profile defined below.
default_permissions = "openclaw"

# Use cached hosted search.
web_search = "cached"

[permissions.openclaw.filesystem]
# Allow reads needed by the minimal runtime environment.
":minimal" = "read"

# Allow reading and modifying the agent's workspace.
"/home/dev-user/openclaw-workspaces" = "write"

# Allow reading managed assets without modifying them.
"/home/dev-user/read-only" = "read"

# Prevent access to SSH credentials.
"/home/dev-user/.ssh" = "deny"

[permissions.openclaw.network]
# Permit network access through the administrator-required proxy.
enabled = true

# Do not inherit an upstream proxy.
allow_upstream_proxy = false

# Keep the proxy's local/private-address guard enabled.
allow_local_binding = false

# Disable the SOCKS5 listener.
enable_socks5 = false

# Disable SOCKS5 UDP support.
enable_socks5_udp = false

# Do not permit proxy listeners on non-loopback addresses.
dangerously_allow_non_loopback_proxy = false

# Do not permit unrestricted Unix-socket access.
dangerously_allow_all_unix_sockets = false

[shell_environment_policy]
# Preserve default filtering of sensitive environment variables.
ignore_default_excludes = false

# Remove GitHub credentials from agent command environments.
# This does not hide credentials stored in accessible files.
exclude = [
  "GH_TOKEN",
  "GITHUB_TOKEN",
  "OPENCLAW_GITHUB_BASIC_AUTH",
  "OPENCLAW_GITHUB_READONLY_BASIC_AUTH",
]

[apps._default]
# Disable apps unless individually enabled.
enabled = false

# Disable destructive app operations by default.
destructive_enabled = false

# Disable open-world app operations by default.
open_world_enabled = false

Incorporar medidas de protección basadas en modelos

Todos los controles descritos hasta aquí son estáticos en el sentido de que dependen de código determinista tradicional para impedir que un agente se aparte de lo previsto. A medida que los modelos se vuelven más capaces, es fundamental contar también con defensas que mejoren al disponer de más recursos de cómputo. Para eso recurrimos a otros modelos.

Con la Revisión automática, un segundo agente puede supervisar y aprobar las acciones del agente principal. Pedir a una persona que revise cada acción genera fatiga y la acostumbra a aceptar todas las solicitudes de permiso sin examinarlas. Usar un revisor basado en un LLM como filtro nos permite reservar la atención humana para las solicitudes de aprobación más importantes. Tanto OpenClaw como Codex incluyen esta función de forma nativa.

En nuestra implementación de OpenClaw, exigimos la revisión automática de todas las acciones de los agentes.

Separar la identidad del agente de la del usuario

Cuando un agente realiza una acción, necesitamos poder auditarla, darle al agente acceso a los recursos y determinar si la acción la inició el agente o el usuario. La identidad del agente nos permite hacerlo. Algunas especificaciones en desarrollo, como WAG, permiten que los agentes accedan a los recursos por derecho propio. Otras, como XAA, les permiten actuar en nombre del usuario mediante la delegación de OAuth. La identidad de un agente es distinta de una cuenta de servicio, que proporciona a un bot acceso independiente a la API. Conviene usar ambas en conjunto. Por ejemplo, tu agente debería actuar con su propia identidad y acceder a servicios de terceros mediante cuentas de servicio vinculadas a esa identidad.

En nuestra implementación de OpenClaw, cada agente tiene una identidad única asociada a una cuenta de servicio de ChatGPT. Así, cada agente tiene su propia credencial de inferencia, independiente de la del usuario, y los equipos pueden conectar complementos personalizados al agente. También podemos auditar las acciones del agente y, si es necesario, desactivar la inferencia.

Observar todo el ciclo de vida

La observabilidad de principio a fin permite a los operadores entender todo el ciclo de vida de los agentes, desde cómo se configuraron hasta qué acciones realizaron. Con los agentes persistentes, esa cobertura es fundamental para rastrear y detectar acciones que se apartan de lo previsto.

En nuestra implementación de OpenClaw, registramos todo cambio de configuración en el plano de control y todos los turnos de los agentes. Como esos turnos pueden contener información sensible, restringimos el acceso a los registros a unas pocas personas del equipo de seguridad.

Reflexiones finales

La adopción de agentes persistentes aún está en sus primeras etapas. La falta de buenas prácticas establecidas dificulta su implementación en muchas empresas.

Cuando pusimos en marcha el piloto interno de OpenClaw en OpenAI, vimos un gran aumento tanto en la productividad como en la adopción entre los equipos técnicos y no técnicos de toda la empresa. Hoy tenemos más de 500 agentes que trabajan por iniciativa propia en segundo plano. Entre otras tareas, abren Pull requests automáticamente en respuesta a comentarios sobre el producto y realizan de forma continua experimentos con datos para evaluar nuevas funciones.

Durante el OpenAI DevDay anunciamos OpenClaw Enterprise (OCE), un plano de control de código abierto para agentes, independiente de cualquier proveedor. Si usas OCE, puedes iniciar un agente con muchas de las protecciones que describimos gracias a la configuración preestablecida estándar de Codex. El proyecto sigue en fase piloto y tenemos previsto publicar la versión 1.0 para fines de año.

Creemos que muchos de los mayores beneficios de la IA para la industria vendrán de los agentes persistentes. Al compartir lo que aprendimos y desarrollar OCE de manera abierta, esperamos que cualquier persona pueda implementar estos agentes con mayor seguridad.