Managed AgentsSelbst gehostete Sandboxes

Sicherheitsmodell

Copy page



Modell der geteilten Verantwortung für selbst gehostete Sandbox-Umgebungen.

Anthropic sichert die „control plane“ (Steuerungsebene) über alle Umgebungen hinweg: Integrität von Sitzungen und Arbeitswarteschlangen, mandantenübergreifende Isolation und Minimierung des Agentenkontexts. Wenn du selbst hostest, fallen die folgenden Verantwortlichkeiten dir zu.

Was in deiner Verantwortung liegt

• Qualität des Sandbox-Images und Härtung der Laufzeitumgebung. Anthropic prüft oder verifiziert dein Sandbox-Image nicht. Befolge Best Practices wie das Entfernen unnötiger Linux-Capabilities, das Ausführen als Nicht-Root-Benutzer und die Verwendung eines schreibgeschützten Root-Dateisystems.
• Kontrollen für ausgehenden Netzwerkverkehr. Der Netzwerkzugriff deiner Sandbox wird durch deine VPC- und Firewall-Regeln bestimmt. Ohne Egress-Beschränkungen kann eine kompromittierte Tool-Ausführung beliebige externe Hosts erreichen. Beschränke ausgehenden Datenverkehr auf genau die Endpunkte, die deine Tools benötigen.
• Speicherung und Rotation des Service-Keys. Der Service-Key der Umgebung (ANTHROPIC_ENVIRONMENT_KEY) autorisiert das Abfragen der Arbeitswarteschlange deiner Umgebung und das Zurücksenden von Ergebnissen an Sitzungen. Speichere ihn in einem Secrets-Manager, nicht in Umgebungsdateien oder Sandbox-Images. Rotiere ihn sofort, wenn du eine Offenlegung vermutest.
• Isolierung nicht vertrauenswürdiger Workloads. Der Service-Key der Umgebung ist auf die Arbeitswarteschlange einer einzelnen Umgebung beschränkt. Wenn du nicht vertrauenswürdigen Code in deiner Sandbox ausführst, erwäge, für jede Vertrauensgrenze einen separaten Workspace und eine separate Umgebung bereitzustellen. Dadurch wird jeder Key auf die Sitzungen eines einzelnen Benutzers statt auf einen gemeinsamen Pool beschränkt.
• Sitzungsspezifische Anmeldedaten. Jedes Arbeitselement, das dein Worker beansprucht, kann ein sitzungsspezifisches secret enthalten, das der SDK-Worker anstelle des Service-Keys der Umgebung verwendet. Der Zugriff auf Memory Stores erfordert das secret: Die Memory-Store-Endpunkte lehnen den Umgebungs-Key ab (siehe Memory Stores verwenden). Übergib das secret nur an die Sandbox, die diese Sitzung bedient, halte es aus Images und gemeinsam genutzten Volumes heraus und protokolliere es niemals.
• Schadensradius der Tool-Ausführung. Tools laufen in deiner Sandbox mit den Berechtigungen, die dein Prozess hat. Wende das Prinzip der geringsten Rechte auf den Prozessbenutzer an und binde nur die Verzeichnisse ein, die deine Tools benötigen.
• Log-Aufbewahrung und Sitzungsinhalte. Gesprächsinhalte und Tool-Ausgaben durchlaufen deinen Worker und verbleiben in deiner Umgebung. Du bist dafür verantwortlich, diese Daten gemäß deinen eigenen Richtlinien aufzubewahren, zu schwärzen oder zu löschen. Anthropic hat keinen Einblick darin, was dein Worker mit Sitzungsinhalten macht, sobald sie zugestellt wurden.
• Inhalte von Memory Stores. Memory Stores werden weiterhin von Anthropic gehostet, einschließlich ihres Versionsverlaufs. Wenn eine Sitzung einen anhängt, hält der Worker für die Dauer der Sitzung eine Arbeitskopie unter /mnt/memory/ in deiner Sandbox und synchronisiert Änderungen zurück. Der Worker löscht diese Kopie, wenn die Sitzung endet, aber ein Worker, der beendet wird, ohne seinen Teardown auszuführen, lässt sie zurück. Das Bereinigen übrig gebliebener Kopien, die Berechtigungen auf diesem Pfad und die Isolation zwischen Sitzungen, die sich ein Dateisystem teilen, liegen in deiner Verantwortung.
• Schreibgeschützte Memory Stores. Ein mit read_only-Zugriff angehängter Store ist vor dem Hochladen geschützt, nicht vor lokaler Änderung. Die write- und edit-Tools des Workers verweigern das Schreiben unterhalb seines Verzeichnisses, nichts dort wird zurücksynchronisiert, und die Memory-Store-Endpunkte lehnen Schreibvorgänge darauf ab, die mit dem secret der Sitzung vorgenommen werden. Andere Prozesse in der Sandbox können die lokale Kopie dennoch ändern: Befehle, die der Agent über das bash-Tool ausführt, sowie benutzerdefinierte Tools oder MCP-Server, die du aus der Sandbox bereitstellst und die mit den Berechtigungen des Workers laufen. Spätere Tool-Aufrufe in dieser Sitzung lesen die geänderte Kopie, bis sich dieser Memory das nächste Mal im Store ändert. Wenn der Agent nicht einmal seine lokale Sicht auf einen solchen Store verändern können darf, deaktiviere das bash-Tool für diesen Agenten und gib ihm kein benutzerdefiniertes Tool, das in das Dateisystem der Sandbox schreibt.

Was Anthropic nicht für dich tun kann

• Wissen, dass dein Key geleakt ist. Anthropic kann anomale Nutzungsmuster erkennen, aber nicht wissen, dass dein Key kompromittiert wurde. Wenn du vermutest, dass ANTHROPIC_ENVIRONMENT_KEY geleakt ist, widerrufe ihn und generiere sofort einen Ersatz. Der Widerruf wird bei jeder Anfrage validiert und wird daher beim nächsten Aufruf des Workers wirksam.
• Deinen Worker-Build verifizieren. Anthropic prüft weder dein Sandbox-Image noch deine Laufzeitumgebung. Eine Kompromittierung der Lieferkette in deinem Image ist von der Steuerungsebene aus nicht erkennbar.
• Tools innerhalb deiner Sandbox isolieren. Die Sicherheitsgrenze von Anthropic endet an der Sandbox. Wie du einzelne Tool-Ausführungen innerhalb dieser Grenze voneinander isolierst, liegt vollständig in deiner Verantwortung.
• Datenaufbewahrung in deiner Umgebung durchsetzen. Sobald Sitzungsinhalte deinen Worker erreichen, befinden sie sich außerhalb der Datenlebenszyklus-Kontrollen von Anthropic.