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.

Agenten sind Identitäten

Ein Agent, der auf Systeme zugreift, braucht ein eigenes Konto. Auf dieses Konto laufen seine Rechteliste und sein Protokoll, und es trägt einen Namen, der den Agenten erkennen lässt. Ein geteiltes Dienstkonto scheidet dafür ebenso aus wie das Konto eines Mitarbeiters, dessen Rechte der Agent mitbenutzt.

Fachlich heißen solche Konten Non-Human Identities (nicht-menschliche Identitäten). Das Agentenkonto steht nicht im Widerspruch zum Grundsatz oben, die Rechte am anfragenden Menschen festzumachen. Das Agentenkonto legt fest, was der Agent überhaupt erreichen kann. Der Sicherheitskontext des Menschen grenzt das für jede einzelne Anfrage weiter ein. Ausgeführt wird nur, was beide erlauben.

Der Nutzen zeigt sich nach einem Vorfall. Im Protokoll steht, welcher Agent eine Datei gelöscht hat, und nicht bloß, dass es das Sammelkonto der Automatisierung war. Fällt ein Agent auf, lässt sich sein Konto sperren, ohne dass ein Mitarbeiter oder ein anderer Ablauf seinen Zugang verliert. Und wer prüfen will, was ein Agent darf, liest eine Rechteliste, die nur zu diesem Agenten gehört.

Dass fehlende Zugriffskontrolle eher die Regel als die Ausnahme ist, zeigt der Cost of a Data Breach Report 2026 von IBM und Ponemon Institute: „Rund jede fünfte untersuchte Organisation meldete einen Vorfall, der sich gegen KI-Modelle oder KI-Anwendungen richtete; 92 % dieser Organisationen hatten keine ordentliche Zugriffskontrolle für ihre KI“. Weitere geprüfte Kennzahlen stehen im Lagebild KI-Sicherheit.

Berechtigungen mit Ablaufdatum

Ein Agent bekommt seine Rechte für eine Aufgabe und für einen Lauf, nicht auf Dauer. Technisch heißt das: Er erhält zum Start ein Token mit festem Geltungsbereich und kurzer Laufzeit, und mit dem Ende des Laufs verfällt es. Ein Agent, der Rechnungen vorbereitet, hält dann für diese eine Aufgabe Lesezugriff auf die offenen Posten, aber keinen bleibenden Schlüssel zur Buchhaltung.

Agenten werden für eine Aufgabe gestartet und danach beendet, manche für einen einzigen Arbeitsschritt. Bleiben ihre Rechte bestehen, sammeln sich Zugänge an, die niemand mehr braucht und niemand mehr prüft. Die Rechte müssen also mit dem Agenten entstehen und mit ihm verschwinden.

Wer jeden Zugang von Hand beantragt und wieder entzieht, kommt bei Agenten nicht hinterher, die mehrmals am Tag neu starten. Vergabe und Entzug gehören deshalb automatisiert, nach einer festen Regel je Anwendung. Ein guter Ort für diese Regel ist das KI-Gateway vor den Modellen, wo die Allowlist der Werkzeuge je Anwendung liegt: Rechte zentral im Gateway steuern.

Freigabe nach Risikostufe

Nicht jede Aktion eines Agenten braucht einen Menschen, der sie bestätigt. Wie viel Kontrolle nötig ist, hängt davon ab, was die Aktion anrichten kann, wenn sie falsch ist. Bewährt hat sich eine Einteilung in Stufen:

• Lesen und zusammenfassen. Läuft ohne Freigabe und wird protokolliert.
• Schreiben in interne Systeme, etwa ein Datensatz im CRM oder ein Ticket. Läuft mit Protokoll, das jemand täglich sichtet. Ändert der Agent viele Datensätze auf einmal, braucht die Massenänderung eine Freigabe.
• Nach außen senden, Geld bewegen, löschen. Hier gibt immer ein Mensch frei, als Human in the Loop. Was er dabei zu sehen bekommen muss, steht oben unter „Menschliche Freigabe für alles, was nicht folgenlos ist“.

Die Freigabe braucht es auch dann, wenn gerade niemand aktiv angreift. Ein Agent, der fremde E-Mails oder Dokumente liest, kann eine darin versteckte Anweisung ausführen, ohne dass irgendjemand etwas anklickt. Wie das abläuft, beschreibt die Seite zu Zero-Click-Angriffen auf KI-Agenten.

Neben Rechten und Freigaben gehört geprüft, was die Anwendung aus der Modellantwort weiterverarbeitet. 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.

Weiterführend

• Zero-Click Attacks: AI Agents and the Next Cybersecurity Challenge, IBM Technology, 30.9.2025
• How Developers Secure AI-Generated Code: 5 Security Best Practices, IBM Technology, 14.9.2026
• 2026 Cost of a Data Breach Report: AI Is Changing Cybersecurity, IBM Technology, 30.7.2026