Excessive Agency bei LLMs: Werkzeuge und Rechte zuschneiden

Excessive Agency (übermäßige Handlungsvollmacht) ist der Punkt LLM06 der OWASP-Liste. Die Ursache liegt selten im Modell und fast immer in seinem Handlungsspielraum: Schaden entsteht dort, wo eine Anwendung den Vorschlag eines Sprachmodells ohne Rückfrage ausführt. Schutz bietet das Prinzip der minimalen Rechte, durchgesetzt im angebundenen System und nicht im Modell.

Ein Nachbarpunkt ist hier aufgegangen

Die Nummer hat gewechselt, der Name nicht: Was 2023/24 als LLM08 geführt wurde, heißt in der Fassung 2025 unverändert Excessive Agency und trägt die Nummer LLM06. Gewichtiger als die Nummer ist ein Punkt, den es nicht mehr gibt. „Insecure Plugin Design“ stand 2023/24 als eigener Eintrag; 2025 führt OWASP Erweiterungen, Plugins und Werkzeuge unter Excessive Agency mit. Diese Seite ist deshalb länger geworden: Sie hat den Stoff unserer bisherigen Seite zu unsicherem Plugin-Design übernommen.

Die Zusammenlegung ist sachlich richtig. Ein Assistent, der zu viel darf, und eine Erweiterung, die zu viel darf, sind derselbe Fehler an zwei Stellen. Wer ihn behebt, ändert nicht den Prompt, sondern die Rechte.

Woraus Excessive Agency entsteht

OWASP nennt drei Ursachen, und keine davon liegt im Sprachmodell.

1. Zu viele Funktionen. Ein Agent verfügt über Werkzeuge, die seine Aufgabe nicht braucht. Wer ein Modell E-Mails lesen lassen will und ihm dafür eine Bibliothek gibt, die auch versenden und löschen kann, hat zwei Funktionen zu viel vergeben.
2. Zu weite Berechtigungen. Das Werkzeug arbeitet mit einem Zugang, der über die Aufgabe hinausreicht, etwa mit Schreibrechten auf einer Datenbank, aus der nur gelesen werden soll.
3. Zu viel Autonomie. Eine folgenreiche Handlung läuft ohne Bestätigung durch einen Menschen.

Ausgelöst wird der Schaden durch eine Halluzination des Modells oder durch einen Angriff. Eine Prompt Injection genügt, um dem Agenten eine fremde Anweisung unterzuschieben; eine über die Lieferkette manipulierte Erweiterung wirkt dauerhaft, weil niemand sie hinterfragt.

Wie sich das im Betrieb zeigt

Der Schaden ist selten spektakulär. Ein Assistent mit Zugriff auf die Dokumentenablage löscht eine Datei, weil er eine Anweisung falsch gelesen hat. Ein Agent im Einkauf verschickt eine Bestellung, die eine Zusammenfassung als Auftrag missverstanden hatte. Beides sind reguläre Aufrufe regulärer Funktionen, im Protokoll nicht von einem gewollten Vorgang zu unterscheiden. Je mehr Rechte an einem Werkzeug hängen, desto weiter reicht ein einzelner Fehlgriff.

Eine zweite Bauform fällt noch später auf: mehrere Werkzeuge, die einander ungeprüft vertrauen. Übergibt das eine, was es vom Modell bekommen hat, an das nächste, wandert eine untergeschobene Anweisung durch die Kette, bis sie auf ein Werkzeug mit ausreichenden Rechten trifft.

Was ein Werkzeug entgegennehmen darf

Die zu weite Vollmacht entsteht beim Zuschnitt der Schnittstelle. Drei Muster sind verbreitet und jedes gibt mehr her, als die Aufgabe verlangt:

• Ein einziges Freitextfeld statt benannter Parameter. Was hineingeschrieben wird, lässt sich weder typisieren noch begrenzen.
• Ein Konfigurationsstring statt einzelner Einstellungen. Damit lässt sich das Verhalten des Werkzeugs im Aufruf umschreiben.
• Rohes SQL oder Programmcode als Eingabe. Die Schnittstelle reicht damit die Rechte ihres eigenen Zugangs an den Aufrufer durch.

Die Gegenmaßnahme ist Zuschnitt: benannte Parameter mit Typ und Wertebereich, eine Funktion je Aufgabe statt eines Werkzeugs, das alles kann. Eine Funktion „Rechnung an Kunde X senden“ lässt sich prüfen, ein Werkzeug „führe folgendes Kommando aus“ nicht. Wo Freitext fachlich nötig ist, gehört er validiert, bevor er auf eine Methode trifft. OWASP verweist dafür auf den Application Security Verification Standard (ASVS).

Rechte, Freigaben und Protokoll

Rechte am Menschen festmachen, nicht am Agenten. Ein Werkzeug arbeitet im Sicherheitskontext dessen, der die Anfrage gestellt hat, und nicht mit einem Sammelkonto. Dann sieht ein Agent im Personalbereich genau die Akten, die der anfragende Sachbearbeiter ohnehin sehen darf.

Die Prüfung gehört ins Zielsystem. Eine Berechtigung, die nur im Prompt oder in der Werkzeugbeschreibung steht, ist eine Bitte. Verbindlich wird sie erst dort, wo die Handlung ausgeführt wird, also in der Datenbank, im ERP oder im Mailserver.

Menschliche Freigabe für alles, was nicht folgenlos ist. Zahlungen, Löschungen und Nachrichten nach außen bekommen eine Bestätigung. Das ist keine Rückkehr zur Handarbeit: Der Agent bereitet vor, ein Mensch gibt frei. Wichtig ist, dass die Freigabe zeigt, was tatsächlich passieren wird, und nicht die Zusammenfassung des Modells davon.

Jeden Werkzeugaufruf protokollieren. Wer Aufruf, Parameter und auslösende Anfrage festhält, kann eine Auffälligkeit später zuordnen. Ohne dieses Protokoll bleibt nach einem Vorfall nur die Vermutung.

Was die Anwendung aus der Modellantwort weiterverarbeitet, gehört zusätzlich geprüft. Das ist ein eigener Punkt der Liste, Improper Output Handling (OWASP LLM05), und er greift auch dann, wenn die Rechte sauber gesetzt sind.

Fazit

Excessive Agency ist der Punkt der Liste, an dem eine KI-Anwendung aufhört zu antworten und anfängt zu handeln. Die Frage vor dem Start lautet deshalb nicht, wie gut das Modell ist. Sie lautet, was im schlimmsten Fall passiert, wenn es sich irrt. Fällt die Antwort unangenehm aus, ist ein Recht zu viel vergeben.