Rechte und Freigaben für KI-Agenten: Excessive Agency vermeiden

Von Wladimir Neuberger · Aktualisiert 27.10.2026

Was „Excessive Agency“ bedeutet

Entwickler geben Systemen mit Sprachmodellen häufig Handlungsfähigkeit: Sie können Funktionen aufrufen oder über Erweiterungen mit anderen Systemen interagieren. Anbieter nennen diese Erweiterungen Tools, Skills oder Plug-ins. In Agentensystemen kann sogar die Auswahl der Erweiterung dem Modell überlassen sein, das auf Grundlage früherer Ausgaben immer wieder neue Aufrufe macht.

Excessive Agency (LLM06:2025 in der OWASP-Liste der zehn größten Risiken für Anwendungen mit Sprachmodellen) beschreibt die Schwachstelle, die schädliche Aktionen als Reaktion auf unerwartete, mehrdeutige oder manipulierte Modellausgaben ermöglicht, unabhängig davon, was die Fehlfunktion ausgelöst hat. OWASP nennt als Auslöser unter anderem erfundene Inhalte (Halluzinationen) und direkte oder indirekte Prompt Injection, auch durch eine kompromittierte Erweiterung oder einen kompromittierten Partner-Agenten. Die Folgen können Vertraulichkeit, Integrität und Verfügbarkeit betreffen, je nachdem, welche Systeme der Agent erreicht.

Drei Ursachen

OWASP führt Excessive Agency auf drei Wurzeln zurück. Wer sie kennt, findet in der eigenen Umgebung schnell die Stellen, an denen nachgebessert werden muss.

• Übermäßige Funktionalität: Erweiterungen enthalten Fähigkeiten, die die Anwendung nicht braucht, etwa ein Dokumente-Lesewerkzeug, das auch ändern und löschen kann, oder ein nicht mehr benötigtes Testwerkzeug, das dem Agenten weiter zur Verfügung steht.
• Übermäßige Berechtigungen: Erweiterungen haben in nachgelagerten Systemen mehr Zugriff als nötig, zum Beispiel ein lesendes Werkzeug mit einer Datenbankidentität, die auch ändern, einfügen und löschen darf, oder ein generisches Hochprivileg-Konto, das auf die Dateien aller Nutzer zugreifen kann.
• Übermäßige Autonomie: Das System führt folgenreiche Aktionen ohne unabhängige Prüfung oder Freigabe aus, etwa das Löschen von Nutzerdokumenten ohne Rückfrage.

Das Beispielszenario von OWASP: Ein persönlicher Assistent mit Postfachzugriff soll eingehende Mails nur zusammenfassen, kann aber auch senden. Eine in einer Mail versteckte indirekte Prompt Injection könnte ihn anweisen, den Posteingang nach sensiblen Daten zu durchsuchen und sie weiterzuleiten. OWASP empfiehlt dagegen, das Werkzeug auf Lesen zu beschränken, einen schreibgeschützten OAuth-Zugriff zu nutzen und jede entworfene Mail vom Nutzer manuell versenden zu lassen.

Funktionen und Berechtigungen begrenzen

Die folgenden fünf Maßnahmen entsprechen den Empfehlungen von OWASP zu LLM06:2025. Sie wirken, weil sie nicht vom Verhalten des Modells abhängen.

• Erweiterungen minimieren: Nur anbieten, was der Agent unbedingt braucht. Wenn das System keinen Webabruf benötigt, bekommt es kein URL-Abrufwerkzeug.
• Funktionsumfang minimieren: Ein Werkzeug zum Zusammenfassen von E-Mails liest Mails, es löscht oder versendet sie nicht.
• Offene Werkzeuge vermeiden: Granulare Werkzeuge sind sicherer als allgemeine wie Shell- oder URL-Zugriff. Ein eigenes Werkzeug zum Schreiben von Dateien ist sicherer als eine Shell, mit der man Dateien schreibt.
• Berechtigungen minimieren: Ein Empfehlungs-Agent, der eine Produkttabelle liest, darf weder Daten ändern noch andere Tabellen sehen. Durchgesetzt wird das über die Rechte der Datenbankidentität, nicht über den Prompt.
• Im Kontext des Nutzers ausführen: Die Autorisierung und der Umfang jedes Nutzers werden mitgeführt, sodass Aktionen mit dessen minimalen Rechten laufen, zum Beispiel über OAuth mit dem engstmöglichen Geltungsbereich.

Freigaben und Autonomie

Rechte beantworten die Frage, was ein Agent kann. Freigaben beantworten, was er allein tun darf. OWASP empfiehlt, bei folgenreichen Aktionen den Menschen einzubinden, entweder im nachgelagerten System oder in der Erweiterung selbst; ein Werkzeug zum Veröffentlichen von Beiträgen sollte den Nutzer zuvor um Zustimmung bitten. Ebenso wichtig ist die vollständige Vermittlung: Die Autorisierung wird im nachgelagerten System durchgesetzt, statt dem Modell zu überlassen, ob eine Aktion erlaubt ist. Jede Anfrage einer Erweiterung wird gegen die Sicherheitsrichtlinie geprüft.

Als Orientierung, wann Freigaben nötig sind, taugt die „Agents Rule of Two“, die Meta im Oktober 2025 vorgeschlagen hat. Danach soll ein Agent in einer Sitzung höchstens zwei von drei Eigenschaften erfüllen: nicht vertrauenswürdige Eingaben verarbeiten, auf sensible Systeme oder private Daten zugreifen, Zustände ändern oder nach außen kommunizieren. Braucht eine Aufgabe alle drei, soll der Agent nicht autonom laufen, sondern beaufsichtigt werden, etwa durch menschliche Freigabe. Auch das NCSC rät, deterministische, nicht auf dem Modell beruhende Schutzmaßnahmen zu bevorzugen, die Aktionen begrenzen, statt sich nur auf das Filtern von Eingaben zu verlassen.

• Unsere Empfehlung: Als freigabepflichtig gelten Aktionen, die sich nicht zurücknehmen lassen, also Löschen, Bezahlen, Versand an Externe und Änderungen an Zugängen.
• Unsere Empfehlung: Die Freigabe zeigt der prüfenden Person, was genau passiert, etwa Empfänger, Betrag oder betroffene Datensätze, und nicht nur „Aktion bestätigen“.
• Unsere Empfehlung: Die Freigabe wird in der Anwendung erzwungen. Eine Anweisung im Prompt, vorher zu fragen, ersetzt sie nicht.

Entscheidend ist, wo die Grenze durchgesetzt wird: im Zielsystem und in der Anwendung, nicht in der Entscheidung des Modells.

Protokollieren, bremsen, abschalten

OWASP führt zwei Maßnahmen ausdrücklich als solche auf, die Excessive Agency nicht verhindern, aber den Schaden begrenzen. Die dritte Maßnahme ergänzen wir als Empfehlung.

• Protokollierung und Überwachung: Aktivitäten der Erweiterungen und der nachgelagerten Systeme aufzeichnen, damit unerwünschte Aktionen erkannt werden und man darauf reagieren kann. Das NCSC nennt dafür unter anderem Werkzeug- und Schnittstellenaufrufe sowie fehlgeschlagene Aufrufe, die auf Abtasten hindeuten können.
• Ratenbegrenzung: Unerwünschte Aktionen werden verlangsamt, damit Zeit bleibt, sie zu entdecken, bevor größerer Schaden entsteht. Beim Mailbeispiel von OWASP kann das den Schaden der Versandschnittstelle verringern.
• Not-Aus (unsere Empfehlung): Es braucht einen dokumentierten Weg, einen Agenten sofort zu stoppen und seine Zugangsdaten zu sperren. Prüfen Sie ihn, bevor Sie ihn brauchen.

Wo Sie anfangen

Wir bauen selbst KI-Agenten, etwa CITT, einen Sprach-Agenten mit Anbindung an Kalender und CRM. Die folgende Reihenfolge ist unsere Empfehlung für jedes Agentenprojekt, keine Quellenaussage.

• Alle Werkzeuge und Zugangsdaten jedes Agenten auflisten und für jedes Werkzeug fragen: Braucht die Aufgabe das wirklich?
• Zugriffe auf das Minimum zurücksetzen: lesend, wo Lesen genügt, mit eigener Identität pro Agent und möglichst im Kontext des jeweiligen Nutzers.
• Festlegen, welche Aktionen eine Freigabe verlangen, und diese Freigabe in der Anwendung erzwingen.
• Protokollierung, Ratenbegrenzung und Not-Aus einrichten und den Ablauf einmal durchspielen.

Häufige Fragen

Quellen

• OWASP GenAI Security Project — LLM06:2025 Excessive Agency
• OWASP GenAI Security Project — Top 10 for LLM Applications (Ausgabe 2025)
• OWASP GenAI Security Project — LLM01:2025 Prompt Injection
• UK National Cyber Security Centre (NCSC) — Prompt injection is not SQL injection (it may be worse), 8. Dezember 2025
• Simon Willison — New prompt injection papers: Agents Rule of Two and The Attacker Moves Second, 2. November 2025

Die Einordnung beruht auf den genannten Veröffentlichungen. Prüfen Sie bei Entscheidungen die Originalquelle.

Weiterlesen

• Prompt Injection bei KI-Agenten: Warum Filter nicht reichen und was wirklich schützt
• MCP-Sicherheit: KI-Agenten und ihre Tool-Anbindungen absichern
• Cyber Security im Agentenzeitalter: Was sich ändert, wenn KI selbst handelt