Sandboxed Code Agents: Lassen Sie Modelle Code ausführen, ohne ihnen freien Lauf zu lassen

Einem KI-Modell die Möglichkeit zur Code-Ausführung zu geben, ist eines der effektivsten Upgrades, die Sie vornehmen können. Anstatt 100.000 Zeilen in den Kontext zu laden, kann der Agent Code schreiben, der diese verarbeitet. Anstatt das Modell zu bitten, Dateien mental zu transformieren, kann es einen Parser ausführen. Anstatt einen vagen Vorschlag zu liefern, kann es ein Artefakt erstellen und testen.

Es ist jedoch auch der Moment, in dem ein KI-System aufhört, „nur Text“ zu sein. Code kann Dateien lesen, Sockets öffnen, CPU-Leistung beanspruchen, Prozesse forken, Umgebungsvariablen auslesen und alles verändern, was die Laufzeitumgebung erreichen kann. Das richtige Produktionsmuster lautet nicht „vertraue dem Modell mehr“, sondern geben Sie dem Modell einen kleineren Computer.

1. Die Sandbox-Grenze

agent
  ↓
ephemeral workspace
  ├─ filesystem: scoped
  ├─ CPU / memory: bounded
  ├─ runtime: code + shell
  ├─ network: deny / allowlist
  ├─ secrets: none by default
  └─ artifacts: explicit export
          ↓
     governed tool boundary
          ↓
   approval / policy
          ↓
   external side effect

Dateisystem

Geben Sie dem Prozess einen Arbeitsbereich, nicht das Host-Dateisystem. Mounten Sie nur notwendige Eingaben und machen Sie sensible Host-Pfade unerreichbar. Der Export von Artefakten sollte explizit erfolgen, damit „der Agent hat eine Datei erstellt“ nicht bedeutet, dass „der Agent überall schreiben kann“.

Netzwerk

Netzwerkzugriff sollte als eine spezifische Berechtigung behandelt werden. Viele Analyseaufgaben benötigen überhaupt keinen ausgehenden Netzwerkzugriff. Andere benötigen möglicherweise eine Whitelist. Ein uneingeschränkter ausgehender Datenverkehr macht aus einer beliebigen Code-Ausführung einen Pfad zur Datenexfiltration.

Geheimnisse

Injizieren Sie standardmäßig keine langlebigen Anbieter- oder Unternehmensanmeldedaten in die Sandbox-Umgebung. Wenn der Agent eine externe Funktion benötigt, bevorzugen Sie ein kontrolliertes Tool, das sich außerhalb der Sandbox authentifiziert und nur die jeweils erforderliche, eng begrenzte Operation freigibt.

Zeit und Ressourcen

Legen Sie Limits für Laufzeit, CPU, Arbeitsspeicher, Prozesse und Ausgabegröße fest. Ohne diese wird eine versehentliche Endlosschleife oder eine unbegrenzte Datenausweitung zu einem Infrastrukturvorfall anstatt nur zu einem fehlgeschlagenen Agenten-Schritt.

Artefakt-Übergabe

Trennen Sie Erstellung von Konsequenz. Die Sandbox kann einen Patch, einen Bericht, ein Bild, eine SQL-Datei oder einen Bereitstellungsplan erzeugen. Ein nachgelagerter Richtlinien- oder Freigabeschritt entscheidet dann, ob dieses Artefakt veröffentlicht oder angewendet wird.

Bedrohungsmodellierung der Sandbox nach Berechtigungen

„Sandboxed“ ist keine binäre Eigenschaft. Listen Sie die Berechtigungen auf, die der Prozess erhält: Lese-/Schreibpfade, Zieladressen für ausgehenden Verkehr, Paketinstallation, Erstellung von Subprozessen, Kernel-Funktionen, Umgebungsvariablen, gemountete Anmeldedaten und maximale Laufzeit. Die Sicherheitslage ergibt sich aus der Schnittmenge dieser Berechtigungen, nicht aus dem Container-Label.

Ein Arbeitsbereich ohne Host-Mounts, aber mit uneingeschränktem Internetzugang und Cloud-Anmeldedaten kann beispielsweise dennoch Daten exfiltrieren oder die Infrastruktur verändern. Ein Arbeitsbereich ohne Netzwerk, aber mit einem beschreibbaren Produktions-Volume kann ebenfalls Schaden anrichten. Das nützliche Design-Artefakt ist eine Berechtigungsmatrix, die genau zeigt, was jede Klasse von Agenten-Jobs tun darf.

Bevorzugen Sie die Bereitstellung von Artefakten gegenüber direkten Änderungen

Viele nützliche Aufgaben für Code-Agenten erfordern keinen direkten Zugriff auf die Produktionsumgebung. Lassen Sie den Agenten stattdessen in einer Sandbox einen Patch, ein Notebook, einen Bericht, einen Migrationsplan, ein Deployment-Manifest oder einen transformierten Datensatz erstellen. Überführen Sie dieses Artefakt anschließend über einen separaten, geprüften Prozess. Dies schafft einen natürlichen Kontrollpunkt, an dem deterministische Tests, Richtlinien und menschliche Prüfungen stattfinden können, bevor Konsequenzen entstehen.

Dieses Muster ist besonders effektiv bei der Softwareentwicklung: Patch generieren → Tests in der Sandbox ausführen → Diff und Testergebnisse ausgeben → genehmigen → über ein kontrolliertes Repository oder Deployment-Tool anwenden. Der Agent erhält so umfassende Autonomie bei der Berechnung, ohne die entsprechende Autonomie über die Produktionsumgebung zu erhalten.

Die Installation von Paketen ist ebenfalls Codeausführung

Ein Agent, der Pakete frei installieren kann, ist in der Lage, beliebige Installationsskripte von Drittanbietern auszuführen und seine Angriffsfläche im Netzwerk zu vergrößern. Produktions-Sandboxes sollten kuratierte Basis-Images, fixierte Abhängigkeiten, eine Whitelist für Paketquellen oder eine explizite Richtlinie für die Paketinstallation verwenden. Der Komfort von „pip install, was auch immer du brauchst“ ist für einige risikoarme, kurzlebige Aufgaben angemessen, sollte jedoch eine bewusste Entscheidung sein.

Erfassen Sie genügend Nachweise, um den Durchlauf zu reproduzieren

Speichern Sie die Sandbox-Image- bzw. Laufzeitversion, die Identifikatoren der Eingabeartefakte, die ausgeführten Befehle oder Codezellen, Exit-Status, Hashes der erzeugten Artefakte sowie alle kontrollierten externen Aufrufe. Eine vollständige Byte-für-Byte-Wiedergabe ist möglicherweise nicht immer praktikabel, aber ein Operator sollte in der Lage sein, zu erklären, was ausgeführt wurde und welche Ausgaben die Sandbox-Grenze überschritten haben.

2. Wo TrueFoundry ansetzt: Sandbox innerhalb des Harness, Autorität außerhalb

TrueFoundrys Agent Harness betrachtet die Sandbox-Ausführung als Teil der Laufzeitumgebung um das Modell herum, ergänzt durch Kontextmanagement, Genehmigungen, Tool-Ausführung und Tracing. Das macht die Codeausführung sowohl für die Automatisierung als auch für die Kontextsteuerung nützlich: Umfangreiche Zwischendaten können direkt im Arbeitsbereich verarbeitet werden, anstatt sie bei jedem Modellschritt erneut zu kopieren.

Externe Aktionen lassen sich besser über das MCP Gatewayabbilden, wo Tool-Zugangsdaten, Zugriffskontrollen, Pre-/Post-Guardrails und Genehmigungen zentral verwaltet werden. Agent Registry liefert den Identitäts- und Eigentümerkontext für den Agenten, und End-to-End-Traces korrelieren die Arbeit in der Sandbox mit den Modell- und Tool-Schritten.

Der architektonische Kernpunkt ist die Trennung: Die Sandbox ist der Ort, an dem der Agent berechnen darf; das Gateway ist der Ort, an dem der Agent die Berechtigung erhält, andere Systeme zu beeinflussen.

3. Grenzen, klar definiert

Eine Sandbox verringert zwar den potenziellen Schaden, macht aber beliebigen Code nicht vertrauenswürdig. Kernel-/Container-Ausbrüche, Abhängigkeitsrisiken, übermäßige Berechtigungen und Netzwerkfreigaben bleiben weiterhin kritisch. Umgebungen mit hohen Sicherheitsanforderungen erfordern unter Umständen eine stärkere Isolierung als ein Standard-Container.

Außerdem benötigt nicht jeder Agent die Möglichkeit zur Codeausführung. Einem Workflow, der lediglich drei klar definierte APIs aufruft, eine Shell hinzuzufügen, vergrößert die Angriffsfläche, ohne einen nennenswerten Mehrwert zu bieten. Nutzen Sie die kleinstmögliche Ausführungsumgebung, die Ihr Problem löst.

Referenzen

• TrueFoundry: Was ist ein Agent Harness?.
• TrueFoundry: JIT-Kontext.
• TrueFoundry MCP-Gateway.
• TrueFoundry Guardrails.
• TrueFoundry Agent-Registry.

Sandboxing ist eine Maßnahme der gestaffelten Verteidigung (Defense-in-Depth), keine Sicherheitsgarantie. Die Stärke der Isolierung sollte der Sensibilität des Codes, der Daten, des Netzwerks und der nachgelagerten Systeme entsprechen.

‍