anthropic-experimental/sandbox-runtimeUna herramienta de sandboxing ligera para aplicar restricciones de sistema de archivos y red en procesos arbitrarios a nivel del sistema operativo, sin necesidad de un contenedor.
Una herramienta de sandboxing ligera para aplicar restricciones de sistema de archivos y de red a procesos arbitrarios a nivel del sistema operativo, sin necesidad de un contenedor.
srt utiliza primitivas nativas de sandboxing del sistema operativo (sandbox-exec en macOS, bubblewrap en Linux) y filtrado de red basado en proxy. Puede usarse para aplicar sandboxing al comportamiento de agentes, servidores MCP locales, comandos bash y procesos arbitrarios.
Vista previa de investigación Beta
El Sandbox Runtime es una vista previa de investigación desarrollada para Claude Code con el fin de permitir agentes de IA más seguros. Se pone a disposición como una vista previa temprana de código abierto para ayudar al ecosistema en general a construir sistemas agénticos más seguros. Dado que se trata de una vista previa de investigación temprana, las APIs y los formatos de configuración pueden evolucionar. ¡Agradecemos los comentarios y las contribuciones para hacer que los agentes de IA sean más seguros por defecto!
npm install -g @anthropic-ai/sandbox-runtime
# Network restrictions
$ srt "curl anthropic.com"
Running: curl anthropic.com
<html>...</html> # Request succeeds
$ srt "curl example.com"
Running: curl example.com
Connection blocked by network allowlist # Request blocked
# Filesystem restrictions
$ srt "cat README.md"
Running: cat README.md
# Anthropic Sandb... # Current directory access allowed
$ srt "cat ~/.ssh/id_rsa"
Running: cat ~/.ssh/id_rsa
cat: /Users/ollie/.ssh/id_rsa: Operation not permitted # Specific file blocked
Este paquete proporciona una implementación de sandbox autónoma que puede utilizarse tanto como herramienta CLI como biblioteca. Está diseñado con una filosofía segura por defecto adaptada a los casos de uso habituales de los desarrolladores: los procesos se inician con acceso mínimo y solo se abren explícitamente los huecos que se necesitan.
Capacidades clave:
Un caso de uso clave es el sandboxing de servidores del Model Context Protocol (MCP) para restringir sus capacidades. Por ejemplo, para aplicar sandbox al servidor MCP de sistema de archivos:
Sin sandboxing (.mcp.json):
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem"]
}
}
}
Con sandboxing (.mcp.json):
{
"mcpServers": {
"filesystem": {
"command": "srt",
"args": ["npx", "-y", "@modelcontextprotocol/server-filesystem"]
}
}
}
Luego configure las restricciones en ~/.srt-settings.json:
{
"filesystem": {
"denyRead": [],
"allowWrite": ["."],
"denyWrite": ["~/sensitive-folder"]
},
"network": {
"allowedDomains": [],
"deniedDomains": []
}
}
Ahora el servidor MCP tendrá bloqueada la escritura en la ruta denegada:
> Write a file to ~/sensitive-folder
✗ Error: EPERM: operation not permitted, open '/Users/ollie/sensitive-folder/test.txt'
El sandbox utiliza primitivas a nivel de sistema operativo para aplicar restricciones que se aplican a todo el árbol de procesos:
sandbox-exec con perfiles Seatbelt generados dinámicamentesrt-sandbox, con una barrera de salida de Windows Filtering Platform vinculada al SID de esa cuenta, un token con restricción de escritura y ACEs explícitas en el árbol de trabajo0d1c612947c798aef48e6ab4beb7e8544da9d41a-4096x2305
Tanto el aislamiento del sistema de archivos como el de red son necesarios para un sandboxing eficaz. 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 de red sin restricciones.
Aislamiento del sistema de archivos aplica restricciones de lectura y escritura:
/Users) y luego volver a permitir rutas específicas dentro de ellas (p. ej., .). allowRead tiene precedencia sobre denyRead — lo contrario de la escritura, donde denyWrite tiene precedencia sobre allowWrite. Una entrada denyRead que sea más específica que la región allowRead en la que se encuentra (p. ej. denyRead: ["**/.env"] o ["./secrets"] con allowRead: ["."]) sigue permaneciendo denegada.., /tmp). Una lista de permisos vacía significa que no hay acceso de escritura.Aislamiento de red (patrón solo-permitir): de forma predeterminada, todo el acceso de red está denegado. Debe permitir dominios explícitamente. Una lista allowedDomains vacía significa que no hay acceso de red. El tráfico de red se enruta a través de servidores proxy que se ejecutan en el host:
Linux: las solicitudes se enrutan a través del sistema de archivos mediante un socket de dominio Unix. El espacio de nombres de red del proceso en sandbox se elimina por completo, por lo que todo el tráfico de red debe pasar por los proxies que se ejecutan en el host (escuchando en sockets Unix que se montan mediante bind dentro del sandbox)
macOS: el perfil Seatbelt permite la comunicación solo a un puerto localhost específico. Los proxies escuchan en este puerto, creando un canal controlado para todo el acceso de red
Windows: un conjunto de filtros WFP para toda la máquina bloquea las conexiones salientes realizadas por procesos que se ejecutan como la cuenta srt-sandbox, excepto el loopback al rango de puertos del proxy. Los proxies escuchan dentro de ese rango, creando un canal controlado para todo el acceso de red. Los filtros no siguen a un proceso en sandbox que coloque un token diferente en un hilo antes de crear un socket, ni al tráfico que un servicio del sistema transporta en su nombre; consulte las limitaciones conocidas de Windows
Tanto el tráfico HTTP/HTTPS (a través del proxy HTTP) como el resto del tráfico TCP (a través del proxy SOCKS5) son mediados por estos proxies, que aplican sus listas de dominios permitidos y denegados.
Para obtener más detalles sobre el sandboxing en Claude Code, consulte: