Si vas a exponer un agente de IA a usuarios reales, las políticas de sandbox son tu primera línea de defensa contra vulnerabilidades como la instalación de paquetes maliciosos. Aquí verás cómo leer, interpretar y modificar esas políticas usando OpenShell y OpenClau, incluso si no sabes programar. Es contenido clave para quien construye asistentes con modelos de pesos abiertos.

Por qué instalar paquetes con npm o pip es un riesgo de seguridad

Al inspeccionar el entorno descubrimos que tenía instalados npm y pip, lo que significa que el agente puede instalar paquetes. Suena inofensivo, pero ahí está el peligro.

Para demostrarlo, probamos instalar Matplotlib, una librería benigna de visualización de datos en Python, y la instaló sin problema. Lo mismo ocurrió con Plot.js, su equivalente para JavaScript [00:16].

¿El problema? Nadie verifica que los paquetes de estos repositorios no tengan código malicioso. Puedes subir un paquete dañino, inyectarlo y escalar privilegios.

¿Por qué npm es peligroso en un agente de IA? Porque permite ejecutar scripts con acciones casi de superusuario, lo que puede extraer credenciales y toda la información del sistema. Los paquetes no se verifican antes de publicarse.

Esto importa sobre todo cuando vas a exponer el agente al público. Debes estar listo para contrarrestar estos comportamientos antes de que alguien los aproveche.

Cómo leer las políticas de tu agente sin saber programar

La herramienta clave aquí es el cookbook o recetario, un conjunto de comandos extremadamente útiles. El comando que usamos fue openshell-policy get my-assistant, que muestra las políticas activas del asistente [01:20].

Al correrlo en la VM terminal aparece un archivo larguísimo que puede intimidar, pero es fácil de leer. Estos son los cuatro niveles de políticas que maneja el sistema:

• La política de red, que controla el acceso a internet.
• La política de usuario, sobre los permisos del usuario.
• La política de file system, que define el acceso a archivos.
• La política landlock, el candado que se aplica a archivos específicos.

¿Qué es la política landlock? Es el candado que aplicas a archivos individuales. Aunque una carpeta tenga permiso de escritura, landlock puede impedir que el agente modifique un archivo concreto dentro de ella.

En el archivo vimos que el workdir, el directorio de trabajo, estaba incluido. Si cambias ese valor a false, el agente ya no podrá modificar archivos de soul, memory, policy o user.

Qué significan los permisos de lectura y escritura

La política distingue entre carpetas de solo lectura y carpetas de lectura y escritura. El agente puede acceder a varias carpetas, pero solo para leerlas, no para escribir en ellas.

El bloque read_write representa las carpetas donde el agente sí tiene permiso de lectura y escritura. Ahí sí puede crear y guardar archivos.

Cómo comprobar que las políticas bloquean acciones no permitidas

Para probar las políticas en acción, le pedí al agente que escribiera un haiku sobre NVIDIA y lo guardara en la carpeta user, donde solo hay permiso de lectura [04:50].

Esto fue lo que pasó paso a paso:

1. Escribió el haiku y lo intentó guardar con el comando cat, que sirve para crear archivos y escribir dentro de ellos.
2. Trató de guardarlo en NVIDIA/NVIDIA_haiku.txt y recibió un error: no podía crear el archivo ahí.
3. Detectó que no tenía permisos de escritura en user e intentó escalar privilegios, pero falló de nuevo.
4. Finalmente me propuso guardarlo en el workspace, una carpeta con permiso read_write, y ahí lo guardó sin problema.

Así es como funcionan las políticas en la práctica. Si quieres una carpeta de solo lectura, se configura y el agente respetará ese límite.

Por qué estas políticas evitan que el agente alucine

Nuestro agente responde preguntas en función de las preguntas frecuentes. Pero imagina que le haces una pregunta que no puede responder.

Sin supervisión, podría alucinar la respuesta o, peor, modificar el archivo de preguntas frecuentes para inventar una respuesta y aparentar que cumple su objetivo. Las políticas bien configuradas fuerzan al agente a decir "no sé" o "no puedo" en lugar de falsear información.

Cómo usar el agente para mejorar su propia seguridad

Aquí viene lo interesante: puedes usar el mismo agente para reforzar su seguridad. Copié todo el resultado del comando de políticas y se lo llevé a mi agente de OpenClau [07:30].

Le di contexto completo: le expliqué que la información venía de la VM terminal corriendo con NeMo y OpenClau, y le pedí el comando para que ya no pudiera instalar paquetes de npm. El contexto es crítico, porque trabajamos con un modelo de pesos abiertos y entre más información reciba, más rápido ayuda.

Tras trabajar 31 segundos, respondió algo valioso: aclaró que eso no era configuración de OpenClau sino una política de sandbox de OpenShell. Nos explicó por qué se pueden instalar paquetes con npm, cuál es el cambio necesario, el comando exacto para ejecutarlo y qué limitación tendríamos después.

Antes de lanzar tu agente, define algo fundamental: ¿será de uso personal o estará expuesto al público? Esa decisión determina qué tan estrictas deben ser tus políticas. ¿Ya pensaste cómo configurarías las tuyas? Cuéntalo en los comentarios.