# Umgebungszugriff: Sandbox, Egress, Ausführungskontext

> Wenn ein Agent nicht nur APIs aufruft, sondern Code ausführt und Oberflächen bedient: die fünf Isolationsachsen, Netzausgang als Exfiltrationsgrenze, Identität der Ausführung, Zustand der Umgebung und Ressourcengrenzen.

Track: [Agentic AI](https://physar.tech/learn/agentic-ai)  
Kanonische Fassung: https://physar.tech/learn/agentic-ai/agent-environment-access  
Stand: 2026-09-04  
Interaktiver Teil: 9 Checks (nur im Browser)

## Umgebungszugriff: Sandbox, Egress und die Frage, mit wessen Rechten der Code läuft

### Die Grenze verschiebt sich vom Werkzeug zur Umgebung

Solange ein Agent benannte Werkzeuge aufruft, ist der Raum seiner möglichen Wirkungen abzählbar: Es gibt so viele Operationen, wie es Werkzeuge gibt. Sobald er Code ausführt oder eine Oberfläche bedient, endet diese Abzählbarkeit. `bash` ist kein Werkzeug mit einer Fähigkeit, sondern ein Werkzeug mit allen Fähigkeiten des Kontos, unter dem es läuft.

Damit wandert die eigentliche Kontrolle von der Werkzeugdefinition in die Umgebung. Die Frage ist nicht mehr „welche Argumente sind erlaubt“, sondern „was ist in dieser Umgebung überhaupt erreichbar“. Wer Codeausführung anbietet und die Absicherung weiter in Beschreibungen sucht, hat die Verlagerung nicht mitgemacht.

> **Merksatz:** Ein Agent mit Codeausführung hat genau die Rechte seiner Umgebung — nicht die, die im Systemprompt stehen. Die Umgebung ist die Berechtigung.

### Was eine Sandbox tatsächlich isoliert

„Sandbox“ ist kein Zustand, sondern eine Aussage über fünf getrennte Achsen. Jede kann isoliert sein oder nicht, und die Kombination entscheidet, was ein Fehlverhalten anrichten kann.

|  |  |
| --- | --- |
| Prozess | Läuft der Code in einem eigenen Namensraum, oder kann er Prozesse des Hosts sehen und beeinflussen? |
| Dateisystem | Sieht er nur ein Arbeitsverzeichnis, oder auch eingebundene Pfade des Hosts — Zugangsdaten, Sockets, Konfigurationen? |
| Netzwerk | Kann er ausgehende Verbindungen aufbauen, und wenn ja, wohin? Diese Achse trägt die Exfiltration. |
| Identität | Mit welchen Zugangsdaten läuft er? Ein isolierter Prozess mit einem Produktionstoken ist keine Sandbox. |
| Zeit und Ressourcen | Wie lange darf er laufen, wie viel Rechenzeit, Speicher und Plattenplatz verbrauchen? |

**Sandbox:** Eine Ausführungsumgebung, die auf **allen fünf Achsen** ausdrücklich begrenzt ist. Fehlt eine, ist es eine Ausführungsumgebung mit einer Lücke — und die Lücke bestimmt den Schaden, nicht die vier geschlossenen Achsen.

Die am häufigsten offene Achse ist die Identität, weil sie am wenigsten nach Isolation aussieht. Ein Container ist schnell abgeschottet; ein eingebundenes Zugangsdaten-Verzeichnis fällt niemandem auf, weil es „nur eine Datei“ ist.

Bei einer Container-Laufzeit lassen sich die Achsen an konkreten Schaltern ablesen, und drei davon heben die Isolation vollständig auf. `privileged` gibt dem Container praktisch die Rechte des Hosts. Ein Netzwerkmodus, der den Host-Netzstack teilt, macht jede Netzregel des Containers wirkungslos. Und ein eingebundener Docker-Socket erlaubt es, beliebige weitere Container zu starten — mit beliebigen Einbindungen. Wer eine Umgebung beurteilen soll, findet die Antwort schneller in diesen drei Zeilen als in jeder Beschreibung.

Die Gegenrichtung ist genauso konkret: Ein Container ohne Netzwerkanbindung, mit einem schreibbaren Arbeitsverzeichnis und einem unprivilegierten Nutzer ist auf vier Achsen geschlossen, bevor überhaupt eine Richtlinie formuliert wurde. Diese Voreinstellung ist billiger als jede nachträgliche Absicherung.

### Der stärkste Fall: gar kein Netz

Es lohnt, den strengsten real existierenden Fall anzusehen, weil er zeigt, was Isolation kostet. Die Codeausführung als Server-Werkzeug läuft in einem Container, dessen Internetzugang **vollständig abgeschaltet** ist: keine ausgehenden Netzanfragen, vollständige Isolation gegenüber Host und anderen Containern.

|  |  |
| --- | --- |
| Gewinn | Kein Exfiltrationsweg über das Netz. Was in den Container gelangt, kommt nur über einen definierten Kanal wieder heraus. |
| Preis | Keine Pakete zur Laufzeit nachladbar — nur was vorinstalliert ist, ist verfügbar. Und keine eurer eigenen Systeme erreichbar. |
| Folge | Alles, was der Code braucht, muss vorher hinein: Bibliotheken im Abbild, Daten als hochgeladene Dateien. |

Das ist der ehrlichste Trade-off im ganzen Feld. Vollständige Netzisolation ist die einzige Egress-Kontrolle ohne Restrisiko — und sie schließt genau die Anwendungsfälle aus, für die man einen Agenten mit Codeausführung meist haben will: Daten aus dem eigenen Warehouse ziehen, ein internes API aufrufen, ein Paket installieren.

> **Preis der richtigen Wahl:** Wer eine Netzausnahme einbaut, um „nur das Warehouse“ erreichbar zu machen, hat keine abgeschwächte Isolation, sondern eine andere Architektur: Ab jetzt ist eine Allowlist zu pflegen, und jeder Eintrag darauf ist ein potenzieller Ausgangskanal.

### Der Ausführungskontext ist der Ort der Rechte

### Die Sandbox, die keine war

Ein Analyse-Agent führt Python in einem Container aus. Der Container ist frisch, das Dateisystem eigen, der Prozess isoliert. Damit der Agent Daten laden kann, ist eine Umgebungsvariable mit dem Zugangstoken des Data-Warehouse gesetzt — dasselbe Token, das die Berichtspipeline benutzt, mit Leserecht auf alle Schemata.

**Anforderungen**

- Der Agent soll aggregierte Auswertungen erstellen können
- Ein fehlgeleiteter Lauf darf nicht mehr erreichen als die Aufgabe braucht
- Der Zugriff muss einer Sitzung zuordenbar bleiben

**Schritte**

- Befund: Vier Achsen sind geschlossen, die Identität ist offen. Der Container ist isoliert, das Token ist es nicht.
- Erste Korrektur: ein eigenes Dienstkonto nur für den Agenten, mit Leserecht ausschließlich auf die zwei Schemata, die die Aufgabe braucht.
- Zweite Korrektur: kurzlebige Zugangsdaten statt eines dauerhaften Tokens, ausgestellt je Lauf und nach Minuten verfallend.
- Dritte Korrektur: die Zugangsdaten nicht als Umgebungsvariable, sondern über einen Abruf, den die Ausführungsschicht vornimmt — sonst liest sie jeder Code im Container per `env`.
- Vierte Korrektur: den Zugriff im Warehouse dem auslösenden Menschen zurechenbar machen, nicht nur dem Dienstkonto.
- Gegenprobe: ein Testlauf, der ein drittes Schema abfragt — er muss mit einem Berechtigungsfehler enden, nicht mit Daten.

**Merksatz:** Isolation auf vier Achsen mit einem Produktionstoken auf der fünften ist keine teilweise Absicherung, sondern eine vollständige Lücke mit gutem Gefühl.

### Abhängigkeiten müssen vorher hinein

Aus einer geschlossenen Netzachse folgt eine Betriebsaufgabe, die überrascht, weil sie nach Entwicklung aussieht und Sicherheit ist: Was der Code braucht, muss im Abbild liegen, bevor der Lauf beginnt.

- **Abbild statt Laufzeitinstallation** — die Bibliotheken kommen fest ins Abbild. Ein `pip install` zur Laufzeit ist entweder unmöglich oder ein offener Ausgangskanal.
- **Versionen festnageln** — sonst unterscheidet sich der Lauf von heute vom Lauf von gestern, und ein Fehlschlag ist nicht reproduzierbar.
- **Herkunft prüfen** — jedes Paket im Abbild ist Code, der mit den Rechten des Agenten läuft. Die Lieferkette ist Teil der Angriffsfläche.
- **Sparsam bleiben** — jedes zusätzliche Werkzeug im Abbild ist eine Fähigkeit, die ein fehlgeleiteter Lauf nutzen kann. Ein Netzwerkwerkzeug im Abbild einer netzlosen Sandbox ist bestenfalls nutzlos.

Der letzte Punkt wird regelmäßig unterschätzt. Ein umfangreiches Abbild „für alle Fälle“ ist dieselbe Fehlform wie eine aufgeblähte Werkzeugmenge, nur ohne Beschreibungen, aus denen man sie erkennen könnte.

### Egress ist die Grenze, an der Daten das Haus verlassen

Für die Netzachse gibt es eine Formulierung, die den Kern besser trifft als jede Risikomatrix. Sie benennt drei Eigenschaften, die einzeln unproblematisch und **zusammen** gefährlich sind.

**Lethal Trifecta:** Die Kombination aus **Zugriff auf private Daten**, **Kontakt mit nicht vertrauenswürdigen Inhalten** und **der Fähigkeit, nach außen zu kommunizieren**. Liegen alle drei vor, kann fremder Inhalt den Agenten anweisen, private Daten hinauszutragen.

Der praktische Wert dieser Formulierung liegt in der Handlungsanweisung, die daraus folgt: **Die einzige verlässliche Absicherung ist, die Kombination zu vermeiden.** Eines der drei Beine zu entfernen ist eine Architekturentscheidung mit garantierter Wirkung — ein Filter, der Angriffe erkennt, ist eine Wahrscheinlichkeitsaussage.

Zur Einordnung solcher Filter gibt es einen Satz, den man sich merken sollte: Werbeaussagen wie „erkennt 95 Prozent der Angriffe“ sind in der Anwendungssicherheit **eine glatte Fünf**. Bei einem Exfiltrationsweg heißt 95 Prozent, dass jeder zwanzigste Versuch gelingt — und ein Angreifer versucht es mehr als zwanzigmal.

**Kurzcheck:** Ein Agent liest Kundentickets (fremder Inhalt), hat Lesezugriff auf die Kundendatenbank (private Daten) und darf Webanfragen stellen (Ausgangskanal). Welche Änderung entfernt das Risiko strukturell?

- [x] Ausgehende Verbindungen entfernen und Ergebnisse nur über einen definierten Rückkanal ausliefern
- [ ] Einen Injection-Klassifikator vor die Ticketverarbeitung setzen
- [ ] Die Webanfragen auf eine Allowlist bekannter Domains einschränken
- [ ] Im Systemprompt untersagen, Datenbankinhalte in Webanfragen zu verwenden

> Entfernt ein Bein der Kombination vollständig. Damit gibt es keinen Weg, private Daten nach außen zu tragen — unabhängig davon, was in einem Ticket steht.

### Zustand: flüchtig oder fortgesetzt

Ob eine Umgebung zwischen zwei Anfragen weiterlebt, ist eine Entscheidung mit Folgen für Reproduzierbarkeit, Isolation und Kosten. In der Voreinstellung läuft jede Anfrage in einem **neuen** Container; wer den Zustand behalten will, gibt die Container-Kennung der vorherigen Antwort zurück.

|  |  |
| --- | --- |
| Flüchtig | Jeder Lauf startet gleich. Kein Übertrag von Fehlern oder Daten zwischen Läufen, saubere Isolation zwischen Nutzern — aber jeder Lauf zahlt seine Vorbereitung erneut. |
| Fortgesetzt | Dateien und Zwischenstände bleiben erhalten, lange Aufgaben werden möglich — aber ein Lauf erbt, was der vorherige hinterlassen hat, und die Isolation zwischen Nutzern muss jetzt der Aufrufer sicherstellen. |

Der Grenzfall, der im Betrieb Ärger macht, liegt dazwischen: eine Umgebung, die nach einigen Minuten Untätigkeit stillgelegt und bei der nächsten Anfrage wiederhergestellt wird, aber nach einer längeren Frist endgültig verfällt. Ein Lauf, der auf eine verfallene Umgebung verweist, bekommt einen Fehler und keine neue Umgebung — dieser Fall muss im Code behandelt sein, sonst scheitert er zufällig nach Pausen.

Konkret hängt das an zwei Feldern der Antwort: einer Kennung der Umgebung und einem Verfallszeitpunkt. Wer die Kennung bei der nächsten Anfrage mitschickt, arbeitet weiter; wer sie weglässt, bekommt eine frische Umgebung. Wichtig ist, dass der ausgewiesene Verfallszeitpunkt ein rollierender Wert ist und nicht die endgültige Frist beschreibt — auf ihn allein sollte sich die Aufräumlogik nicht stützen.

> **Merksatz:** Fortgesetzter Zustand ist bequem und macht aus einem Lauf ein Konto. Wo mehrere Nutzer im Spiel sind, ist die Wiederverwendung derselben Umgebung eine Mandantenfrage.

### Was hinein- und was herauskommt

Bei einer netzlosen Umgebung sind die Dateikanäle die **einzigen** Wege hinein und hinaus — und damit die Stelle, an der die Datenflusskontrolle sitzt.

Eingang: eine hochgeladene Datei wird der Anfrage beigelegt → Ausführung: der Code liest sie, verarbeitet und schreibt Ergebnisse → **Ausgang: nur Dateien im dafür vorgesehenen Ausgabeverzeichnis werden übernommen** → Protokoll: beide Listen — hinein und hinaus — sind der prüfbare Datenfluss

Hinaus geht typischerweise nur, was der Code in ein bestimmtes Ausgabeverzeichnis legt — bei der Codeausführung als Server-Werkzeug ist das ein je Aufruf frisch angelegtes Verzeichnis, dessen Pfad dem Kommando als `$OUTPUT_DIR` bekannt ist. Übernommen wird, was auf dessen oberster Ebene liegt. Alles, was der Code anderswo schreibt, bleibt in der Umgebung. Das ist eine erfreulich harte Grenze und gleichzeitig eine Falle für Erwartungen: Ein Agent, der eine Datei „erzeugt hat“, hat sie nicht zwingend ausgeliefert.

Hinein geht, was hochgeladen wird — und genau das ist die Stelle, an der private Daten in die Umgebung gelangen. Wer den Datenfluss beurteilen will, muss deshalb nicht die Prompts prüfen, sondern zwei Listen: was hochgeladen wurde und was aus dem Ausgabeverzeichnis zurückkam. Beide sind kurz, maschinenlesbar und protokollierbar.

### Ressourcengrenzen sind Teil der Isolation

Die fünfte Achse wird gern als Betriebsdetail behandelt und ist eine Isolationsachse. Ein Lauf mit einer Endlosschleife in einer Umgebung ohne Grenzen ist kein Sicherheitsvorfall, aber ein Verfügbarkeits- und Kostenvorfall — und er trifft alle anderen Läufe auf derselben Maschine.

- **Rechenzeit** — eine harte Obergrenze je Ausführung, nicht nur je Lauf. Ein Agent kann viele kurze Aufrufe machen.
- **Speicher** — eine Grenze, deren Überschreitung einen definierten Fehler erzeugt und nicht den Wirtsprozess trifft.
- **Plattenplatz** — begrenzt, weil eine Endlosschleife, die schreibt, sonst den Datenträger füllt.
- **Gleichzeitigkeit** — wie viele Umgebungen gleichzeitig laufen dürfen. Ohne diese Grenze ist eine Agentenschleife ein Lastgenerator.

Wichtig ist auch hier, was beim Greifen passiert. Eine Grenze, die den Prozess abschießt und dem Agenten nichts sagt, erzeugt einen Lauf mit unerklärlicher Lücke. Eine Grenze, die einen benannten Fehler zurückgibt, erzeugt eine Beobachtung, aus der der Agent den nächsten Schritt ableiten kann — kleinere Datenmenge, engere Abfrage, Abbruch mit Aussage.

### API oder Oberfläche

Wenn ein Agent ein System bedienen soll, das eine Programmierschnittstelle hat, ist die Entscheidung einfach. Interessant ist der andere Fall: ein System ohne API, das nur eine Weboberfläche anbietet.

|  |  |
| --- | --- |
| Programmierschnittstelle | Benannte Operationen, geprüfte Argumente, unterscheidbare Fehlercodes, stabil über Zeit. Alles, was dieses Modul kontrollierbar macht, ist hier vorhanden. |
| Oberflächenautomatisierung | Kein Vertrag, keine Fehlercodes, brüchig bei jedem Layoutwechsel — und die Aktion ist im Zielsystem nicht von einer menschlichen Handlung zu unterscheiden. |

Der letzte Punkt der zweiten Zeile ist der schwerwiegendste und wird selten genannt: Wenn ein Agent sich als menschlicher Nutzer anmeldet und klickt, steht im Prüfprotokoll des Zielsystems dieser Mensch. Die Zurechenbarkeit ist damit weg, und zwar nicht in deinem System, sondern in einem fremden.

Oberflächenautomatisierung bleibt vertretbar, wenn es keinen anderen Weg gibt. Dann gehört sie mit einem eigenen technischen Konto betrieben, das im Zielsystem als solches erkennbar ist, auf lesende Vorgänge beschränkt, wo es geht, und mit einer Vorabprüfung dort, wo es nicht geht.

Der zweite Preis ist der laufende: Ein Klickpfad ist keine Zusicherung. Ein umbenanntes Feld, ein zusätzlicher Zwischendialog, eine geänderte Reihenfolge — jede Oberflächenänderung des Zielsystems kann den Ablauf brechen, und sie kommt ohne Ankündigung. Bei einer Programmierschnittstelle merkt man einen Bruch an einem Fehlercode; bei einer Oberfläche merkt man ihn daran, dass die Aktion in die Leere klickt und der Agent trotzdem melden kann, sie sei erfolgt.

> **Merksatz:** Bei Oberflächenautomatisierung muss die Erfolgsprüfung aus einer **anderen** Quelle kommen als aus dem Klickpfad selbst — idealerweise aus einem lesenden Abruf, der den erwarteten Zustand bestätigt.

### Beobachtbarkeit endet nicht an der Sandbox-Grenze

Eine Umgebung, in die man nicht hineinsieht, ist ein blinder Fleck genau an der Stelle, an der ein Agent das meiste anrichten kann. Bei benannten Werkzeugen steht im Protokoll, was aufgerufen wurde. Bei Codeausführung steht dort im schlimmsten Fall „hat Code ausgeführt“.

- Jedes ausgeführte Kommando und jedes Skript im Wortlaut, nicht nur die Tatsache der Ausführung.
- Die Ausgaben, gekürzt aber vollständig genug, um einen Fehlschlag nachvollziehen zu können.
- Die Liste der hochgeladenen und der zurückgegebenen Dateien mit Größe und Prüfsumme.
- Bei erlaubtem Netzzugang jede ausgehende Verbindung mit Ziel — das ist der Datensatz, aus dem ein Exfiltrationsversuch später erkennbar wird.

Diese vier Angaben sind der Unterschied zwischen einem Vorfall, dessen Wirkungsradius man bestimmen kann, und einem, bei dem man vorsichtshalber annehmen muss, dass alles Erreichbare betroffen war.

Die Aufzeichnung hat eine Nebenwirkung, die vor der Einführung entschieden werden muss: Ein Kommando im Wortlaut kann Zugangsdaten enthalten, und eine Ausgabe kann personenbezogene Daten enthalten. Das Protokoll wird damit selbst zu einer Kopie schützenswerter Inhalte. Übliche Behandlung sind Redaktion bekannter Muster beim Schreiben, eine kürzere Aufbewahrung als für gewöhnliche Betriebsprotokolle und ein engerer Leserkreis als für den Rest der Telemetrie.

> **Preis der richtigen Wahl:** Vollständige Aufzeichnung macht den Wirkungsradius bestimmbar und erzeugt eine neue Stelle, an der sensible Daten liegen. Wer das nicht mitentscheidet, tauscht ein Diagnoseproblem gegen ein Governance-Problem.

### Was der Check prüft

- Für eine gegebene Umgebung benennen, welche der fünf Achsen begrenzt ist und welche nicht.
- Erkennen, dass Isolation mit einem Produktionstoken keine Isolation ist.
- Abhängigkeiten so bereitstellen, dass Reproduzierbarkeit und Netzisolation zusammen bestehen.
- Eine Umgebungskonfiguration lesen und die Zeile finden, die die Isolation aufhebt.
- Zwischen Programmierschnittstelle und Oberflächenautomatisierung entscheiden und die Zurechenbarkeit mitbedenken.
- Flüchtigen und fortgesetzten Zustand gegeneinander abwägen, inklusive des Verfallsfalls.
- Ressourcengrenzen setzen, die beim Greifen eine Beobachtung erzeugen statt einer Lücke.
- Einen Exfiltrationsverlauf lesen und das Bein der Kombination benennen, das entfernt werden muss.

Der gemeinsame Nenner: In diesem Modul gibt es keine Maßnahme, die im Prompt steht. Jede Kontrolle ist eine Eigenschaft der Umgebung — und deshalb prüfbar, bevor der erste Agent sie betritt.

## Quellen

- Anthropic — Code execution tool — https://platform.claude.com/docs/en/agents-and-tools/tool-use/code-execution-tool
- Simon Willison — The lethal trifecta for AI agents — https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
- OWASP GenAI Security Project — LLM01 Prompt Injection — https://genai.owasp.org/llmrisk/llm01-prompt-injection/
- OWASP GenAI Security Project — LLM06:2025 Excessive Agency — https://genai.owasp.org/llmrisk/llm062025-excessive-agency/
- Anthropic — Tool use with Claude — https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview
- OWASP GenAI Security Project — LLM10:2025 Unbounded Consumption — https://genai.owasp.org/llmrisk/llm102025-unbounded-consumption/