Anthropic Sandbox Runtime (srt)

Un outil de sandboxing léger pour appliquer des restrictions de système de fichiers et de réseau à des processus arbitraires au niveau du système d'exploitation, sans nécessiter de conteneur.

srt utilise les primitives natives de sandboxing du système d'exploitation (sandbox-exec sur macOS, bubblewrap sur Linux) et un filtrage réseau basé sur un proxy. Il peut être utilisé pour sandboxer le comportement d'agents, de serveurs MCP locaux, de commandes bash et de processus arbitraires.

Aperçu de recherche bêta

Le Sandbox Runtime est un aperçu de recherche développé pour Claude Code afin de permettre des agents IA plus sûrs. Il est mis à disposition en tant qu'aperçu open source précoce pour aider l'écosystème au sens large à construire des systèmes agentiques plus sécurisés. Comme il s'agit d'un aperçu de recherche précoce, les API et les formats de configuration peuvent évoluer. Nous accueillons favorablement les retours et les contributions pour rendre les agents IA plus sûrs par défaut !

Installation```bash

npm install -g @anthropic-ai/sandbox-runtime

## Utilisation de base```bash
# 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

Aperçu

Ce paquet fournit une implémentation de sandbox autonome qui peut être utilisée à la fois comme outil CLI et comme bibliothèque. Il est conçu selon une philosophie sécurisée par défaut adaptée aux cas d'usage courants des développeurs : les processus démarrent avec un accès minimal, et vous n'ouvrez explicitement que les brèches dont vous avez besoin.

Capacités principales :

Restrictions réseau : contrôlez quels hôtes/domaines peuvent être accédés via HTTP/HTTPS et d'autres protocoles
Restrictions du système de fichiers : contrôlez quels fichiers/répertoires peuvent être lus/écrits
Restrictions des sockets Unix : contrôlez l'accès aux sockets IPC locaux
Surveillance des violations : sur macOS, accédez au magasin de journaux de violations du sandbox du système pour des alertes en temps réel

Cas d'usage exemple : sandboxer les serveurs MCP

Un cas d'usage clé consiste à sandboxer les serveurs Model Context Protocol (MCP) afin de restreindre leurs capacités. Par exemple, pour sandboxer le serveur MCP du système de fichiers :

Sans sandboxing (.mcp.json) :```json { "mcpServers": { "filesystem": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem"] } } }

**Avec sandboxing** (`.mcp.json`) :```json
{
  "mcpServers": {
    "filesystem": {
      "command": "srt",
      "args": ["npx", "-y", "@modelcontextprotocol/server-filesystem"]
    }
  }
}

Ensuite, configurez les restrictions dans ~/.srt-settings.json :```json { "filesystem": { "denyRead": [], "allowWrite": ["."], "denyWrite": ["~/sensitive-folder"] }, "network": { "allowedDomains": [], "deniedDomains": [] } }

Désormais, le serveur MCP sera bloqué en écriture vers le chemin refusé :```
> Write a file to ~/sensitive-folder
✗ Error: EPERM: operation not permitted, open '/Users/ollie/sensitive-folder/test.txt'

Fonctionnement

Le sandbox utilise des primitives au niveau du système d'exploitation pour appliquer des restrictions qui s'appliquent à l'ensemble de l'arborescence des processus :

macOS : Utilise sandbox-exec avec des profils Seatbelt générés dynamiquement
Linux : Utilise bubblewrap pour la conteneurisation avec isolation du namespace réseau
Windows : Exécute le processus sandboxé sous un compte utilisateur local dédié srt-sandbox, avec une clôture de sortie Windows Filtering Platform basée sur le SID de ce compte et des ACE explicites par session sur l'arborescence de travail

0d1c612947c798aef48e6ab4beb7e8544da9d41a-4096x2305

Modèle d'isolation double

L'isolation du système de fichiers et du réseau sont toutes deux nécessaires pour un sandboxing efficace. Sans isolation des fichiers, un processus compromis pourrait exfiltrer des clés SSH ou d'autres fichiers sensibles. Sans isolation réseau, un processus pourrait s'échapper du sandbox et obtenir un accès réseau non restreint.

Isolation du système de fichiers applique des restrictions de lecture et d'écriture :

Lecture (modèle refuser-puis-autoriser) : Par défaut, l'accès en lecture est autorisé partout. Vous pouvez refuser de larges régions (par exemple, /Users) puis réautoriser des chemins spécifiques à l'intérieur de celles-ci (par exemple, .). allowRead a la priorité sur denyRead — l'inverse de l'écriture, où denyWrite a la priorité sur allowWrite. Une entrée denyRead plus spécifique que la région allowRead dans laquelle elle se trouve (par exemple denyRead: ["**/.env"] ou ["./secrets"] avec allowRead: ["."]) reste refusée.
Écriture (modèle autoriser-uniquement) : Par défaut, l'accès en écriture est refusé partout. Vous devez explicitement autoriser des chemins (par exemple, ., /tmp). Une liste d'autorisation vide signifie aucun accès en écriture.

Isolation réseau (modèle autoriser-uniquement) : Par défaut, tout accès réseau est refusé. Vous devez explicitement autoriser des domaines. Une liste allowedDomains vide signifie aucun accès réseau. Le trafic réseau est acheminé via des serveurs proxy s'exécutant sur l'hôte :

Linux : Les requêtes sont acheminées via le système de fichiers sur un socket de domaine Unix. Le namespace réseau du processus sandboxé est entièrement supprimé, donc tout le trafic réseau doit passer par les proxies s'exécutant sur l'hôte (écoutant sur des sockets Unix qui sont montés par liaison dans le sandbox)
macOS : Le profil Seatbelt autorise la communication uniquement vers un port localhost spécifique. Les proxies écoutent sur ce port, créant un canal contrôlé pour tout accès réseau
Windows : Un ensemble de filtres WFP à l'échelle de la machine bloque toutes les connexions sortantes provenant du compte srt-sandbox sauf le loopback vers la plage de ports proxy. Les proxies écoutent dans cette plage, créant un canal contrôlé pour tout accès réseau

Tant le trafic HTTP/HTTPS (via proxy HTTP) que les autres trafics TCP (via proxy SOCKS5) sont médiés par ces proxies, qui appliquent vos listes d'autorisation et de refus de domaines.

Pour plus de détails sur le sandboxing dans Claude Code, voir :

sandbox-runtime v0.0.68