KI & Automation

Sandbox (abgeschottete Ausführungsumgebung)

Eine Sandbox ist ein abgeschotteter Bereich auf einem Rechner, in dem ein Programm ausschließlich die ihm zugeteilten Dateien, Netzwerkadressen und Rechenmittel erreicht; Fehler und Angriffe, die darin auftreten, bleiben vom übrigen Rechner und vom Firmennetz ferngehalten.

Die Sandbox ist die technische Umsetzung der Werkzeuggrenze in einem Agent-Harness: Sie begrenzt, was eine KI-Automation auf dem Rechner tun kann, unabhängig davon, was das Modell ausgeben will.

In einfachen Worten

Das Wort kommt vom Sandkasten, in dem Kinder bauen dürfen, ohne dass etwas außerhalb davon Schaden nimmt. Technisch ist eine Sandbox ein Bereich mit festen Wänden: Das Programm darin sieht nur die Dateien, die ihm zugewiesen sind, erreicht nur die Adressen im Netz, die auf einer Allowlist stehen, und bekommt nur so viel Rechenzeit, Arbeitsspeicher und Laufzeit, wie festgelegt ist. Andere Programme desselben Rechners, das übrige Firmennetz und die Zugangsdaten des Betriebs liegen außerhalb der Wände. Für einen KI-Agenten ist das die entscheidende Sicherung, weil das Sprachmodell Text erzeugt, den der Harness ausführt. Enthält dieser Text eine Aktion, die niemand wollte, etwa nach einer Prompt-Injection über einen manipulierten Beleg, trifft sie auf die Wand der Sandbox und bleibt folgenlos. Die Sandbox ersetzt das Vertrauen in das Verhalten des Modells durch eine Grenze, die technisch gilt. Ergänzt wird sie durch Obergrenzen für Schritte und Laufzeit, die einen Durchlauf beenden, der sich im Kreis dreht.

Wozu brauche ich das?

Jede Automation, die Werkzeuge mit Wirkung auf Dateien, Datenbanken oder das Netz aufruft, gehört in eine Sandbox. Das gilt für die Belegzuordnung im Haus ebenso wie für einen Agenten, der Programmcode erzeugt und ausführt (Agentic Coding). Der Zuschnitt folgt der Aufgabe: ein Verzeichnis für Eingang und Ausgang, eine Verbindung zum Modell, eine Verbindung zur Schnittstelle der Warenwirtschaft, sonst nichts.

Beispiel aus der Praxis

Ein Handelsbetrieb betreibt eine Automation, die Kundenanfragen aus dem Posteingang liest, den Bestellstatus nachschlägt und Antwortentwürfe vorbereitet. Die Automation läuft in einer Sandbox auf einem Server im Firmennetz: Sie liest aus einem Eingangsordner, schreibt Entwürfe in einen Ausgangsordner, darf die Schnittstelle der Warenwirtschaft lesend abfragen und das Modell erreichen. Versenden, Löschen und der Zugriff auf andere Ordner sind technisch nicht möglich. Im Probebetrieb schickt die IT eine präparierte Anfrage, eine Prompt-Injection, in der ein versteckter Satz das Modell auffordert, alle Kundendaten an eine fremde Adresse zu senden. Das Modell nimmt die Aufforderung teilweise auf und formuliert einen Versandbefehl; der Harness findet dafür kein Werkzeug, die Sandbox lässt keine Verbindung zu der fremden Adresse zu, und im Audit-Log steht der Vorfall mit Zeitstempel. Der Ablauf geht unverändert in Betrieb.

Wirtschaftlicher Nutzen

Die Sandbox macht den Schaden eines Fehlverhaltens berechenbar: Er ist auf das begrenzt, was innerhalb der Wände liegt. Für den Betrieb heißt das, dass eine Automation mit echten Daten laufen kann, ohne dass ein einzelner Fehler des Modells Stammdaten, Buchungen oder Kundenbeziehungen trifft. Die Sandbox ist zugleich eine technische Maßnahme, die sich gegenüber Kunden und Aufsicht belegen lässt. Ihr Aufwand liegt in der Einrichtung und in der Pflege der Grenzen, wenn sich die Aufgabe ändert; er bleibt klein gegen die Aufarbeitung eines Vorfalls, bei dem eine Automation außerhalb ihrer Grenzen gehandelt hat.

Typische Fehler

  • Die Automation mit den Rechten des Benutzers laufen lassen, der sie gestartet hat, sodass sie alles erreicht, was dieser Benutzer erreicht.
  • Die Sandbox nur für Dateien ziehen und die Netzwerkseite offen lassen, sodass eine Verbindung zu beliebigen Adressen möglich bleibt.
  • Zugangsdaten innerhalb der Sandbox ablegen, wo das Modell sie lesen und in eine Ausgabe schreiben kann.
  • Keine Obergrenzen für Schritte, Laufzeit und Modellaufrufe setzen, sodass ein Durchlauf endlos weiterläuft.
  • Die Grenzen nach einer Erweiterung der Aufgabe nicht nachziehen, sodass neue Werkzeuge außerhalb der Sandbox arbeiten.

Worauf achten?

  • Verzeichnisse, Netzwerkziele und Ressourcen je Automation auflisten und nur diese freigeben.
  • Lesende von schreibenden Zugriffen trennen und schreibende auf einen Entwurfsbereich beschränken.
  • Obergrenzen für Schritte, Laufzeit und Kosten setzen und einen abgebrochenen Durchlauf als unvollständig kennzeichnen.
  • Die Wände mit präparierten Eingaben testen und das Ergebnis im Audit-Log nachlesen.
  • Nach jeder Änderung an Aufgabe oder Werkzeugen die Grenzen prüfen und den Test wiederholen.

Häufig gestellte Fragen

Was ist eine Sandbox?

Ein abgeschotteter Bereich, in dem ein Programm ausschließlich auf die ihm zugeteilten Dateien, Netzwerkadressen und Rechenmittel zugreift. Fehler und Angriffe innerhalb dieses Bereichs erreichen den übrigen Rechner nicht.

Warum braucht eine KI-Automation eine Sandbox?

Weil das Sprachmodell Text erzeugt, den der Harness ausführt, und dieser Text eine unerwünschte Aktion enthalten kann, etwa nach einer versteckten Anweisung in einem verarbeiteten Dokument. Die Sandbox sorgt dafür, dass eine solche Aktion auf eine Wand trifft, statt Stammdaten, Buchungen oder das Netz zu erreichen.

Was gehört in eine Sandbox für eine Belegautomation?

Ein Eingangs- und ein Ausgangsverzeichnis, die Verbindung zum Modell, eine lesende Verbindung zur Schnittstelle der Warenwirtschaft und Obergrenzen für Schritte und Laufzeit. Versand, Löschen und andere Verzeichnisse bleiben außerhalb.

Wie prüft man, ob die Sandbox wirkt?

Mit präparierten Eingaben, die absichtlich eine Grenze verletzen: ein Beleg mit einer versteckten Versandanweisung, ein Werkzeugaufruf auf ein fremdes Verzeichnis, eine Verbindung zu einer Adresse außerhalb der Liste. Im Audit-Log lässt sich anschließend nachlesen, ob der Versuch abgewiesen wurde.