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 sous forme d'aperçu open source précoce pour aider l'écosystème au sens large à construire des systèmes agentiques plus sécurisés. S'agissant d'un aperçu de recherche précoce, les API et les formats de configuration sont susceptibles d'évoluer. Nous accueillons favorablement les retours et les contributions pour rendre les agents IA plus sûrs par défaut !

Installation

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

Utilisation de base

# 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 bac à sable 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 clés :

Restrictions réseau : contrôlez quels hôtes/domaines sont accessibles 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, exploitez le magasin de journaux de violations du bac à sable du système pour des alertes en temps réel

Exemple de cas d'usage : 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 de système de fichiers :

Sans sandboxing (.mcp.json) :

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem"]
    }
  }
}

Avec sandboxing (.mcp.json) :

{
  "mcpServers": {
    "filesystem": {
      "command": "srt",
      "args": ["npx", "-y", "@modelcontextprotocol/server-filesystem"]
    }
  }
}

Puis configurez les restrictions dans ~/.srt-settings.json :

{
  "filesystem": {
    "denyRead": [],
    "allowWrite": ["."],
    "denyWrite": ["~/sensitive-folder"]
  },
  "network": {
    "allowedDomains": [],
    "deniedDomains": []
  }
}

Désormais, le serveur MCP sera bloqué lors de l'é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 bac à sable 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 de l'espace de noms réseau
Windows : exécute le processus isolé sous un compte utilisateur local dédié srt-sandbox, avec une clôture de sortie Windows Filtering Platform indexée sur le SID de ce compte, un jeton à écriture restreinte et des ACE explicites sur l'arborescence de travail

0d1c612947c798aef48e6ab4beb7e8544da9d41a-4096x2305

Modèle d'isolation double

L'isolation du système de fichiers et l'isolation réseau sont toutes deux nécessaires pour un bac à sable 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 bac à sable et obtenir un accès réseau non restreint.

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

Lecture (schéma refuser-puis-autoriser) : par défaut, l'accès en lecture est autorisé partout. Vous pouvez refuser de larges zones (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 (schéma 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 (schéma 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 par le biais d'un socket de domaine Unix. L'espace de noms réseau du processus isolé est entièrement supprimé, de sorte que tout le trafic réseau doit passer par les proxys s'exécutant sur l'hôte (à l'écoute sur des sockets Unix montés par bind dans le bac à sable)
macOS : le profil Seatbelt n'autorise la communication que vers un port localhost spécifique. Les proxys é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 les connexions sortantes effectuées par les processus s'exécutant sous le compte srt-sandbox, à l'exception du loopback vers la plage de ports proxy. Les proxys écoutent dans cette plage, créant un canal contrôlé pour tout accès réseau. Les filtres ne suivent pas un processus isolé qui place un jeton différent sur un thread avant de créer un socket, ni le trafic qu'un service système transporte en son nom ; voir les limitations connues de Windows

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

Pour plus de détails sur le bac à sable dans Claude Code, voir :

sandbox-runtime v0.0.66