Ausgangslage
Wir setzen KI-Agenten ein, um Code zu schreiben, Tests laufen zu lassen und Daten auszuwerten, oft über Nacht. Die naheliegende Lösung, dem Agenten einen Zugang zum Server zu geben, scheidet aus: Auf denselben Servern laufen produktive Anwendungen, Datenbanken und Zugangsdaten.
Anforderungen
- Der Agent erreicht weder Produktionsdaten noch Zugangsdaten.
- Jeder Auftrag ist im Nachhinein belegbar, Wort für Wort.
- Nichts geht ohne Freigabe eines Menschen in den Hauptstand.
- Ein fehlerhafter oder manipulierter Lauf bleibt folgenlos.
Architektur
Das Schema oben zeigt den Weg einer Anfrage. Mit dem Schalter lässt sich vergleichen, wie es ohne Steuerung aussähe: Der Agent griffe direkt auf Register, ERP und Postfach zu.
- Steuerungsserver mit Positivliste. Der Agent spricht über das Model Context Protocol mit einem eigenen Dienst. Dieser kennt eine kurze Liste benannter Werkzeuge: Dateien im Projekt lesen, Auftrag ablegen, Lauf anfordern, Testsuite ausführen, Bericht lesen. Alles andere wird abgelehnt; Pfade zu Zugangsdaten sind gesperrt.
- Aufträge mit Prüfsumme. Ein Auftrag wird als Datei abgelegt, die Steuerung gibt eine Prüfsumme zurück. Ein Lauf startet nur mit passender Prüfsumme; geänderter Inhalt braucht einen neuen Namen.
- Getrennte Ausführung. Die Steuerung legt Anforderungen nur in eine Warteschlange. Ein getrennter Starter prüft sie und führt sie aus. Er verweigert den Dienst, wenn seine eigenen Dateien oder die Konfiguration nicht ausschließlich vom Systemverwalter änderbar sind.
- Arbeitszweige und Bericht. Agenten arbeiten auf eigenen Zweigen und schreiben einen Bericht. Übernommen wird nach Review; Veröffentlichen nach außen ist gesperrt.
- Tests in Wegwerf-Kopien. Die Testsuite läuft in einer frischen Arbeitskopie des Zweigs, die danach gelöscht wird.
- Abgeschottete Auswertungen. Analysejobs laufen unter einem eigenen Benutzer, mit Grenzen für Laufzeit, Speicher und Rechenzeit, ohne Zugriff auf interne Netze.
- Protokoll. Jede Anfrage, Ablehnung und Ausführung wird mitgeschrieben.
Bezug zu OWASP
Die drei Ursachen übermäßiger Handlungsmacht nach OWASP LLM06:2025 sind zu viele Funktionen, zu viele Rechte und zu viel Autonomie.1 Die Positivliste begrenzt die Funktionen, die getrennte Ausführung und die abgeschotteten Läufe die Rechte, Arbeitszweig und Freigabe die Autonomie.
Was wir gelernt haben
Bei einer eigenen Durchsicht fiel auf, dass über eine gemeinsame Benutzergruppe theoretisch Code des Starters hätte geändert werden können. Wir haben die Rechte getrennt und die Selbstprüfung des Starters eingeführt. Seitdem gilt: lieber nicht starten als unsicher starten.
Die zweite Lehre betrifft den Aufwand. Die Technik ist schlank; die eigentliche Arbeit liegt in der Frage, welche Werkzeuge ein Agent wirklich braucht. Jedes zusätzliche Werkzeug ist eine Tür, die man bewachen muss.
Übertragbar auf
Dasselbe Muster eignet sich überall, wo Agenten in bestehende Systeme greifen sollen: Belege vorbereiten, aber nicht buchen; Antworten entwerfen, aber nicht versenden; Verträge auswerten, aber nicht ändern. Der Agent schlägt vor, die Steuerung begrenzt, ein Mensch gibt frei.
Quellen
- OWASP Foundation: OWASP Top 10 for LLM Applications 2025, LLM06:2025 Excessive Agency.