sandbox-runtime (srt) de Anthropic: cómo funciona y cómo reforzarlo

Tu agente de IA puede ejecutar comandos de shell, instalar paquetes y acceder a la red en tu nombre. Entonces, ¿qué impide que un agente comprometido o víctima de inyección de prompts lea tus claves SSH y las envíe por POST al servidor de un atacante? En octubre de 2026, Anthropic publicó como código abierto la herramienta que creó justo para esa pregunta: sandbox-runtime, con el nombre de CLI srt. Este artículo explica qué es, cómo funciona, dónde es honesta sobre sus propios límites y termina con un checklist de refuerzo concreto que puedes aplicar hoy.

Qué es srt

srt es, en palabras de su propio README, «una herramienta de sandboxing ligera para imponer restricciones de sistema de archivos y de red a procesos arbitrarios a nivel del sistema operativo, sin necesidad de un contenedor». Anthropic la describe como «una versión preliminar de investigación desarrollada para Claude Code con el fin de hacer más seguros los agentes de IA». La documentación de Claude Code confirma la relación de forma literal: «Claude Code construye el sandbox sobre el paquete de código abierto @anthropic-ai/sandbox-runtime».

• Paquete: @anthropic-ai/sandbox-runtime en npm; CLI: srt.
• Instalación: npm install -g @anthropic-ai/sandbox-runtime. En Linux también necesita bubblewrap y socat; ripgrep se usa para detectar las rutas denegadas.
• Licencia: Apache-2.0.
• Estado: Beta Research Preview («las API y los formatos de configuración pueden cambiar»); en Windows es alfa.

No se limita a Claude Code. El README dice que «puede usarse para aislar el comportamiento de agentes, servidores MCP locales, comandos bash y procesos arbitrarios». El uso es simplemente srt <comando> —por ejemplo srt npm install o srt --debug curl https://example.com— y hay una API de librería (SandboxManager.initialize() y luego wrapWithSandbox()). Lo crucial es que las restricciones «cubren cualquier script, programa o subproceso que lance el comando», así que los procesos hijos heredan el sandbox.

Fuentes primarias, todas recomendables: el repositorio de sandbox-runtime en GitHub, el blog de ingeniería de Anthropic sobre el sandboxing de Claude Code y la documentación de sandboxing de Claude Code.

Cómo funciona

srt se apoya en primitivas nativas del sistema operativo en lugar de en una máquina virtual. El README: «usa primitivas de sandboxing nativas del sistema operativo (sandbox-exec en macOS, bubblewrap en Linux) y filtrado de red basado en proxies».

Plataforma	Mecanismo
macOS	sandbox-exec con perfiles Seatbelt generados dinámicamente; el perfil solo permite la comunicación con un puerto proxy concreto de localhost.
Linux	bubblewrap con aislamiento por network namespace. El network namespace del proceso aislado se elimina por completo, así que todo el tráfico debe pasar por proxies del lado del host a los que se llega mediante sockets Unix montados dentro del sandbox. El bloqueo de sockets Unix usa filtros seccomp (solo x86-64/arm64).
Windows	Alfa. Una cuenta de usuario local dedicada srt-sandbox, una barrera de salida de Windows Filtering Platform ligada al SID de esa cuenta, un token con escritura restringida y ACL sobre el árbol de trabajo. Con más huecos que macOS/Linux: consulta Limitaciones.

Red: denegada por defecto y controlada fuera del sandbox

El README es directo: «Por defecto, todo el acceso a la red está denegado. Debes permitir dominios de forma explícita». El control no vive dentro del sandbox, sino en dos proxies que se ejecutan en el host: un proxy HTTP para HTTP/HTTPS y un proxy SOCKS5 para el resto de TCP. Una conexión se evalúa en orden: si coincide con deniedDomains, se deniega; si no, si coincide con allowedDomains, se permite; si no, con strictAllowlist, se deniega; si no, se consulta una lista por comando; y si no, decide un callback de «preguntar» (sin callback, se deniega). En Claude Code, ese «preguntar» es el aviso de permiso.

También hay una red de seguridad sobre las direcciones resueltas: los nombres de host permitidos se resuelven y cualquier dirección de un conjunto denegado —loopback, link-local, multicast, endpoints de metadatos de la nube (169.254.169.254) y las direcciones de las propias interfaces del host— se descarta. Es una protección integrada contra SSRF y contra la exfiltración de metadatos.

Sistema de archivos: escrituras cerradas, lecturas abiertas

Es lo más importante que hay que asimilar. Sin archivo de configuración, la postura por defecto es «sin acceso a la red, sin escrituras fuera de las rutas de escritura predeterminadas y lecturas sin restricciones». Las reglas de precedencia:

• Lecturas: denegar y luego permitir, abiertas por defecto. «Por defecto, la lectura está permitida en todas partes». allowRead tiene prioridad sobre denyRead.
• Escrituras: solo permitir, cerradas por defecto. denyWrite tiene prioridad sobre allowWrite.
• Red: solo permitir, cerrada por defecto.

La política vive en un archivo de configuración JSON (~/.srt-settings.json por defecto, o --settings <ruta>) con los subobjetos network y filesystem:

{
  "network": {
    "allowedDomains": ["github.com", "*.github.com", "npmjs.org", "*.npmjs.org"],
    "deniedDomains": ["malicious.com"],
    "allowUnixSockets": ["/var/run/docker.sock"],
    "allowLocalBinding": false
  },
  "filesystem": {
    "denyRead": ["~/.ssh"],
    "allowRead": [],
    "allowWrite": [".", "src/", "test/", "/tmp"],
    "denyWrite": [".env", "config/production.json"]
  }
}

Un comportamiento realmente bueno que merece mención: un archivo de configuración que existe pero no pasa la validación es un error fatal. srt termina en lugar de volver en silencio a los valores por defecto: falla de forma cerrada, que es lo que quieres.

El equilibrio entre seguridad y usabilidad

Anthropic presenta el sandboxing como una forma de reducir la «fatiga de aprobación», la erosión de la seguridad que ocurre cuando una persona pulsa «aprobar» en cada aviso sin leerlo. El blog de ingeniería afirma que el sandboxing «reduce de forma segura los avisos de permiso en un 84 %» en el uso interno. Trátalo como una cifra interna reportada por Anthropic, del blog de ingeniería; no la hemos verificado de forma independiente y no la encontramos en la parte de la documentación pública que revisamos.

La tensión va en los dos sentidos. Demasiado estricto, y los flujos reales se rompen; el README documenta varios casos: errores de permisos de Jest/Watchman (srt "jest --no-watchman"); Chromium/Electron, podman sin root y bubblewrap anidado que fallan con EPERM salvo con allowNestedUserNamespaces: true (que, advierte el README, debilita las garantías); herramientas de Go que necesitan enableWeakerNetworkIsolation para verificar TLS frente al proxy MITM; y Ubuntu 24.04+ que necesita un ajuste de AppArmor. Demasiado laxo, y el sandbox deja de significar algo: cada interruptor de excepción sacrifica una garantía (más abajo). La declaración de diseño central de Anthropic explica por qué ambas dimensiones son obligatorias: «Sin aislamiento de archivos, un proceso comprometido podría exfiltrar claves SSH u otros archivos sensibles. Sin aislamiento de red, un proceso podría escapar del sandbox y obtener acceso ilimitado a la red».

Las limitaciones honestas

Hay que reconocerle a Anthropic que el README documenta lo que srt no protege. Tenlo siempre presente: ahí es donde muerde el exceso de confianza.

• No es una VM ni una frontera de aislamiento completa. La documentación lo dice abiertamente. Un exploit a nivel de kernel queda fuera de su alcance.
• Las lecturas están abiertas por defecto. Tienes que escribir a mano las listas de denegación para los secretos. Olvidarlo es la mala configuración más probable en la práctica.
• Filtrado de dominios ciego al contenido. El proxy «no inspecciona el tráfico de ninguna otra forma»: «permitir github.com deja que un proceso haga push a cualquier repositorio», y en algunos casos el filtrado «puede ... saltarse mediante domain fronting».
• Los sockets Unix son agujeros para tomar el host. Permitir /var/run/docker.sock «concedería en la práctica acceso al sistema host». En Linux sin seccomp, los sockets Unix no tienen restricción (solo una advertencia).
• Un $PATH con escritura es una escalada a ejecución de código. Permitir escrituras en directorios del $PATH, en la configuración del sistema o en los archivos rc de la shell «puede llevar a la ejecución de código en otros contextos de seguridad». Y una copia de srt en un <proyecto>/node_modules/ con escritura «puede reescribirla un comando aislado, y el siguiente srt que se ejecute ahí ejecutará el resultado sin sandbox».
• Los interruptores de debilitamiento eliminan garantías. enableWeakerNetworkIsolation es un «posible vector de exfiltración de datos a través del servicio trustd»; allowAppleEvents significa que «el sandbox deja de ofrecer aislamiento de ejecución de código»; allowNestedUserNamespaces significa que las denegaciones obligatorias «dejan de cumplirse»; enableWeakerNestedSandbox «debilita considerablemente la seguridad».
• Omisión del proxy en Linux. El enrutamiento se basa en HTTP_PROXY/HTTPS_PROXY/ALL_PROXY, que «pueden ignorar los programas que no respetan estas variables». (La aplicación obligatoria por network namespace es aquí la palanca más fuerte.)
• Atribución, no una frontera, entre comandos simultáneos. Un proceso aislado que presenta el id de otra invocación activa obtiene los permisos de esa invocación: «esto es atribución, no una frontera entre comandos simultáneos de una misma sesión».
• Sin auditoría estructurada en Linux. macOS puede leer el log de violaciones del sandbox (log stream --predicate 'process == "sandbox-exec"'); en Linux, bubblewrap no tiene informes de violaciones integrados y tienes que añadir strace (strace -f srt <cmd> 2>&1 | grep EPERM).

Cuando deniega algo, srt hace tres cosas: bloquea la operación a nivel del sistema operativo (devuelve EPERM), registra la violación con mecanismos propios de cada plataforma y avisa al usuario (un aviso de permiso en Claude Code).

Checklist de refuerzo: 13 controles concretos

Cada punto corresponde a un mecanismo real de srt. Esta es la lista de «cómo mantenerlo seguro».

1. Denegar por defecto siempre que puedas. Las escrituras y la red ya están cerradas: mantenlas al mínimo. Nunca amplíes a allowWrite: ["/"] ni a un dominio general.
2. Corrige primero el hueco de las lecturas por defecto. Las lecturas están ABIERTAS por defecto. Añade denyRead explícito para los almacenes de secretos: ~/.ssh, ~/.aws, ~/.config, .env, .npmrc, credenciales de la nube, claves SSH/GPG, perfiles de navegador. Es el paso manual más importante.
3. Sistema de archivos con mínimo privilegio. allowWrite solo para el árbol del proyecto y un directorio temporal (/tmp). Nunca permitas escrituras en directorios del $PATH, en la configuración del sistema ni en los archivos rc de la shell: es una vía de escalada a ejecución de código. Instala srt de forma global, no en un node_modules/ del proyecto con escritura.
4. Disciplina en la lista de dominios permitidos. Permite dominios exactos (registry.npmjs.org, github.com, el host de tu API), no comodines amplios. Recuerda que el permiso es grueso: github.com permite hacer push a cualquier repositorio. Para controlar rutas o métodos, usa un conjunto de reglas de proxy personalizado.
5. Protege contra SSRF y los endpoints de metadatos. Apóyate en (y verifica) la lista de direcciones resueltas denegadas, que descarta loopback, link-local, multicast y metadatos de la nube (169.254.169.254). Nunca permitas un dominio que resuelva a rangos internos.
6. Trata los sockets Unix como concesiones de privilegio. Nunca uses allowUnixSockets para docker.sock (= tomar el host) salvo que lo aceptes del todo. En Linux, confirma que seccomp está activo (x86-64/arm64) para que los sockets se filtren de verdad; una advertencia de seccomp no disponible significa que NO se filtran.
7. No actives los interruptores de debilitamiento por reflejo. enableWeakerNetworkIsolation, allowAppleEvents, enableWeakerNestedSandbox, allowAllUnixSockets y allowNestedUserNamespaces eliminan cada uno una garantía. Úsalos solo con una razón documentada y un aislamiento compensatorio.
8. Falla de forma cerrada y valida la configuración. Apóyate en que srt termina ante un archivo de configuración no válido; mantén la política en control de versiones y valídala en CI. Nada de volver en silencio a los valores por defecto.
9. Audita las denegaciones. Envía las violaciones de strace o de log stream a un lugar duradero (SigNoz, syslog) para que una avalancha de EPERM sea visible y no solo un aviso pasajero. Revisa a qué intentó llegar el agente.
10. Defensa en profundidad: no lo trates como una VM. Para código no confiable o hosts de alto valor, ejecuta srt dentro de un contenedor o una microVM. El confinamiento con primitivas del sistema operativo no sobrevive a un exploit del kernel.
11. Revisa el alcance en Claude Code específicamente. El sandbox de Bash integrado solo cubre los comandos de shell; las herramientas de archivos, los hooks y los servidores MCP locales se ejecutan con acceso completo. Para tener una sola frontera, ejecuta todo el proceso de Claude Code bajo srt (o en un contenedor o VM).
12. Fija y revisa la política por proyecto. Cada repositorio necesita su propia lista de permitidos; un único ~/.srt-settings.json global acaba siendo demasiado amplio. Prefiere --settings por proyecto.
13. Ojo con la omisión del proxy en Linux. Los programas que no respetan las variables de entorno pueden ignorar el proxy. Prefiere la aplicación obligatoria por network namespace y vigila las herramientas que abren sockets en bruto.

En resumen

srt es un valor por defecto bienvenido y bien documentado: una forma de bajo coste de poner fronteras de sistema de archivos y de red alrededor de un agente sin levantar un contenedor para cada comando, y la única herramienta local ligera de su tipo que trae de serie una lista de dominios permitidos con denegación por defecto. Pero su propia documentación deja claro que es confinamiento, no contención. Trátalo como la capa interior: corrige las lecturas abiertas por defecto, mantén las listas de permitidos ajustadas, audita las denegaciones y colócalo dentro de un aislamiento más fuerte cuando el código sea realmente no confiable. Para ver cómo se compara srt con bubblewrap, Firejail, Docker, gVisor, Firecracker y los servicios de sandbox en la nube, consulta nuestra comparativa de sandboxes para agentes.