El sandbox de OpenShell
En el módulo 3, los archivos aportaban contexto persistente y las tareas programadas iniciaban trabajo sin supervisión. Estas operaciones dependen de los permisos disponibles para el proceso del agente. OpenShell limita esos permisos mediante la política activa y su aplicación.
Ejecuta comandos en el sandbox, examina su salida y estado de salida e investiga la causa. Después, comprueba el acceso de lectura mediante el plano de control del operador.
- 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.
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.
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.
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 representa los límites de aplicación. Los siguientes comandos devuelven observaciones; identificar el mecanismo responsable requiere pruebas de la política o de auditoría.
El mismo runtime de Kickstart. Cada celda controla al agente OpenClaw conectado en esa página.
Examinar los resultados de los comandos
Ejecuta un comando cada vez y examina su salida, su estado de salida y si terminó. Un fallo puede deberse a la política, a software ausente, a una solicitud no válida o al propio servicio. Usa las pruebas y la política actual para investigar la causa.
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.
¿Ejecutar una trayectoria de varios comandos en el sandbox?
Avanza: una trayectoria completa
Un agente puede planificar varios comandos para un objetivo. Examina el plan y compara cada comando con la salida y el estado de salida que devuelve tu sandbox. Determina qué resultados aportan pruebas de denegación de acceso y cuáles requieren más investigación.
Un secreto que imprime un comando permitido ya ha llegado al canal de salida. Examina tanto los pasos exitosos como los fallidos: una denegación de red posterior no puede deshacer una divulgación anterior.
Lee la política activa del launchable y visualízala como un mapa
Lee la política del entorno de ejecución antes de interpretar los resultados de los comandos. La celda llama a helpers.policyGet() a través del terminal del operador y muestra su estado y el YAML analizado. Comprueba si la política devuelta está activa.
El mapa evalúa los destinos propuestos según la política cargada. Cambia el binario que realiza la llamada para comparar sus permisos y examina la regla coincidente. Son predicciones del navegador; las solicitudes reales aportan una observación independiente.
Al hacer clic en un destino se abre la regla que lo rige, para que puedas consultar qué binarios permite ese endpoint y qué regla utiliza el evaluador del navegador. El control View policy source muestra el YAML del que se obtuvo la regla, el mismo texto que acabas de recuperar.
Compara una predicción de la política con una solicitud real
Elige una acción, predice su resultado a partir de la política cargada y ejecuta la misma solicitud a través del sandbox. Compara las pruebas sin asumir que un error de comando demuestra la aplicación de la política ni que un resultado coincidente demuestra todas sus reglas.
La predicción tiene en cuenta la identidad del binario, el destino, el puerto, el método y la ruta. Confirm ejecuta la solicitud curl seleccionada. Las demás identidades de binario siguen siendo predicciones hasta que pruebes cada programa mediante su propia interfaz.
openshell sandbox exec devuelve la salida y el estado de salida del comando. Un error HTTP puede proceder de un proxy o de la aplicación de destino; identifica su origen antes de atribuirle una causa.Por encima del sandbox: el plano de control
La celda solicita operator.admin con el token de gateway existente y llama a métodos de lectura de la personalidad, horarios, sesiones, modelos y configuración. Examina qué solicitudes funcionan. La configuración del servidor puede permitir escrituras administrativas, pero esta comprobación no las prueba. No envía solicitudes de edición; las conexiones y lecturas sí pueden generar registros.
Lo que el sandbox no puede capturar
La comprobación de lectura no demuestra autoridad de escritura. Por separado, un flujo dañino puede combinar lecturas y canales de salida permitidos individualmente.
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.
Considera estos modos de fallo según la configuración real:
- Alteración de la personalidad. Si el agente puede modificar SOUL.md, examina su propiedad y los permisos de escritura. La política, la protección de archivos gestionada por el host y un historial revisable pueden ayudar a proteger los cambios de personalidad.
- Autoridad del plano de control. El alcance del token y la configuración del servidor determinan los métodos administrativos disponibles. Las lecturas exitosas no demuestran permiso para cambiar la personalidad, el horario o la conversación.
- Inyección entrante. Un canal permitido puede transportar instrucciones adversarias. Las restricciones de red no demuestran que el contenido entrante sea fiable; evalúa por separado el tratamiento de las entradas y las acciones con consecuencias.
- 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. Varias acciones permitidas por separado pueden combinarse en un flujo de trabajo dañino. Revisa sus efectos conjuntos al evaluar un registro de herramientas.
- Preservación entre pares. El veredicto de un agente sobre otro puede cambiar según el contexto social. Compara sus juicios al variar ese contexto de forma controlada.
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.
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.