AI Sandbox: dándole a Claude un contenedor seguro para depurar tus aplicaciones

Hay un problema fundamental con la asistencia DevOps por IA: la IA no puede tocar nada. Puede leer tus logs. Puede verificar tus métricas. Puede decirte "la aplicación probablemente se está cayendo por una variable de entorno faltante." Pero no puede verificar realmente esa hipótesis. No puede hacer curl al endpoint de salud de tu aplicación. No puede inspeccionar el sistema de archivos dentro de tu contenedor. No puede ejecutar npm ls para verificar conflictos de dependencias.

Decidimos arreglar eso. El 25 de marzo de 2026, construimos la Fase 5 del servidor MCP: un contenedor sandbox de IA que da a Claude acceso root a un entorno Linux real, conectado a la red de tu aplicación, con herramientas de depuración preinstaladas. No una simulación. No una vista de solo lectura. Un contenedor Alpine escribible donde Claude puede instalar paquetes, clonar repositorios, compilar código y ejecutar comandos -- con las suficientes barreras de protección para prevenir que destruya el host.

La decisión de diseño: Acceso completo, lista de bloqueo mínima

Elegimos una filosofía de lista de bloqueo mínima en lugar de una lista de permitidos. El sandbox bloquea exactamente cuatro categorías de comandos: rm -rf /, mkfs, shutdown/reboot y fork bombs. Todo lo demás está permitido.

Cada sandbox es un contenedor Alpine 3.19 con: 1 GB de memoria, 2 núcleos CPU, usuario root, timeout de 5 minutos por comando, límite de salida de 100 KB y modo de red container:{app_id} que comparte localhost con el contenedor de la aplicación.

Los paquetes preinstalados cubren los escenarios de depuración más comunes: curl, wget, bind-tools, netcat, jq, git, nodejs, npm, python3, pip, bash.

Las cinco herramientas MCP

La Fase 5 añadió cinco herramientas al servidor MCP:

• sandbox_exec_command (riesgo escritura) -- Ejecuta cualquier comando shell dentro del contenedor sandbox
• sandbox_read_file (riesgo lectura) -- Lee un archivo del sandbox o de los volúmenes montados de la aplicación
• sandbox_list_processes (riesgo lectura) -- Ejecuta ps aux dentro del contenedor de la aplicación
• sandbox_check_connectivity (riesgo lectura) -- Prueba conectividad de red desde el sandbox
• sandbox_status (riesgo lectura) -- Inspecciona el contenedor sandbox mismo

Hooks de ciclo de vida

Los sandboxes se gestionan automáticamente a través de hooks de ciclo de vida de la aplicación. La función ensure_sandbox es idempotente -- si el sandbox ya existe y está ejecutándose, retorna inmediatamente. Si existe pero está detenido, lo reinicia. Si no existe, lo crea.

Por qué esto importa: Depurar haciendo, no adivinando

Sin un sandbox, una sesión de depuración con IA se ve así:

Usuario: Mi aplicación Node está devolviendo errores 502. Claude: Basándome en los logs de despliegue, la aplicación inició exitosamente. El 502 podría ser causado por: (1) la aplicación escuchando en el puerto incorrecto, (2) un timeout de health check, (3) un problema de dependencias. ¿Podrías verificar package.json?

Con un sandbox:

Usuario: Mi aplicación Node está devolviendo errores 502. Claude: Déjame verificar. [llama get_app_details] La aplicación está configurada en el puerto 3000. [llama sandbox_exec_command: curl -v http://localhost:3000/] La conexión fue rechazada -- nada escucha en el puerto 3000. [llama sandbox_exec_command: curl -v http://localhost:8080/] El puerto 8080 devuelve un 200. Tu aplicación está escuchando en 8080 pero sh0 está enrutando al 3000. Actualiza el puerto en tu sh0.yaml o establece la variable de entorno PORT en 3000.

La diferencia es la diferencia entre una sugerencia y un diagnóstico. El sandbox convierte a Claude de un adivinador bien informado en un depurador real que puede reproducir y verificar problemas.

Consideraciones de seguridad

Dar acceso root a una IA en un contenedor suena alarmante. He aquí por qué es seguro:

1. Aislamiento: El sandbox es un contenedor separado. Comparte el namespace de red de la aplicación pero no su sistema de archivos, procesos o memoria.
2. Límites de recursos: 1 GB de RAM y 2 núcleos CPU.
3. Sin acceso al host: Sin capacidades privilegiadas, sin montajes del host, sin acceso al socket Docker.
4. Validación de comandos: La lista de bloqueo previene comandos que podrían dañar el sistema de archivos del contenedor.
5. Timeout: Límite de ejecución de 5 minutos por comando.
6. Límite de salida: Tope de 100 KB.
7. Imposición de alcance: La herramienta sandbox_exec_command está clasificada como riesgo write.

La posición filosófica es simple: el sandbox es menos peligroso que el acceso SSH, y ya damos a los usuarios acceso SSH a través del terminal del dashboard.

Siguiente en la serie: De cargo build a un servidor en vivo: el pipeline de release -- compilaciones Docker multi-etapa, batallas de compilación cruzada y el primer despliegue a producción en demo.sh0.app.