anthropic-experimental/sandbox-runtimeUno strumento di sandboxing leggero per applicare restrizioni su filesystem e rete a processi arbitrari a livello di sistema operativo, senza richiedere un container.
Uno strumento di sandboxing leggero per applicare restrizioni sul filesystem e sulla rete a processi arbitrari a livello di sistema operativo, senza richiedere un container.
srt utilizza le primitive native di sandboxing del sistema operativo (sandbox-exec su macOS, bubblewrap su Linux) e il filtraggio di rete basato su proxy. Può essere usato per confinare in sandbox il comportamento di agenti, server MCP locali, comandi bash e processi arbitrari.
Anteprima di ricerca Beta
Il Sandbox Runtime è un'anteprima di ricerca sviluppata per Claude Code per consentire agenti AI più sicuri. Viene resa disponibile come anteprima open source iniziale per aiutare l'ecosistema più ampio a costruire sistemi agentici più sicuri. Trattandosi di un'anteprima di ricerca iniziale, le API e i formati di configurazione possono evolvere. Accogliamo con favore feedback e contributi per rendere gli agenti AI più sicuri per impostazione predefinita!
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
Questo pacchetto fornisce un'implementazione sandbox autonoma che può essere utilizzata sia come strumento CLI che come libreria. È progettata con una filosofia secure-by-default (sicura per impostazione predefinita) adattata ai casi d'uso comuni degli sviluppatori: i processi partono con accesso minimo e si aprono esplicitamente solo le eccezioni necessarie.
Funzionalità principali:
Un caso d'uso importante è il sandboxing dei server Model Context Protocol (MCP) per limitarne le capacità. Ad esempio, per applicare il sandboxing al server MCP del filesystem:
Senza sandboxing (.mcp.json):
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem"]
}
}
}
Con sandbox (.mcp.json):
{
"mcpServers": {
"filesystem": {
"command": "srt",
"args": ["npx", "-y", "@modelcontextprotocol/server-filesystem"]
}
}
}
Poi configura le restrizioni in ~/.srt-settings.json:
{
"filesystem": {
"denyRead": [],
"allowWrite": ["."],
"denyWrite": ["~/sensitive-folder"]
},
"network": {
"allowedDomains": [],
"deniedDomains": []
}
}
Ora il server MCP sarà bloccato dalla scrittura nel percorso negato:
> Write a file to ~/sensitive-folder
✗ Error: EPERM: operation not permitted, open '/Users/ollie/sensitive-folder/test.txt'
La sandbox utilizza primitive a livello di sistema operativo per applicare restrizioni che si estendono all'intero albero dei processi:
sandbox-exec con profili Seatbelt generati dinamicamentesrt-sandbox, con una barriera in uscita basata su Windows Filtering Platform associata al SID di tale account, un token con restrizioni di scrittura e ACE espliciti sull'albero di lavoro0d1c612947c798aef48e6ab4beb7e8544da9d41a-4096x2305
Sia l'isolamento del filesystem che quello della rete sono necessari per una sandbox efficace. Senza l'isolamento dei file, un processo compromesso potrebbe esfiltrare chiavi SSH o altri file sensibili. Senza l'isolamento della rete, un processo potrebbe sfuggire alla sandbox e ottenere accesso di rete senza restrizioni.
Isolamento del filesystem applica restrizioni di lettura e scrittura:
/Users) e poi ri-consentire percorsi specifici al loro interno (ad es. .). allowRead ha la precedenza su denyRead — l'opposto della scrittura, dove denyWrite ha la precedenza su allowWrite. Una voce denyRead più specifica della regione allowRead in cui ricade (ad es. denyRead: ["**/.env"] o ["./secrets"] con allowRead: ["."]) rimane comunque negata.., /tmp). Una lista di autorizzazioni vuota significa nessun accesso in scrittura.Isolamento della rete (schema solo-consenti): per impostazione predefinita, tutto l'accesso alla rete è negato. È necessario consentire esplicitamente i domini. Una lista allowedDomains vuota significa nessun accesso alla rete. Il traffico di rete viene instradato attraverso server proxy in esecuzione sull'host:
Linux: le richieste vengono instradate tramite il filesystem su un socket di dominio Unix. Lo spazio dei nomi di rete del processo in sandbox viene rimosso completamente, quindi tutto il traffico di rete deve passare attraverso i proxy in esecuzione sull'host (in ascolto su socket Unix montati tramite bind nella sandbox)
macOS: il profilo Seatbelt consente la comunicazione solo verso una porta specifica di localhost. I proxy sono in ascolto su questa porta, creando un canale controllato per tutto l'accesso alla rete
Windows: un insieme di filtri WFP a livello di macchina blocca le connessioni in uscita effettuate da processi in esecuzione con l'account srt-sandbox, eccetto il loopback verso l'intervallo di porte del proxy. I proxy sono in ascolto all'interno di tale intervallo, creando un canale controllato per tutto l'accesso alla rete. I filtri non seguono un processo in sandbox che applica un token diverso a un thread prima di creare un socket, né il traffico che un servizio di sistema trasporta per suo conto; vedere le limitazioni note di Windows
Sia il traffico HTTP/HTTPS (tramite proxy HTTP) che altro traffico TCP (tramite proxy SOCKS5) sono mediati da questi proxy, che applicano le liste di domini consentiti e negati.
Per maggiori dettagli sul sandboxing in Claude Code, vedere: