Módulo 4 · Parte A de 3

El sandbox de OpenShell

El Módulo 3 proporcionó a OpenClaw contexto persistente y activadores sin supervisión. Las reglas del prompt y las comprobaciones del entorno de ejecución aún influyen en lo que intenta hacer; OpenShell sitúa la decisión final de permitir o denegar en un sandbox que el agente no puede reescribir.

En esta página enviarás comandos reales a tu launchable, leerás cada veredicto y lo relacionarás con la regla que lo produjo. Después examinarás un segundo límite: el plano de control del operador situado por encima del sandbox.

OpenShell separa la entrada de control, la aplicación de políticas, el estado del agente, el acceso a herramientas y el enrutamiento de modelos. Mantén este mapa a la vista mientras la página avanza desde el propósito del sandbox hasta las comprobaciones de la política activa.

Separa claramente los tres roles del producto mientras sigues el flujo de aplicación de políticas:

OpenClaw es el framework del agente. Decide qué herramienta utilizar y qué acción intentar.
OpenShell es el runtime de seguridad. Limita los archivos, destinos de red y operaciones del sistema operativo disponibles para esa acción.
NemoClaw es el stack de referencia que empaqueta OpenClaw y OpenShell con comandos de ciclo de vida, preajustes de políticas, guía de inferencia y configuraciones de despliegue predeterminadas.

OpenShell no depende de un agente específico. El mismo límite puede contener OpenClaw, Hermes, LangChain deepagents u otro proceso que necesite contención a nivel del sistema operativo.

Dónde interviene cada capa de defensa

Supongamos que un contenido no confiable le ordena a un agente leer una credencial y enviarla fuera del sistema. Tres capas distintas tienen la oportunidad de detener esa acción, y cada una responde a una pregunta diferente:

El prompt orienta la intención. Una regla como «no reveles credenciales» describe el comportamiento esperado. Aun así, el contenido recuperado malicioso, la salida de una herramienta u otro agente pueden engañar al modelo. Esta capa influye en la decisión, pero el agente conserva la autoridad que el entorno de ejecución le haya otorgado.
El entorno de ejecución valida la solicitud. OpenClaw o Hermes pueden rechazar una forma de shell no admitida, una llamada a herramienta prohibida o un argumento con formato incorrecto antes de que la solicitud llegue al sistema operativo. Esa comprobación determinista resulta útil, pero sigue siendo lógica de aplicación que puede estar mal configurada, desactualizada o comprometida.
El sandbox limita el resultado. OpenShell solo concede al proceso la autoridad permitida por la política. Si fallan tanto el prompt como el entorno de ejecución, el sistema operativo aún puede denegar una operación de archivo, red o proceso antes de que se complete.

El trabajo práctico de esta página mide esa capa final. Intentarás una acción, observarás el veredicto de permitir o denegar, y conectarás ese veredicto con el mecanismo que lo ejecutó.

Por qué la aplicación de políticas debe estar por debajo del modelo

Supón que una solicitud aparentemente válida aún puede causar daño

Zero trust rechaza la confianza implícita basada únicamente en el origen de una solicitud. La guía de OWASP sobre inyección de prompts aplica la misma disciplina a los agentes: limita las herramientas, restringe los privilegios y supone que el contenido externo puede dirigir al modelo.

Concede únicamente la autoridad que necesita la tarea

Saltzer y Schroeder lo describieron como el principio de mínimo privilegio: cada componente recibe únicamente los permisos necesarios para su trabajo. Esta disciplina es anterior a los agentes y se aplica directamente en este contexto.

Mide los límites en lugar de intentar demostrar la intención

El teorema de Rice descarta una prueba general para el comportamiento no trivial de programas arbitrarios. Un agente que ejecuta código merece la misma cautela: mide los límites de lo que se ejecuta, en lugar de suponer que una comprobación estática puede demostrar que toda acción futura será segura.

Cómo responden los mecanismos del sandbox a preguntas verificables

Este launchable combina cuatro mecanismos del sistema operativo. Cada uno responde a una pregunta que puede comprobar, y juntos aplican la política en más de un límite. Lee la política activa más adelante en la página antes de considerar universal cualquier garantía.

Reglas de prompt y protecciones de la aplicación orientan al agente; la contención del kernel impone el límite final. La flecha bloqueada representa una acción interrumpida antes de llegar al disco o a la red.

1 · ¿Dónde puede conectarse este proceso?

Un espacio de nombres de red (netns) proporciona al agente una red aislada. El acceso saliente comienza cerrado. Un proxy HTTP CONNECT ofrece la única ruta de salida. Open Policy Agent (OPA) compara con la política el binario solicitante, el host, el puerto y la ruta. Quien edite esa política decide qué conexiones están permitidas.

2 · ¿Qué archivos puede alcanzar?

Landlock es un módulo de seguridad de Linux que restringe el acceso futuro al sistema de archivos. Aquí limita las nuevas operaciones de archivos a las rutas otorgadas por la política. Es una aplicación estricta, pero el modo de compatibilidad, OverlayFS y los descriptores abiertos antes de la restricción siguen siendo importantes. Revisa la política en vivo y prueba la ruta que pretendes exponer.

3 · ¿Qué operaciones del núcleo puede solicitar?

Una llamada al sistema, o syscall, pide al kernel de Linux que realice una operación. seccomp filtra las syscalls; su filtro BPF compara cada solicitud con una lista de permitidos. Una llamada denegada devuelve EPERM, «operación no permitida», antes de ejecutar la operación. Este launchable excluye primitivas peligrosas como ptrace, mount y setuid.

4 · ¿Con qué autoridad comienza?

El agente se ejecuta como un proceso que no es root mediante el usuario sin privilegios sandbox. Por tanto, un exploit que tenga éxito comienza con menos autoridad. Esa autoridad inicial menor reduce el alcance del impacto, pero no demuestra que sea imposible escalar privilegios. El host, la configuración del contenedor y la política de syscalls siguen formando parte del límite de seguridad.

Vocabulario en estos cuatro mecanismos

Política de red

Espacio de nombres de red / netns: Stack de red Linux aislado: dispositivos, rutas, reglas de firewall y puertos de sockets. network_namespaces(7)
Entrada / salida: Ingress es el tráfico que entra en el sandbox; egress es el que sale. Denegar de forma predeterminada significa que ninguna dirección está abierta salvo que la política la conceda.
Proxy CONNECT: Proxy de túnel HTTP hacia el host y el puerto solicitados; las implementaciones seguras restringen los destinos permitidos. MDN CONNECT
OPA: Motor de políticas que evalúa una entrada estructurada y devuelve decisiones al código que las aplica. Documentación de OPA
Binario, host, puerto, ruta: Entradas de la política de egress: identidad del ejecutable, nombre del destino, puerto TCP y ruta URL solicitada.

Límite del sistema de archivos

Landlock: Módulo de seguridad de Linux que permite a un proceso sin privilegios restringir su propio acceso futuro. Documentación del kernel
Privilegios del entorno: Acceso que, de otro modo, un proceso heredaría del sistema operativo, del proceso padre, de los montajes o de las credenciales.
Árbol del workspace: Subárbol de directorios que concede una política. Comprueba la política activa y la compatibilidad del kernel antes de tratarlo como un límite completo del sistema de archivos.
Montaje enlazado: Subárbol del sistema de archivos que se hace visible en otra ruta, incluso a través de límites de chroot. mount(2)
Condiciones de carrera con enlaces simbólicos: Una ruta ya comprobada cambia mediante un enlace simbólico antes de utilizarse. symlink(7)

Límite de syscalls

seccomp: Filtrado de syscalls de Linux que reduce la superficie del kernel que puede alcanzar un proceso. Documentación del kernel
Lista de syscalls permitidas: Conjunto de syscalls que pueden ejecutarse; todas las demás reciben una acción de la política.
Capa BPF: Programa de filtrado que comprueba los números y argumentos de las syscalls antes de ejecutarlas. Documentación del kernel
TOCTOU / carrera de inspección: Fallo entre el momento de la comprobación y el del uso; seccomp evita carreras de desreferencia de punteros dentro del filtro. Documentación del kernel
EPERM / EACCES: Nombres errno de Linux para «operación no permitida» y «permiso denegado». errno(3)

Identidad del proceso

Proceso del agente: Proceso del sistema operativo que ejecuta el agente y sus herramientas dentro de estos límites.
Usuario sin privilegios de root: Un UID distinto de cero sujeto a las comprobaciones habituales de permisos del kernel. capabilities(7)
Capacidad de Linux: Privilegio de root separado, como CAP_SYS_ADMIN o bien CAP_SETUID. capabilities(7)
ptrace, mount, setuid: Primitivas peligrosas para el control de procesos, el montaje del sistema de archivos y el cambio de identidad. ptrace(2) · mount(2) · setuid(2)
Escalada de privilegios: Obtención de autoridad superior a la asignada: root, capacidades adicionales, acceso más amplio a archivos o a la red.

Da forma primero al runtime

Antes de que controles el sandbox tú mismo, asegúrate de que el agente esté en un estado óptimo recuperando el entorno de ejecución si está degradado; así, cada celda en vivo de abajo tendrá un agente funcional con el que comunicarse.

El diagrama traza lo que ocurre en cada llamada a una herramienta, y las celdas siguientes permiten realizar esas llamadas y leer la respuesta del kernel.

El mismo runtime de Kickstart. Cada celda controla al agente OpenClaw conectado en esa página.

Observa cómo decide el kernel

Los cuatro mecanismos anteriores se están ejecutando en el entorno de pruebas, por lo que puedes hacer que cada uno decida por sí mismo en lugar de confiar ciegamente en el diagrama.

La celda siguiente ejecuta un comando a la vez. Planteas una pregunta, la celda ejecuta el comando correspondiente en el sandbox y devuelve tres datos:

el veredicto que devolvió el kernel,
el mecanismo que lo decidió
y la línea de evidencia que sustenta la decisión.

El catálogo inicial recorre las preguntas que plantearías sobre un entorno como este, desde el acceso abierto a Internet hasta la modificación de la personalidad del agente. Puedes editar cualquier comando o añadir tu propia sonda.

Profundo · Trayectoria¿Ejecutar una trayectoria de varios comandos en el sandbox?

Avanza: una trayectoria completa

Un agente real encadena varios comandos para alcanzar un objetivo que ninguna celda aislada intenta por sí sola. Describe uno en el siguiente campo y el agente planificará toda la secuencia de comandos que el shell ejecutaría para alcanzarlo antes de ejecutar cada comando en el sandbox y mostrar los resultados. Observa el plan y el punto donde el kernel impide continuar porque la contención detiene la trayectoria.

La misma regla de los comandos aislados sigue vigente. Un secreto que se imprime en cualquier paso ya quedó expuesto, aunque se deniegue un intento posterior de egress. Después de observarlo, edita el objetivo o el prompt de planificación y prueba otra trayectoria.

Lee la política activa del launchable y visualízala como un mapa

Los veredictos observados proceden de un archivo de políticas. Léelo desde el launchable antes de confiar en sus garantías. La celda siguiente llama a helpers.policyGet(), que ejecuta openshell policy get mediante la terminal del operador y analiza el resultado.

La página ahora realiza los cálculos a partir de la política de tu máquina en lugar de usar un ejemplo predefinido. La celda mantiene su código en un menú desplegable, donde puedes inspeccionar la llamada exacta sin convertirla en la lección principal.

Con tu política en mano, la celda la dibuja como un mapa interactivo a continuación, donde cada nodo de la derecha es un endpoint nombrado por tu política junto con algunos que ninguna política permite. Cambia el binario solicitante y observa cómo cambian las conexiones. El kernel decide según el binario, no solo el host: integrate.api.nvidia.com puede estar disponible para openclaw y denegado para curl.

Haz clic en cualquier objetivo para abrir la regla que lo gobierna, los binarios que permite y la justificación del veredicto. Ver el código fuente de la política muestra el mismo YAML que obtuviste en el paso anterior.

Plano del token de operador. La franja ámbar está por encima del punto de aplicación: representa el eje de escalada que las reglas de egress nunca ven.

Demuestra dónde se mantiene el sandbox y confírmalo en vivo

No tienes que aceptar una garantía de robustez sin pruebas. openshell policy prove comprueba una propiedad de la política o devuelve un contraejemplo, mientras el proxy toma una decisión determinista de permitir o denegar en cada conexión. La celda calcula esa misma decisión en el navegador desde la política real del launchable, luego ejecuta la acción en el sandbox activo y comprueba que el veredicto del kernel coincide con la predicción.

Este ejercicio pone a prueba la identidad de un binario. La política concede egress por programa, no por host, así que el proxy comprueba qué binario abrió la conexión antes de evaluar el destino. Por ello, openclaw puede alcanzar el endpoint de inferencia mientras se deniega un curl al mismo destino. Elige una acción para ver de inmediato el veredicto estático y su confirmación activa; la acción del endpoint de inferencia muestra con mayor claridad este cambio de resultado para un mismo host.

La confirmación utiliza la instancia real. Cada acción se ejecuta en el launchable conectado en Kickstart mediante openshell sandbox exec. Mantén el launchable abierto en otra pestaña para conservar la sesión de acceso.

Cuando coinciden el veredicto previsto y el resultado en vivo, la política hace exactamente lo que indica el análisis estático. Una diferencia revela un comportamiento que la predicción no capturó, ya sea por un ajuste inesperado, una diferencia del entorno o una carencia del modelo de análisis. En cualquier caso, aprendes algo importante antes de empezar a confiar en la máquina en serio.

Por encima del sandbox: el plano de control

Hasta ahora has medido lo que puede hacer el agente. La pregunta más amplia es quién puede reconfigurarlo a través del plano situado por encima del sandbox. La forma de acceder a ese plano depende del sistema, y en esta máquina dicho plano es un único gateway al que accedes con el mismo OPENCLAW_GATEWAY_TOKEN del Módulo 3, con alcance operator.admin. Ninguna de esas operaciones pasa por el sandbox del agente.

Ese token permite:

agents.files.get y agents.files.set leen y establecen directamente archivos de personalidad, como SOUL.md y AGENTS.md.
cron.add y cron.list controlan tareas que pueden activarse después de terminar la conversación.
config.get y config.patch controlan toda la configuración del agente: el modelo, las herramientas e incluso toolSearch.
chat.send envía un mensaje a mitad de la tarea que redirige al agente mientras sigue pareciendo que está trabajando en tu solicitud original.
sessions.reset y delete borran memoria; gateway.restart.request reinicia el runtime.

Encadenadas, esas llamadas se convierten en una ruta de escalada de privilegios. Un atacante que pueda leer la personalidad puede implantar una tarea cron que se active mucho después de que termine la conversación y parchear la configuración en ejecución para ampliar lo que el agente tiene permitido hacer. Un turno a mitad de la tarea lo redirige, y un reinicio del runtime hace que la nueva configuración surta efecto.

El sandbox gobierna las syscalls del agente, pero estas operaciones pertenecen al plano de control y no son llamadas al sistema iniciadas por el agente. La solidez del sandbox y el alcance administrativo son propiedades distintas. Un equipo puede restringir el primero y dejar abierto el segundo; evalúa ambos límites.

La protección es deliberadamente unilateral. El sandbox conserva su solidez frente a los errores del agente e incluso frente a un compromiso total del mismo, pero no tiene visibilidad sobre quién controla el plano administrativo situado por encima. Protege el acceso a ese plano como si fuera root. En esta instancia, quien lo controla puede reconfigurar la identidad del agente y crear tareas programadas completamente fuera del alcance de las comprobaciones del sandbox.

Enumera ese alcance en el launchable. La celda solo realiza lecturas y no cambia la configuración.

Lo que el sandbox no puede capturar

Todo lo visto hasta ahora eran las propias acciones del agente, y el kernel mantuvo la línea de defensa. Sin embargo, dos tipos distintos de daños aún logran evadirlo. El primero es el plano de control que acabas de enumerar, que reconfigura al agente desde arriba del punto de control. El segundo utiliza un conjunto autorizado: cada acción aislada está permitida, pero su composición causa el daño.

La entrada no confiable, el acceso a datos privados y la comunicación externa forman la tríada letal.

Datos privados son información que el agente puede leer, pero no debe divulgar: archivos del workspace, correos electrónicos, tokens, memoria o registros internos.
Entrada no confiable es contenido no escrito por el operador que el modelo puede interpretar como instrucción: una página web, un issue, un documento, el resultado de una herramienta o la respuesta de otro agente.
Comunicación externa es cualquier ruta capaz de transportar bytes al exterior: HTTP, pull request, chat, línea de log, carga de imagen o enlace que abre el usuario.

El riesgo surge de la composición. La política puede autorizar correctamente un endpoint, pero la conexión sigue siendo bidireccional: la solicitud sale y la respuesta regresa como una entrada nueva. El contenido hostil puede dirigir al modelo para que lea datos privados y los envíe mediante un canal permitido. Un control situado por encima del sandbox debe interrumpir al menos una de esas tres condiciones.

El centro rojo muestra una ruta formada por recursos permitidos, no una acción aislada prohibida. El contenido hostil influye en un runtime que lee estado protegido y usa un canal aprobado. Como el canal también recibe respuestas, una lista de permisos de red no basta para decidir si la conexión es segura.

Estas brechas existen en una configuración estándar, y las políticas de red y del sistema de archivos no pueden resolverlas por sí solas:

Manipulación de la personalidad. SOUL.md pertenece al agente y se puede escribir; un agente confundido o comprometido puede reescribir su propia identidad. El propietario puede revertir chmod. Un chattr +i aplicado por root fuera del sandbox crea un límite más sólido.
Plano de control con privilegios de identidad. Quien posea OPENCLAW_GATEWAY_TOKEN puede leer la personalidad, crear una tarea cron e introducir un turno por encima del punto de aplicación del kernel.
Inyección mediante entradas. Bloquear egress por patrones evita algunas fugas, pero no elimina las instrucciones maliciosas que llegan por un canal autorizado. Esta es la inyección indirecta de prompts descrita por Greshake et al. Mitigarla exige procedencia, clasificación de entradas y evaluación del comportamiento.
Exfiltración por canal permitido. Un endpoint autorizado todavía puede transportar datos indebidos. La política prueba que el canal está permitido; no determina si el contenido es benigno.
Intención oculta. El gateway reenvía acciones sin exponer el razonamiento del modelo. Un agente comprometido puede ejecutar un flujo de trabajo dañino compuesto por acciones que, aisladas, parecen válidas.
Preservación entre pares. En una flota, el contexto social puede alterar el criterio de un agente al evaluar o detener a otro. Las pruebas de regresión del comportamiento deben detectar ese cambio.

Elige el control por el modo de fallo

Un sandbox limita lo que puede alcanzar un proceso comprometido. La aplicación y las prácticas operativas aún deben tomar decisiones cuyo significado resulta invisible para el kernel.

Modo de fallo	Lo que el sandbox contribuye	Control aún necesario
Secuestro de objetivos o inyección de prompts	Limita los archivos, procesos y destinos alcanzables después de desviar el modelo	Procedencia de entradas, aprobación de acciones con consecuencias y evaluación del comportamiento
Uso indebido de herramientas	Restringe el sistema operativo y el conjunto de accesos de red donde se ejecuta la herramienta	Autorización por herramienta, validación de argumentos, límites de frecuencia y confirmación de llamadas irreversibles
Abuso de identidad o privilegios	Inicia el proceso sin root y bloquea algunas rutas de escalada	Identidades por carga de trabajo, alcances mínimos, tokens de corta duración, rotación y auditoría
Cadena de suministro o ejecución inesperada de código	Reduce los archivos, syscalls y egress disponibles para el código instalado	Dependencias fijadas y verificadas, política de instalación y supervisión de la integridad
Envenenamiento de memoria o contexto	Puede proteger archivos específicos cuando la política los establece como solo lectura	Procedencia de escrituras, historial auditable, etiquetas de confianza y restauración a un estado conocido

Las categorías se corresponden con el OWASP Top 10 para aplicaciones de agentes. Utiliza la tabla para elegir un punto de aplicación de políticas en lugar de pedirle a una sola capa que reconozca cada tipo de daño.

El sandbox establece una base, no una defensa completa. Concede al agente el conjunto mínimo de accesos necesarios, comprueba sus garantías y añade controles en las capas superiores para los fallos que el kernel no puede ver.

Referencias

Simon Willison, The lethal trifecta (2025). Define la combinación de acceso a datos privados, contenido no confiable y comunicación externa que representa el diagrama de la tríada letal.
Greshake et al. (2023) Not what you've signed up for. Trabajo de referencia sobre inyección indirecta de prompts: ataques entregados mediante contenido recuperado o renderizado en el que el modelo confía.
Saltzer y Schroeder, The Protection of Information in Computer Systems (1975). Trabajo que definió el principio de mínimo privilegio, base de la contención que deniega de forma predeterminada.
seccomp filter y Landlock. Primitivas del kernel para listas de syscalls permitidas y control de acceso al sistema de archivos, utilizadas por los mecanismos 2 y 3 de openshell.
Open Policy Agent. Mecanismo de política como datos que evalúa el proxy CONNECT y controla cada conexión de salida.
NeMo Guardrails. Complemento en la capa de aplicación para la contención en el núcleo; detecta violaciones de política que el núcleo no puede interpretar.
OWASP Top 10 for Agentic Applications. Taxonomía actual de secuestro de objetivos, uso indebido de herramientas, abuso de identidad, compromiso de la cadena de suministro, ejecución inesperada de código y envenenamiento de memoria.

Lista completa en Para ir más lejos · Referencias.

← Módulo 3c: Siempre activo Módulo 4b: CLI modernos →