Der vorige Artikel hat die Diagnose gestellt: Agenten scheitern nicht am Würfeln, sondern an drei Deklarationslücken — ein Aktionsraum, den niemand angegeben und vermessen hat (die Restmenge der unsicheren Steuerhandlungen, Unsafe Control Actions, UCA, ist offen), ein Lesekanal, der heimlich steuert (Prompt Injection als nicht deklarierter Kopplungskanal), und eine Erfolgsmeldung, die sich selbst ausstellt (selbstreferenzielle Bewertung).
Die naheliegende Rückfrage kam prompt: Schön analysiert — und was baue ich jetzt konkret?
Dieser Artikel zeigt eine Antwort.#
Er ist als Regelkatalog geschrieben, nicht als Essay: acht Regeln in MUSS-Form, jede mit der technischen Umsetzung und der Angabe, welche Grenze sie verschiebt — von der Prosa-Bitte zur konstruktiven Wand. Die Regeln sind keine Privaterfindung; sie decken sich mit dem, was sich 2025/2026 als Praxis-Konsens herausgebildet hat, unter anderem in den Behörden-Leitlinien zur Agentic-AI-Einführung und der OWASP Top 10 for Agentic Applications. Der Erlaubte Raum liefert nur das, was diesen Sammlungen fehlt: die Begründung, warum genau diese Maßnahmen wirken und andere nicht.
Das Problem in einem Absatz#
Ein Agent bekommt ein Ziel und Werkzeuge. Was er tun soll, steht im Prompt; was er tun kann, bestimmen die Werkzeuge — und die Differenz ist die UCA-Restmenge, in der jeder gemeldete Vorfall stattfindet: gelöschte Datenbanken, exfiltrierte Schlüssel, befolgte Anweisungen aus Dokumenten, die nur gelesen werden sollten. Der Prompt ist eine Bitte. Die folgenden Regeln bauen Wände.
Eine Vorbemerkung, die den häufigsten Denkfehler ausräumt: Eine Rückfrage ist keine Sandbox. Viele Agenten-Werkzeuge fragen vor jeder Aktion um Erlaubnis — das regelt die Zustimmung, nicht den Wirkradius. Wer fünfzig Rückfragen am Tag wegklickt, hat keine Kontrolle, sondern einen Reflex. Zustimmung und Begrenzung sind zwei verschiedene Mechanismen, und nur der zweite hält, wenn der erste ermüdet.
Der Regelkatalog#
Regel 1 — Werkzeuge: deny-by-default, Allowlist pro Aufgabe#
Der Agent MUSS mit null Werkzeugen starten; jedes Werkzeug wird pro Aufgabentyp explizit freigeschaltet. Ein Recherche-Agent bekommt Suche und Lesen — keine Shell. Ein Refactoring-Agent bekommt Dateizugriff auf ein Arbeitsverzeichnis — kein Postfach. Es DARF NICHT einen „Universal-Agenten" mit dem vollen Werkzeugkasten geben, der je nach Prompt mal dies, mal das tut.
Technisch: Werkzeug-Registrierung pro Task-Profil in der Orchestrierung (nicht im Prompt); bei MCP-Servern nur die benötigten Tools mounten, nicht den ganzen Server. Fremde Tool-Definitionen vor Einbindung lesen — die Berechtigungs-Fußabdrücke von Community-Tools passen erstaunlich oft nicht zu ihrem angegebenen Zweck.
Verschobene Grenze: Die physikalisch möglichen Einwirkungen (Physically possible Interference Actions, PIA) schrumpfen auf das Aufgabenprofil. Was nicht gemountet ist, existiert nicht.
Regel 2 — Credentials: kurzlebig, eng, pro Sitzung!#
Der Agent DARF NIE
- mit langlebigen, breiten Zugangsdaten laufen — kein Admin-Token,
- kein persönlicher API-Key des Entwicklers,
- keine Credentials im Environment des Agent-Prozesses.
- Jede Sitzung MUSS ein eigenes, zeitlich befristetes Token mit minimalem Scope erhalten.
Technisch:
- Scoped Tokens (OAuth2 mit engen Scopes, Datenbank-Rollen statt Superuser, Cloud-STS-Kurzzeit-Credentials)
- Ablauf in Minuten bis Stunden, nicht Monaten.
- Secrets liegen beim Tool-Executor, nie im Kontext des Modells, denn was im Kontext steht, kann per Injection abgefragt werden.
Verschobene Grenze: PIA pro Kanal — und zusätzlich Schadensbegrenzung in der Zeit: Ein erbeutetes Token ist beim Fund bereits abgelaufen.
Regel 3 — Schreiben ist ein anderes Werkzeug als Lesen#
Lese- und Schreibzugriff MÜSSEN getrennte Werkzeuge mit getrennten Credentials sein, und der Default ist read-only.
Ein Agent, der eine Datenbank abfragen soll, bekommt eine Rolle, die INSERT/UPDATE/DELETE nicht kennt! — nicht einen Hinweis im Prompt, es zu unterlassen.
Technisch:
- DB: eigene Read-Rolle (
GRANT SELECT) - Dateisystem: read-only-Mounts
- Schreibzugriff nur auf ein dediziertes Output-Verzeichnis
- APIs: GET-only-Token wo der Anbieter es hergibt.
Verschobene Grenze: Die klassische Doppelnatur des Erlaubten Raums — dieselbe Deklaration einmal als Absicht (Prompt: „nur lesen") und einmal als Konstruktion (Rolle: kann nur lesen). Nur die zweite Fassung zählt.
Regel 4 — Ausführung nur in Isolation#
Führt der Agent Code aus oder verarbeitet er fremde Inhalte, MUSS die Ausführung in einer isolierten Umgebung laufen: Container als Minimum, microVM (Firecracker u. ä.) oder gVisor, sobald nicht vertrauenswürdiger Code läuft oder mehrere Mandanten dieselbe Infrastruktur teilen. Der Host-Zugriff auf Dateisystem, Environment-Variablen und interne Netze DARF NICHT vererbt werden.
Technisch:
- Wegwerf-Umgebung pro Sitzung, kein Zustand zwischen Läufen
- keine gemounteten Home-Verzeichnisse
- keine SSH-Keys
- keine Cloud-Metadata-Endpoints erreichbar.
Die 2026 offengelegten Vorfälle — Prompt-Injection-zu-Host-RCE-Ketten, Sandbox-Escapes bei rein anwendungsseitigen Kontrollen — zeigen einheitlich dasselbe Muster: Anwendungslogik als einzige Schutzschicht fällt.
Verschobene Grenze: PIA des gesamten Ausführungskontexts. Der schlimmste Fall wird von „Host kompromittiert" zu „Wegwerf-Container kompromittiert".
Regel 5 — Netzwerk: Egress-Allowlist, Rest blockiert#
Ausgehender Netzverkehr MUSS auf eine explizite Ziel-Allowlist beschränkt sein; alles andere wird blockiert und alarmiert. Ein Agent mit offenem Internetzugang und einem einzigen erreichbaren Secret ist eine Exfiltrations-Maschine, die nur auf den passenden Prompt wartet.
Technisch: Egress-Proxy oder Netzwerk-Policy (Kubernetes NetworkPolicy, nftables, Cloud-Security-Groups) mit deny-by-default; DNS ebenfalls einschränken (Exfiltration über DNS-Tunnel ist Standard-Repertoire). Alarm auf jeden geblockten Versuch — geblockter Egress ist das früheste Injection-Signal, das es gibt.
Verschobene Grenze: PIA des Netzkanals — und zugleich die wirksamste Entschärfung des Kopplungskanals: Eine Injection, die „sende X an evil.example" verlangt, läuft gegen eine Wand statt gegen eine Bitte.
Regel 6 — Die Taint-Regel: fremder Inhalt entzieht Schreibrechte#
Sobald ein Agent in einer Sitzung nicht vertrauenswürdige Inhalte gelesen hat — Webseiten, E-Mails, hochgeladene Dokumente, fremde Repos — DARF dieselbe Sitzung KEINE schreibenden oder sendenden Aktionen auf sensible Ziele mehr ausführen. Lesen oder Schreiben, nicht beides im selben Kontext.
Technisch: Zwei-Stufen-Architektur: Ein lesender Agent extrahiert und strukturiert (Ausgabe: Daten, kein Freitext-Befehl); ein zweiter, schreibender Agent arbeitet ausschließlich auf dieser strukturierten Ausgabe und sieht den Fremdinhalt nie. Wo die Trennung nicht möglich ist: Schreib-Werkzeuge nach dem ersten Fremd-Read hart deaktivieren (Session-Flag im Orchestrator, nicht im Prompt).
Verschobene Grenze: Das ist die direkte Antwort auf Konstruktionsfehler 1 aus Teil 1. Der Kopplungskanal — Daten wirken als Befehl — lässt sich in heutiger Modellarchitektur nicht schließen; aber er lässt sich in einen Raum münden lassen, dessen PIA nichts Gefährliches mehr enthält. Die Injection findet weiter statt. Sie bewirkt nichts mehr.
Regel 7 — Menschliche Freigabe an jedem irreversiblen Punkt#
Vor jeder Aktion, die nicht per Knopfdruck rückgängig zu machen ist, MUSS ein Mensch freigeben — mit Sicht auf die konkrete Aktion, nicht auf eine Zusammenfassung des Agenten. Die Liste der irreversiblen Punkte wird vorab deklariert, nicht situativ entschieden: Löschen, Senden nach außen, Deployments, Zahlungen, Rechtevergabe.
Technisch: Gate im Orchestrator (Aktion wird geparkt, Mensch bestätigt das Diff / den Empfänger / das Statement, nicht die Absichtserklärung). Wichtig gegen die Ermüdung aus der Vorbemerkung: Gates nur an den deklarierten irreversiblen Punkten — wer alles gatet, gatet garnichts.
Verschobene Grenze: Ein deklarierter Übergabepunkt im Sinne der gewollten Einwirkungen (Desired Interference Actions, DIA): Der Zielwechsel „Wirkung nach außen" ist nur mit expliziter menschlicher Handlung erreichbar.
Regel 8 — Abnahme extern, niemals Selbstauskunft#
Der Erfolg einer Agenten-Aufgabe MUSS von einer Instanz festgestellt werden, die nicht der Agent ist: Assertions, Schema-Validierung, Testlauf, ein unabhängiger Prüf-Agent mit eigenem Kontext — oder der Mensch. Die Meldung „erledigt" des ausführenden Agenten ist ein Signal zum Prüfen, DARF aber NICHT als Prüfergebnis gewertet werden. Zusätzlich MUSS jede Sitzung ein Schritt- und Budget-Limit tragen, und ein fehlgeschlagener Schritt führt zum Stopp — nicht zur Neuinterpretation des Ziels.
Technisch: Harte Erfolgs-Kriterien vor Start definieren (Exit-Codes, Schema, erwartete Artefakte); vollständiges Audit-Log aller Tool-Calls mit Parametern (das Log ist zugleich die Forensik-Grundlage für Regel 5 und 7); Alarm bei Limit-Erreichen statt stillem Weiterlaufen.
Verschobene Grenze: Das ist die Antwort auf Konstruktionsfehler 2. Prüfung 1 des Erlaubten Raums — Ist-Verlauf ⊆ Schlauch — wird erst dadurch zu einer Messung, dass der Ist-Verlauf vom geprüften System kommt und die Prüfung von außen. Vorher ist sie eine Selbstauskunft mit guter Formulierung.
Warum acht Regeln und nicht eine#
Die Regeln sind nicht unabhängig — sie sind gestaffelt, und das ist Absicht. Eine Injection, die die Prompt-Ebene überwindet (was einzukalkulieren ist), trifft auf eine Werkzeug-Allowlist (Regel 1). Kommt sie durch, fehlen ihr die Schreibrechte (Regel 3, 6). Findet sie doch einen Schreibpfad, endet er im Wegwerf-Container (Regel 4) ohne Egress (Regel 5), vor einem menschlichen Gate (Regel 7) — und das Ergebnis besteht die externe Abnahme nicht (Regel 8). Jede Schicht darf einzeln fallen; gefährlich wird es erst, wenn alle gleichzeitig fallen. Das ist keine neue Idee, sondern Defense-in-Depth — angewandt auf ein System, dessen innerste Schicht (das Modell selbst) prinzipbedingt nicht abdichtbar ist.
Und die Gegenprobe aus Teil 1 gilt unverändert: Keine dieser acht Regeln steht im Prompt. Alle acht stehen in der Infrastruktur. Wer seine Agenten-Sicherheit daran misst, wie ausführlich die Verhaltensregeln im System-Prompt formuliert sind, misst die Höflichkeit der Bitte — nicht die Höhe der Wand.