Anthropic Sandbox Runtime (srt)

Ein leichtgewichtiges Sandboxing-Tool zur Durchsetzung von Dateisystem- und Netzwerkbeschränkungen für beliebige Prozesse auf Betriebssystemebene, ohne dass ein Container erforderlich ist.

srt verwendet native Sandboxing-Primitive des Betriebssystems (sandbox-exec unter macOS, bubblewrap unter Linux) und proxybasierte Netzwerkfilterung. Es kann verwendet werden, um das Verhalten von Agenten, lokalen MCP-Servern, Bash-Befehlen und beliebigen Prozessen in einer Sandbox zu isolieren.

Beta Research Preview

Die Sandbox Runtime ist eine Research Preview, die für Claude Code entwickelt wurde, um sicherere KI-Agenten zu ermöglichen. Sie wird als frühe Open-Source-Vorschau bereitgestellt, um dem breiteren Ökosystem zu helfen, sicherere agentische Systeme zu entwickeln. Da es sich um eine frühe Research Preview handelt, können sich APIs und Konfigurationsformate weiterentwickeln. Wir freuen uns über Feedback und Beiträge, um KI-Agenten standardmäßig sicherer zu machen!

Installation

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

Grundlegende Verwendung

# 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

Überblick

Dieses Paket bietet eine eigenständige Sandbox-Implementierung, die sowohl als CLI-Tool als auch als Bibliothek verwendet werden kann. Es ist mit einer Secure-by-Default-Philosophie konzipiert, die auf gängige Entwickler-Anwendungsfälle zugeschnitten ist: Prozesse starten mit minimalem Zugriff, und Sie öffnen explizit nur die Lücken, die Sie benötigen.

Wichtige Funktionen:

Netzwerkbeschränkungen: Steuern Sie, auf welche Hosts/Domains über HTTP/HTTPS und andere Protokolle zugegriffen werden kann
Dateisystembeschränkungen: Steuern Sie, welche Dateien/Verzeichnisse gelesen/geschrieben werden können
Unix-Socket-Beschränkungen: Steuern Sie den Zugriff auf lokale IPC-Sockets
Verletzungsüberwachung: Greifen Sie unter macOS auf den Sandbox-Verletzungsprotokollspeicher des Systems zu, um Echtzeitwarnungen zu erhalten

Beispielanwendungsfall: Sandboxing von MCP-Servern

Ein wichtiger Anwendungsfall ist das Sandboxing von Model Context Protocol (MCP)-Servern, um deren Fähigkeiten einzuschränken. Um beispielsweise den Dateisystem-MCP-Server in eine Sandbox zu packen:

Ohne Sandboxing (.mcp.json):

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

Mit Sandboxing (.mcp.json):

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

Dann konfigurieren Sie Einschränkungen in ~/.srt-settings.json:

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

Nun wird der MCP-Server daran gehindert, in den gesperrten Pfad zu schreiben:

> Write a file to ~/sensitive-folder
✗ Error: EPERM: operation not permitted, open '/Users/ollie/sensitive-folder/test.txt'

Funktionsweise

Die Sandbox verwendet Betriebssystem-Primitive, um Einschränkungen durchzusetzen, die für den gesamten Prozessbaum gelten:

macOS: Verwendet sandbox-exec mit dynamisch generierten Seatbelt-Profilen
Linux: Verwendet bubblewrap für die Containerisierung mit Netzwerk-Namespace-Isolation
Windows: Führt den sandboxed Prozess unter einem dedizierten lokalen Benutzerkonto srt-sandbox aus, mit einem Windows Filtering Platform-Egress-Zaun, der auf die SID dieses Kontos abgestimmt ist, einem schreibgeschützten Token und expliziten ACEs auf dem Arbeitsverzeichnisbaum

0d1c612947c798aef48e6ab4beb7e8544da9d41a-4096x2305

Duales Isolationsmodell

Sowohl Dateisystem- als auch Netzwerkisolation sind für effektives Sandboxing erforderlich. Ohne Dateiisolation könnte ein kompromittierter Prozess SSH-Schlüssel oder andere sensible Dateien exfiltrieren. Ohne Netzwerkisolation könnte ein Prozess aus der Sandbox ausbrechen und uneingeschränkten Netzwerkzugriff erlangen.

Dateisystemisolation erzwingt Lese- und Schreibbeschränkungen:

Lesen (Deny-then-Allow-Muster): Standardmäßig ist Lesezugriff überall erlaubt. Sie können breite Bereiche verweigern (z. B. /Users) und dann bestimmte Pfade darin wieder erlauben (z. B. .). allowRead hat Vorrang vor denyRead — das Gegenteil von Schreiben, wo denyWrite Vorrang vor allowWrite hat. Ein denyRead-Eintrag, der spezifischer ist als der allowRead-Bereich, in den er fällt (z. B. denyRead: ["**/.env"] oder ["./secrets"] mit allowRead: ["."]), bleibt dennoch verweigert.
Schreiben (Allow-only-Muster): Standardmäßig ist Schreibzugriff überall verweigert. Sie müssen Pfade explizit erlauben (z. B. ., /tmp). Eine leere Allow-Liste bedeutet keinen Schreibzugriff.

Netzwerkisolation (Allow-only-Muster): Standardmäßig ist jeglicher Netzwerkzugriff verweigert. Sie müssen Domains explizit erlauben. Eine leere allowedDomains-Liste bedeutet keinen Netzwerkzugriff. Der Netzwerkverkehr wird über Proxy-Server geleitet, die auf dem Host laufen:

Linux: Anfragen werden über das Dateisystem über einen Unix-Domain-Socket geleitet. Der Netzwerk-Namespace des sandboxed Prozesses wird vollständig entfernt, sodass der gesamte Netzwerkverkehr über die Proxies laufen muss, die auf dem Host laufen (lauschend auf Unix-Sockets, die in die Sandbox bind-gemountet werden)
macOS: Das Seatbelt-Profil erlaubt die Kommunikation nur zu einem bestimmten localhost-Port. Die Proxies lauschen auf diesem Port und schaffen so einen kontrollierten Kanal für jeglichen Netzwerkzugriff
Windows: Ein maschinenweites WFP-Filterset blockiert ausgehende Verbindungen von Prozessen, die unter dem Konto srt-sandbox laufen, mit Ausnahme von Loopback zum Proxy-Portbereich. Die Proxies lauschen innerhalb dieses Bereichs und schaffen so einen kontrollierten Kanal für jeglichen Netzwerkzugriff. Die Filter folgen weder einem sandboxed Prozess, der vor dem Erstellen eines Sockets ein anderes Token auf einen Thread setzt, noch Verkehr, den ein Systemdienst in seinem Auftrag überträgt; siehe die Windows Bekannten Einschränkungen

Sowohl HTTP/HTTPS (über HTTP-Proxy) als auch anderer TCP-Verkehr (über SOCKS5-Proxy) werden durch diese Proxies vermittelt, die Ihre Domain-Allowlists und -Denylists durchsetzen.

Weitere Details zum Sandboxing in Claude Code finden Sie unter:

sandbox-runtime v0.0.74