Excessive Agency: Rechteproblem im KI-Gewand

Excessive Agency belegt Platz LLM03 in den OWASP Top 10 for LLM Applications 2026 [1]. Für jeden, der IT-Infrastruktur betreibt, ist dies der entscheidende Eintrag: Anders als die meisten Punkte dieser Liste betrifft er primär das, womit Sie das Modell verbunden haben, und nur zu einem kleinen Teil das Modell selbst.

Das bestimmt maßgeblich, wer für die Behebung zuständig ist: Eine Halluzination ist ein Modellproblem. Eine Halluzination, die eine Datenbanktabelle löscht, ist ein Berechtigungsproblem.

Das Problem

Ein Betriebs-Assistent soll Speicherplatz auf einem Staging-Knoten freigeben. Man stattet ihn mit einem Shell-Werkzeug aus, weil das der schnellste Weg war, ihn produktiv zu machen. Die Zugangsdaten wurden kurzerhand vom Plattform-Team übernommen, da die Bereitstellung einer dedizierten Identität ein formales Ticket erfordert hätte. Er arbeitet unbeaufsichtigt, denn eine manuelle Bestätigung jedes Einzelschritts hätte den Geschwindigkeitsvorteil zunichtegemacht.

Das System interpretiert „Speicherplatz freigeben" sehr großzügig und löscht ein Verzeichnis, das die Staging-Umgebung gemeinsam mit anderen Diensten nutzte. Am Modell selbst lag dabei kein Defekt vor: Es tat exakt das, was ein Shell-Zugriff mit weitreichenden Berechtigungen und fehlender Freigabeschranke erlaubte.

Jeder einzelne Faktor dieses Vorfalls stand fest, noch bevor das Modell die erste Zeile ausführte: welche Werkzeuge bereitstanden, welche Systeme diese Werkzeuge erreichen konnten und ob vor der Ausführung eine Kontrollinstanz eingriff.

Warum es bei KI anders ist

Klassische Software fällt auf deterministische Weise aus. Ein Skript, das den Befehl rm -rf enthält, führt diesen aus, sobald definierte Bedingungen erfüllt sind. Diese Bedingungen lassen sich im Vorfeld prüfen. Ein Sprachmodell wählt seine Aktionen zur Laufzeit dynamisch aus den Schnittstellen aus, die Sie ihm bereitgestellt haben, und diese Auswahl basiert auf Texten, die potenziell von außerhalb Ihres Systems stammen.

OWASP unterteilt diese Problematik in drei grundlegende Ursachen, für die jeweils unterschiedliche Lösungen greifen.

Die erste Ursache ist übermäßige Funktionalität (Excessive Functionality): Das Modell kann Werkzeuge aufrufen, die für die konkrete Aufgabe überflüssig sind. Ein Assistent zur Textzusammenfassung benötigt kein Shell-Werkzeug, und ein Support-Bot braucht keinen API-Endpunkt zum Löschen von Datensätzen, nur weil die Client-Bibliothek diese Methode zufällig mitbrachte. Oft geschieht dies unbemerkt, weil bei der Entwicklung schlicht das angebunden wurde, was schnell verfügbar war.

Die zweite Ursache sind übermäßige Berechtigungen (Excessive Permission): Die Schnittstellen existieren aus nachvollziehbaren Gründen, agieren jedoch mit zu weitreichenden Rechten. Hier liegt die direkte Verantwortung der Infrastrukturteams: Der Agent erbt das Dienstkonto eines menschlichen Administrators oder läuft auf einer VM, deren Instanzrolle das gesamte Cloud-Konto abdeckt. Das Modell fragt eine einzelne Tabelle an, doch die Zugangsdaten öffnen die komplette Datenbank.

Die dritte Ursache ist übermäßige Autonomie (Excessive Autonomy): Aktionen werden vollautomatisch ohne menschliche Kontrolle ausgeführt. Für Routineaufgaben mag das gewollt sein; bei kritischen Operationen führt es dazu, dass irreversible Eingriffe stattfinden, nur weil ein probabilistisches System zu einem scheinbar plausiblen Schluss gelangt ist.

Die Version von 2026 verknüpft dies zudem mit agentenspezifischen Risiken, bei denen dieselbe Schwachstelle als Tool Misuse und als Identity and Privilege Abuse in den OWASP Top 10 for Agentic Applications geführt wird [2]. Die Formulierung variiert, die Kernfrage bleibt identisch: Welche Systeme kann diese Komponente erreichen und mit wessen Rechten handelt sie?

Was tatsächlich funktioniert

Setzen Sie Gegenmaßnahmen nach ihrem Grad an Determinismus um. Je deterministischer eine Schutzmaßnahme greift, desto verlässlicher schützt sie im Ernstfall.

Geben Sie jedem Agenten eine eigene Identität: Das verlangt ein dediziertes Dienstkonto statt des Accounts eines Administrators oder einer unbegrenzten Standardrolle des Hosts. Nur so bleiben ausgeführte Aktionen nachvollziehbar und Berechtigungen unabhängig von Personen einschränkbar. Unter Kubernetes bedeutet dies ein dediziertes ServiceAccount mit eigenem RoleBinding statt des Namespace-Standards. Im Cloud-Umfeld verlangt es eine explizit angenommene IAM-Rolle statt eines Instanzprofils, das jeder Prozess auf dem Server erbt.

Konkret: Unter Kubernetes darf der Pod des Agenten keinesfalls das default-ServiceAccount des Namespace nutzen. Das ist zwar der bequemste Weg, führt jedoch dazu, dass Workloads weit mehr Rechte besitzen als beabsichtigt. Der Agent erhält ein separates ServiceAccount, gebunden an eine Rolle, die exakt die benötigten Verben und Ressourcen im Ziel-Namespace aufführt. Kommuniziert der Agent mit Cloud-Diensten, muss er eine spezifische Rolle annehmen, statt das Instanzprofil des Worker-Knotens zu erben, das allen anderen Pods auf diesem Knoten gleichermaßen offensteht.

Der Test ist eindeutig: Wenn Sie die Frage „Welche Zugangsdaten hat der Agent genutzt und was genau erlauben diese Rechte?" nicht innerhalb einer Minute beantworten können, ist das Identitätskonzept fehlerhaft, unabhängig davon, wie die Tools konfiguriert sind.

Setzen Sie standardmäßig auf Nur-Lesen (Read-Only) und definieren Sie Schreibrechte als begründungspflichtige Ausnahme. Die meisten Agentenaufgaben bestehen in reiner Datenbeschaffung. Wo Schreiboperationen zwingend erforderlich sind, begrenzen Sie diese auf konkrete Ressourcen statt auf ganze Dienste: ein bestimmtes S3-Bucket-Präfix, eine definierte Tabelle, ein einzelner Namespace.

Reglementieren Sie ausgehende Netzwerkverbindungen (Egress). Ein Agent, der beliebige externe Server kontaktieren darf, kann ausgelesene Daten abfließen lassen. Durch Prompt-Injection-Angriffe wird dieses Risiko von einer theoretischen Möglichkeit zu einem realen Angriffsvektor. Eine Netzwerk-Policy mit einer strikten Allow-List arbeitet deterministisch und blockiert unberechtigte Verbindungen unabhängig von den Berechnungen des Sprachmodells.

Verlangen Sie verbindliche Bestätigungen für irreversible Eingriffe: Löschvorgänge, Finanztransaktionen, Zertifikatswechsel oder Datenexporte außerhalb Ihrer Systemgrenzen. Erzwingen Sie diese Freigabe auf der Werkzeugebene und nicht über den System-Prompt. Eine Anweisung im Prompt ist lediglich eine Bitte, und derselbe Textkanal, der sie transportiert, kann durch manipulierte Inhalte angewiesen werden, diese Regel zu ignorieren.

Richten Sie eine echte Notabschaltung ein: einen Mechanismus, der den Workload stoppt und Zugangsdaten sofort sperrt, ohne einen neuen Deployment-Prozess anstoßen zu müssen. Ein Deployment auf null Replikate zu skalieren stoppt neue Aufgaben, macht ein bereits ausgestelltes Token jedoch nicht ungültig. Eine wirksame Notabschaltung umfasst daher stets den Widerruf der Zugangsdaten. Testen Sie dieses Verfahren vorab und dokumentieren Sie verbindlich, wer berechtigt ist, den Schalter umzulegen. Ein Notaus-Schalter, dessen Bedienung um 3 Uhr nachts erst mühsam erfragt werden muss, ist wertlos.

Die ersten vier Maßnahmen betreffen reine Infrastrukturkonfiguration. Keine davon erfordert das Einverständnis des Sprachmodells, und genau deshalb sollten sie an erster Stelle stehen.

Was nicht funktioniert

Dem Modell nahezulegen, vorsichtig zu sein, bietet keinen Schutz. Anweisungen wie „Lösche nichts ohne vorherige Rückfrage" konkurrieren im Kontextfenster mit allen anderen Instruktionen, einschließlich jener, die über externe Dokumente eingeschleust werden. Im besten Fall formuliert man damit eine Präferenz, eine technische Durchsetzung findet nicht statt.

Ein einziges generisches Dienstkonto für alle Agenten auszustatten, hebt das Berechtigungsniveau jedes einzelnen Agenten auf die Stufe der mächtigsten Teilaufgabe an und zerstört im Schadensfall jede Nachvollziehbarkeit.

Freigabeprozesse, die niemand mehr aufmerksam prüft, sind eine weitere Schwachstelle. Wenn ein Bestätigungsdialog vierzigmal täglich aufpoppt, gewöhnen sich Mitarbeiter daran, ihn reflexartig zu bestätigen. Die Schutzwirkung funktioniert nur, wenn Freigaben selten und gezielt verlangt werden; treten sie permanent auf, ist der Zuschnitt der Werkzeuge fehlerhaft.

Der Glaube, dass reine Lese-Berechtigungen harmlos seien, ist ebenfalls ein Irrtum. Lesezugriff auf Speicherbereiche mit Zugangsdaten, Personendaten oder Kundendatensätzen eröffnet direkte Exfiltrationspfade. Das Prinzip der geringsten Rechte gilt für Leseoperationen gleichermaßen.

Die Liste verfügbarer Werkzeuge als statisch anzusehen, führt zu schleichender Ausweitung. Agenten-Frameworks machen das Hinzufügen neuer Schnittstellen trivial, wodurch die Angriffsfläche wächst, ohne dass dies dokumentiert wird. Jedes neue Tool verlangt denselben Prüfprozess wie ein neuer öffentlicher API-Endpunkt.

Verwechseln Sie schließlich Sandbox-Isolierung nicht mit Berechtigungsbegrenzung: Ein Container schränkt ein, worauf der Prozess auf dem Host-System zugreifen kann. Er verhindert jedoch nicht, dass ein im Container hinterlegtes Zugangsdaten-Token die Produktivdatenbank modifiziert. Beide Schutzebenen sind erforderlich, keine ersetzt die andere.

Wo Sie anfangen sollten

• Dokumentieren Sie jedes Werkzeug, das Ihre Agenten aufrufen können, und wer die Berechtigung erteilt hat. Diese Liste fällt meist länger aus als vermutet, und die Verantwortlichkeiten sind selten hinterlegt.
• Prüfen Sie die Identität, unter der die Agenten ausgeführt werden. Handelt es sich um geteilte Konten oder geerbte Host-Rollen, ist deren Ablösung die wirkungsvollste Sicherheitsmaßnahme in diesem Quartal.
• Identifizieren Sie alle irreversiblen Aktionen in der Tool-Liste und schalten Sie auf Werkzeugebene eine zwingende Bestätigung vor.
• Richten Sie eine strikte Egress-Allow-List für alle Systeme ein, die Inferenz- oder Agenten-Workloads ausführen.
• Proben Sie den Not-Aus: Stoppen Sie einen Agenten, widerrufen Sie sein Token und verifizieren Sie, dass kein Zugriff mehr möglich ist. Dieser Test dauert zehn Minuten und verwandelt eine theoretische Annahme in eine verlässliche Tatsache.

Excessive Agency steht weit oben auf der Risikoliste, weil Agenten den Schritt in den Produktivbetrieb vollzogen haben. Infrastrukturteams nutzen diese Kontrollmechanismen seit vielen Jahren. Neu ist lediglich, dass die zu beschränkende Entität ihre Entscheidungen dynamisch zur Laufzeit trifft. Genau deshalb müssen die Sicherheitsgrenzen außerhalb des Modells verankert sein.

Quellen

1. OWASP Top 10 for LLM Applications 2026, OWASP GenAI Security Project, veröffentlicht am 3. August 2026: https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/
2. OWASP Top 10 for Agentic Applications 2026, OWASP GenAI Security Project, veröffentlicht am 9. Dezember 2025: https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/