Agent-Sandboxes erklärt: Warum TrueForge die Sandbox als Werkzeug betrachtet

Eine Sandbox kann Code-, Datei- und Shell-Ausführungen isolieren, ohne zur gesamten Laufzeitumgebung des Agenten zu werden. Diese Entscheidung beeinflusst Kosten, die Offenlegung von Anmeldedaten, den Lebenszyklus und die Wiederherstellungssemantik.

Eine Sandbox beantwortet eine engere Frage als „Ist der Agent sicher?“

Ein Agent muss möglicherweise Code ausführen, Dateien bearbeiten, ein Repository untersuchen oder Shell-Befehle ausführen. Diese Vorgänge sollten sich keine uneingeschränkte Prozessgrenze mit dem Orchestrierungsserver oder der Produktionsinfrastruktur des Unternehmens teilen. Eine Sandbox schafft eine eingeschränkte Ausführungsumgebung für diese Aufgaben.

Doch „sandboxed agent“ ist ein unpräziser Begriff. Er kann bedeuten, dass die gesamte Agenten-Schleife innerhalb einer isolierten Maschine läuft, einschließlich Modell-Clients, Tool-Anmeldedaten und Status. Oder er kann bedeuten, dass die Agenten-Schleife in einer verwalteten Laufzeitumgebung verbleibt und nur für ausführungsintensive Aufgaben eine isolierte Umgebung aufruft. TrueForge wählt das zweite Design: Sandbox als Tool.

Diese Unterscheidung ändert, was isoliert wird, wann Rechenleistung existiert, wo Geheimnisse gespeichert sind und was einen Fehler überlebt. Sie verhindert auch, dass eine Sandbox zu einem magischen Sicherheitssiegel wird. Die Grenze schützt nur die Vorgänge und den Datenverkehr, die tatsächlich dahinter platziert werden.

Die Architektur hält das Modell, das Geheimnisse enthält, sowie die MCP-Clients auf der Harness-Seite, während Code- und Shell-Arbeiten eine separate Ausführungsgrenze erhalten. Der Connector ist ein Fähigkeitspfad, keine Übertragung von Anmeldedaten in die Sandbox.

Zwei Architekturen, unterschiedliche Kompromisse

Bei einer Agent-in-Sandbox-Architektur kann jeder Lauf oder jede Agentenumgebung die Orchestrierungsschleife, den Modell-Client, Tools, Anmeldedaten und Arbeitsdateien enthalten. Die Isolierung ist konzeptionell einfach, da die meisten Aktivitäten innerhalb einer Grenze stattfinden. Die Kosten sind eine aufwendigere Bereitstellung, eine komplexere Injektion von Geheimnissen und Image-Neuerstellungen bei Änderungen der Laufzeitabhängigkeiten.

In der dokumentierten Sandbox-als-Tool-Architektur von TrueForge läuft die Agenten-Schleife auf dem TrueForge-Server. Die Sandbox wird nur bereitgestellt, wenn der Agent Code, Dateien, Shell, eine Fähigkeit oder den Code-Modus benötigt. Einfache Konversationsschritte und MCP-Aufrufe erfordern keine Sandbox-Rechenleistung. Modell- und MCP-Anmeldedaten verbleiben im Harness, und MCP-Aufrufe im Code-Modus werden zurück an den Harness geleitet, anstatt der Sandbox diese Token zu überlassen.

Dies reduziert die Angriffsfläche für Geheimnisse und ermöglicht es, dass der Konversationsstatus einen Sandbox-Absturz überlebt. Es bedeutet auch, dass die Sandbox nicht die Netzwerkgrenze für jeden Modell- und Tool-Aufruf darstellt. Der Datenverkehr der Modellanbieter und MCP-Vorgänge erfolgt über den Harness-Pfad und benötigt eigene Gateway-, Identitäts-, Berechtigungs- und Netzwerkkontrollen.

Der dokumentierte Lebenszyklus ist sitzungsbezogen

TrueForge dokumentiert die Sandbox als standardmäßig deaktiviert für jeden Agenten. Wenn sie aktiviert und benötigt wird, erfolgt die Bereitstellung bei Bedarf. Die Sandbox wird über mehrere Schritte in derselben Sitzung hinweg wiederverwendet, sodass Dateien während der Konversation erhalten bleiben. Nach einer Leerlaufzeit wird sie gestoppt, archiviert und schließlich gemäß den Anbietereinstellungen gelöscht.

Dieser Lebenszyklus ist nützlicher als „ein Einweg-Container pro Prompt“, wirft jedoch Fragen zur Statusverwaltung auf. Eine Datei aus Schritt 1 kann Schritt 5 beeinflussen. Ein bösartiges Archiv, das frühzeitig extrahiert wurde, kann vorhanden bleiben, nachdem die unmittelbare Aufgabe vergessen wurde. Eine während eines Schritts installierte Abhängigkeit kann die spätere Ausführung verändern. Sitzungskontinuität ist ein Feature; unkontrollierte Statusansammlung ist ein Risiko.

Anwendungen sollten Artefakte mit ihrem Quellereignis, Inhalts-Digest, Datenklassifizierung und beabsichtigter Lebensdauer kennzeichnen. Bevor ein späterer Schritt eine Datei ausführt, überprüfen Sie, ob sie noch zur aktiven Aufgabe gehört und ob der aktuelle Benutzer berechtigt ist, darauf zuzugreifen. Wenn Reproduzierbarkeit wichtig ist, zeichnen Sie den Sandbox-Snapshot oder die Image-Identität, den Status der Abhängigkeitssperre und die Befehle auf, die das Artefakt erzeugt haben.

Die Wiederverwendung über mehrere Durchläufe hinweg ist sowohl eine Funktion als auch ein Risiko. Dateien können nützliche Arbeitsergebnisse nach einer Pause bewahren, doch jedes wiederhergestellte Artefakt benötigt eine Herkunft, eine Klassifizierung und eine Lebenszyklusregel, anstatt sich allein auf das Vertrauen aus der Sitzung zu stützen.

Anmeldedaten außerhalb der Sandbox verringern die Berechtigungen – heben sie jedoch nicht auf

Wenn Modell- und MCP-Anmeldedaten im Harness verbleiben, wird verhindert, dass beliebiger Sandbox-Code diese Geheimnisse direkt ausliest. Dies stellt eine starke Grenze dar. Dennoch könnte ein in der Sandbox ausgeführtes Skript den Harness über eine kontrollierte Brücke dazu auffordern, einen MCP-Aufruf auszuführen. Die entscheidende Sicherheitsfrage lautet daher: Welche Aufrufe kann dieser Code anfordern, mit welcher Identität, unter Verwendung welcher Argumente und gemäß welcher Richtlinie?

Die Brücke sollte eine spezifische Funktionalität bereitstellen, anstatt allgemeine Anmeldedaten offenzulegen. Tool-Definitionen, Subjektidentität, Zielort, Datenklassifizierung, kumulative Budgets und Genehmigungsanforderungen sollten außerhalb der Sandbox bewertet werden. Die an den Code zurückgegebenen Ergebnisse sollten minimiert werden, da sie innerhalb der Umgebung zu Dateien, Protokollen oder Befehlseingaben werden können.

Ebenso beweist das Fehlen von Modell-Anmeldedaten nicht, dass die Sandbox keinen Datenausgang hat. Die Konfiguration des Anbieters bestimmt die Netzwerkerreichbarkeit. Eine robuste Bereitstellung definiert separat ausgehende Ziele, DNS-Verhalten, Richtlinien zur Paketinstallation, Zugriff auf Metadatendienste, Dateisystem-Mounts, Ressourcenbeschränkungen und Abbruchkontrollen. TrueForge orchestriert den Sandbox-Anbieter; die Organisation validiert den Anbieter und dessen Konfiguration weiterhin anhand ihres Bedrohungsmodells.

Vertrauensgrenzen explizit abbilden

Offenlegen