KI-Agenten sicher betreiben: Positivliste statt Vollzugriff

KI-Agenten lesen nicht nur, sie handeln: Sie legen Dateien an, rufen Schnittstellen auf, schreiben Code oder buchen. Damit verschiebt sich die Sicherheitsfrage. Entscheidend ist weniger, wie klug ein Modell ist, sondern was es tun darf, wenn es sich irrt oder getäuscht wird.

Die OWASP-Liste der zehn wichtigsten Risiken für Anwendungen mit Sprachmodellen führt dieses Problem auch in der Fassung 2025 als eigenen Punkt: Excessive Agency (LLM06), übermäßige Handlungsmacht. Sie nennt drei Ursachen: ein Agent hat Zugriff auf Funktionen, die er für seine Aufgabe nicht braucht; er hat auf nachgelagerten Systemen Rechte, die er nicht braucht; und folgenreiche Aktionen werden nicht unabhängig geprüft und freigegeben.¹

Ein Agent sollte nur können, was er für seine Aufgabe braucht, und nichts Folgenreiches ohne Freigabe.

Sieben Bausteine

Aus unserem eigenen Betrieb, in dem Agenten über Nacht programmieren, testen und auswerten, haben sich sieben Bausteine bewährt. Keiner davon ist exotisch; wirksam werden sie erst zusammen.

1. Positivliste statt Verbotsliste

Der Agent bekommt keine Shell und keinen Generalschlüssel, sondern eine kurze Liste benannter Werkzeuge: Datei lesen, Auftrag ablegen, Testlauf anfordern. Alles, was nicht auf der Liste steht, wird abgelehnt. Das entspricht den OWASP-Empfehlungen, Erweiterungen und deren Funktionsumfang zu minimieren und offene Erweiterungen zu vermeiden.¹

2. Antrag und Ausführung trennen

Der Dienst, mit dem der Agent spricht, führt selbst nichts mit erhöhten Rechten aus. Er legt nur eine Anforderung in eine Warteschlange. Ein getrennter Starter prüft sie gegen Positivliste und Prüfsumme und führt sie dann aus. Wird der Agent manipuliert, erreicht er höchstens die Warteschlange.

3. Unveränderliche Aufträge

Jeder Auftrag wird als Datei mit Prüfsumme abgelegt. Gleicher Inhalt ist idempotent, geänderter Inhalt braucht einen neuen Namen. So lässt sich später belegen, was genau beauftragt war, und niemand ändert einen Auftrag unbemerkt zwischen Prüfung und Ausführung.

4. Arbeitszweig und Freigabe

Agenten arbeiten nie auf dem Hauptstand, sondern auf eigenen Zweigen, und schreiben einen Bericht. Übernommen wird erst nach Review durch einen Menschen. Das ist die OWASP-Empfehlung, bei folgenreichen Aktionen eine Zustimmung des Menschen zu verlangen, in ihrer einfachsten Form.¹

5. Abgeschottete Laufumgebung

Auswertungen laufen unter einem eigenen Benutzer, mit Grenzen für Laufzeit, Speicher und Rechenzeit und ohne Zugriff auf interne Netze. Ein fehlerhafter oder böswilliger Lauf kann so weder Daten abziehen noch den Server lahmlegen.

6. Protokoll jeder Aktion

Jede Anfrage, jede Ablehnung und jede Ausführung wird protokolliert. OWASP nennt Protokollierung und Überwachung ausdrücklich als Maßnahme, um Schäden zu begrenzen.¹ Im Alltag ist sie vor allem die Grundlage, um Fehler nachzuvollziehen, statt zu raten.

7. Im Zweifel nichts tun

Fehlt eine Voraussetzung, verweigert die Steuerung den Dienst, statt weiterzumachen. Bei uns prüft der Starter vor jedem Lauf, ob seine eigenen Dateien und die Konfiguration nur vom Systemverwalter geändert werden können. Diese Prüfung kam nach einer eigenen Durchsicht dazu, bei der wir einen theoretischen Weg über eine gemeinsame Benutzergruppe gefunden und geschlossen haben.

Was das kostet

Weniger, als man denkt. Die Steuerung ist ein schlanker Dienst mit einer Handvoll Werkzeugen; der größere Aufwand liegt in der Entscheidung, welche Werkzeuge ein Agent wirklich braucht. Genau diese Entscheidung ist Architekturarbeit, nicht Programmierung.

Fünf Fragen für Ihren nächsten Agenten

1. Welche Werkzeuge braucht der Agent für seine Aufgabe, und welche hat er darüber hinaus?
2. Mit welchen Rechten laufen diese Werkzeuge auf Ihren Systemen?
3. Welche seiner Aktionen sind folgenreich, und wer gibt sie frei?
4. Wo ist protokolliert, was er getan hat?
5. Was passiert, wenn eine Prüfung fehlschlägt: hält er an, oder macht er weiter?

Wie das in unserem Betrieb konkret aussieht, zeigt die Fallstudie zur Agentenarchitektur.

Quellen

1. OWASP Foundation: OWASP Top 10 for LLM Applications 2025, Abschnitt LLM06:2025 Excessive Agency.