Uma ferramenta leve de sandboxing para aplicar restrições de sistema de arquivos e rede em processos arbitrários no nível do sistema operacional, sem exigir um contêiner.
Uma ferramenta de sandbox leve para impor restrições de sistema de arquivos e de rede a processos arbitrários no nível do sistema operacional, sem exigir um contêiner.
srt usa primitivas nativas de sandbox do sistema operacional (sandbox-exec no macOS, bubblewrap no Linux) e filtragem de rede baseada em proxy. Pode ser usado para colocar em sandbox o comportamento de agentes, servidores MCP locais, comandos bash e processos arbitrários.
Prévia de Pesquisa Beta
O Sandbox Runtime é uma prévia de pesquisa desenvolvida para o Claude Code para viabilizar agentes de IA mais seguros. Está sendo disponibilizado como uma prévia inicial de código aberto para ajudar o ecossistema mais amplo a construir sistemas agênticos mais seguros. Como esta é uma prévia inicial de pesquisa, as APIs e os formatos de configuração podem evoluir. Agradecemos feedback e contribuições para tornar os agentes de IA mais seguros por padrão!
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 pacote fornece uma implementação de sandbox autônoma que pode ser usada tanto como ferramenta CLI quanto como biblioteca. Ele foi projetado com uma filosofia segura por padrão adaptada aos casos de uso comuns de desenvolvedores: os processos iniciam com acesso mínimo, e você abre explicitamente apenas os buracos de que precisa.
Principais capacidades:
Um caso de uso importante é o sandboxing de servidores Model Context Protocol (MCP) para restringir suas capacidades. Por exemplo, para colocar o servidor MCP de sistema de arquivos em sandbox:
Sem sandboxing (.mcp.json):
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem"]
}
}
}
Com sandboxing (.mcp.json):
{
"mcpServers": {
"filesystem": {
"command": "srt",
"args": ["npx", "-y", "@modelcontextprotocol/server-filesystem"]
}
}
}
Em seguida, configure as restrições em ~/.srt-settings.json:
{
"filesystem": {
"denyRead": [],
"allowWrite": ["."],
"denyWrite": ["~/sensitive-folder"]
},
"network": {
"allowedDomains": [],
"deniedDomains": []
}
}
Agora o servidor MCP ficará bloqueado de escrever no caminho negado:
> Write a file to ~/sensitive-folder
✗ Error: EPERM: operation not permitted, open '/Users/ollie/sensitive-folder/test.txt'
O sandbox utiliza primitivas de nível de sistema operacional para impor restrições que se aplicam a toda a árvore de processos:
sandbox-exec com perfis Seatbelt gerados dinamicamentesrt-sandbox, com uma cerca de saída do Windows Filtering Platform vinculada ao SID dessa conta, um token com restrição de escrita e ACEs explícitas na árvore de trabalho0d1c612947c798aef48e6ab4beb7e8544da9d41a-4096x2305
Tanto o isolamento de sistema de arquivos quanto o de rede são necessários para um sandboxing eficaz. Sem isolamento de arquivos, um processo comprometido poderia exfiltrar chaves SSH ou outros arquivos sensíveis. Sem isolamento de rede, um processo poderia escapar do sandbox e obter acesso irrestrito à rede.
Isolamento de Sistema de Arquivos impõe restrições de leitura e escrita:
/Users) e então permitir novamente caminhos específicos dentro delas (por exemplo, .). allowRead tem precedência sobre denyRead — o oposto da escrita, onde denyWrite tem precedência sobre allowWrite. Uma entrada denyRead mais específica do que a região allowRead na qual ela se encontra (por exemplo, denyRead: ["**/.env"] ou ["./secrets"] com allowRead: ["."]) permanece negada.., /tmp). Uma lista de permissões vazia significa nenhum acesso de escrita.Isolamento de Rede (padrão apenas-permitir): Por padrão, todo o acesso à rede é negado. Você deve permitir domínios explicitamente. Uma lista allowedDomains vazia significa nenhum acesso à rede. O tráfego de rede é roteado através de servidores proxy em execução no host:
Linux: As requisições são roteadas via sistema de arquivos através de um socket de domínio Unix. O namespace de rede do processo em sandbox é removido completamente, então todo o tráfego de rede deve passar pelos proxies em execução no host (escutando em sockets Unix que são montados por bind no sandbox)
macOS: O perfil Seatbelt permite comunicação apenas para uma porta localhost específica. Os proxies escutam nessa porta, criando um canal controlado para todo o acesso à rede
Windows: Um conjunto de filtros WFP de âmbito de máquina bloqueia conexões de saída feitas por processos em execução como a conta srt-sandbox, exceto loopback para a faixa de portas do proxy. Os proxies escutam dentro dessa faixa, criando um canal controlado para todo o acesso à rede. Os filtros não acompanham um processo em sandbox que coloca um token diferente em uma thread antes de criar um socket, nem o tráfego que um serviço do sistema transporta em seu nome; consulte as Limitações conhecidas do Windows
Tanto HTTP/HTTPS (via proxy HTTP) quanto outro tráfego TCP (via proxy SOCKS5) são mediados por esses proxies, que impõem suas listas de permissões e negações de domínios.
Para mais detalhes sobre sandboxing no Claude Code, consulte: