Aprender a restringir herramientas, archivos y acceso a red con OpenShell es el paso que separa un agente que parece seguro de uno que realmente lo es. En esta práctica vas a definir y verificar que un sandbox cumple las reglas que tú le impones, y por qué eso importa para cualquiera que exponga un agente de IA al público.

La idea central es simple pero poderosa: no basta con decir que algo es seguro, hay que ponerlo a prueba de verdad. Y aquí viene lo interesante, porque probar la seguridad de un agente también es un loop, pero esta vez un loop de seguridad.

Por qué la combinación OpenShell y OpenClaw protege tus credenciales

Cuando lanzas OpenClaw, ya vienen limitaciones por defecto. Esa primera capa de seguridad vive en los archivos de soul y en los archivos de policy que se crean automáticamente al arrancar el sistema.

La pieza clave es cómo viajan las credenciales. En el kit completo de NeMo Claw, la API key nunca llega a OpenClaw ni es accesible para él. Tú entregas un voucher y, a través de él, pasando por la recepción, se envía el request completo hacia el cloud de Nvidia para obtener la respuesta de los modelos.

¿Por qué no puedo extraer la API key de un agente con OpenShell? Porque las credenciales nunca llegan a OpenClaw. El agente usa un voucher que pasa por la recepción hacia el cloud de Nvidia, así que la API key nunca es accesible aunque se la pidas directamente.

Por más que intentes obtener cuál es la API key, no puedes llegar a ella [02:00].

Qué reglas puedes definir en el sandbox y dónde ponerlas

Para entender la seguridad real, necesitas leer las políticas del sandbox: cuáles son las limitaciones y cuáles son los puntos débiles. Luego empujas el chat hasta donde puedas y comparas el comportamiento antes y después.

Las reglas se colocan en las carpetas, y ahí decides qué puede leer y dónde sí o no puede escribir [02:52]. También puedes crear candados en archivos, y esto es más fino de lo que parece.

• Puedes permitir lectura y escritura en una carpeta, pero bloquear la edición de un archivo específico dentro de ella.
• Puedes dar acceso de lectura a la carpeta de workspace pero jamás permitir editar el archivo de policy.
• Puedes controlar el acceso a Internet: a qué sitios acceder e incluso en cuáles escribir o no [05:14].

Esa granularidad es lo que convierte una política vaga en una defensa concreta.

Cómo funcionan los permisos de usuario en Linux

Si no vienes del mundo de la administración de sistemas, tranquilo. En Linux, igual que en Mac y en Windows, los usuarios tienen privilegios como lectura, escritura e incluso instalación de programas.

Piensa en una computadora pública: podías navegar y escribir documentos de Word, pero no instalar programas. Ese mismo concepto aplica aquí. El sandbox corre sobre un entorno Linux, igual que la virtual machine, así que agregar permisos se reduce a pocos comandos [04:04].

¿Qué es el usuario sandbox en OpenShell? Es un usuario predefinido con permisos asignados que determinan qué procesos puede correr. No tiene privilegios de root, por lo que no puede, por ejemplo, eliminar todo el sistema ni acceder al directorio raíz.

Este usuario, identificado como UID 998, es el personaje principal de toda la prueba.

Qué pasó al intentar escalar privilegios

Simulando ser un atacante externo, empecé preguntándole al agente qué archivos y folders podía ver. Primer problema: me reveló la estructura de su raíz, que en realidad no es la raíz de Linux sino el workspace del agente, con carpetas como agents, heartbeat, identity, policy, saw, tools y user [06:15].

Luego probé hasta dónde llegaba el límite:

1. Pedí ver el directorio home y me lo mostró sin problema.
2. Intenté subir por encima del home para acceder a datos de otros usuarios, y me respondió que es el usuario sandbox sin privilegios de root [07:21].
3. Intenté listar la raíz del sistema con ls y recibí "permiso denegado".
4. Probé cd ~, luego cd .. y listar: también denegado [08:19].
5. Intenté escalar con sudo su, pero el comando sudo ni siquiera está en su lista de comandos posibles [08:52].

Hasta ahí, la defensa aguantó. Pero gané un insight importante: puedo ejecutar ciertos comandos de batch en la terminal.

El punto débil: instalación de paquetes

La prueba más reveladora fue pedir una política aparentemente benigna: instalar Codex CLI, la forma de usar el agente de código de ChatGPT en la terminal. Esperaba un "no".

Después de trabajar 37 segundos, el agente descubrió que sí podía. Tenía disponibles herramientas peligrosas en las manos equivocadas [09:51]:

• Node y npm, para instalar paquetes.
• npx, para ejecutar paquetes.
• pip, para instalar paquetes de Python.
• curl, para descargar contenido web y hacer requests.

Seguíamos sin sudo, pero eso ya no importaba: con esto el agente podía instalar Codex por su cuenta. Ahí está la tensión de todo el ejercicio, en que una capa de protección puede esconder una puerta abierta.

¿Qué reglas agregarías tú para cerrar ese hueco de instalación de paquetes? Cuéntamelo en los comentarios.