Excessive Agency: Wenn KI-Agenten zu viel dürfen (und warum das kein „Modellproblem“ ist)

KI‑Agenten wirken oft wie der nächste logische Schritt nach Chatbots: Sie planen, entscheiden und handeln. Nicht nur in einer Oberfläche, sondern über Tools und Schnittstellen in echten Systemen. Genau hier entsteht ein Risikofeld, das OWASP als „Excessive Agency“ klassifiziert: Eine LLM‑Komponente bekommt zu viel Autonomie, zu viele Funktionen oder zu breite Berechtigungen und kann dadurch bei Fehlverhalten schädliche Aktionen auslösen.

Das Entscheidende: Die Schwachstelle steckt nicht primär im Modell, sondern in der Architektur und den Capability‑Entscheidungen: Welche Aktionen kann der Agent ausführen? Mit welchen Credentials? Gegen welche Zielsysteme? Und unter welchen Bedingungen? OWASP beschreibt Excessive Agency explizit als Vulnerability, die „damaging actions“ ermöglicht, wenn der Agent auf unerwartete, mehrdeutige oder manipulierte Ausgaben reagiert unabhängig davon, ob die Ursache Halluzinationen, Prompt Injection oder ein Tool‑Fehler ist.

Warum „Excessive Agency“ die Schadenshöhe multipliziert

In klassischen IT‑Systemen begrenzen wir Schadensradius durch Least Privilege, Rollen, Separation of Duties und Freigabeprozesse. NIST formuliert das als Grundprinzip: Prozesse (und Nutzer/„Prozesse im Auftrag von Nutzern“) sollen nur die autorisierten Zugriffe erhalten, die zur Aufgabenerfüllung notwendig sind.

Bei LLM‑Agenten ist dieses Prinzip noch kritischer, weil LLM‑Entscheidungen probabilistisch sind: Ein Agent kann in vielen Fällen „richtig“ handeln und trotzdem in Randfällen riskant reagieren. OWASP betont, dass Excessive Agency durch mehrere Trigger ausgelöst werden kann darunter Halluzinationen/Confabulation, direkte oder indirekte Prompt Injection oder kompromittierte Extensions/Tools.

Warum wird das zum Multiplikator?Prompt Injection ist bei einem reinen Chatbot ärgerlich, aber die Schadensdecke ist meist begrenzt (z. B. falsche Antworten). Sobald der Agent Tools bedienen darf E‑Mails versenden, Dateien ändern, Tickets schließen, Datenbankeinträge mutieren wird Prompt Injection zu einem Business‑Logic‑ und Automationsproblem. OWASP nennt als zentrale Auswirkung von Prompt Injection explizit „unauthorized actions via connected tools and APIs“.

Was OWASP unter „Excessive Agency“ konkret versteht

OWASP beschreibt Agenten‑Agency als Fähigkeit, Funktionen aufzurufen oder über Extensions/Tools/Plugins mit anderen Systemen zu interagieren. Die Root Causes nennt OWASP in drei Kategorien:

1. Excessive Functionality, der Agent hat Tools, die er für den Use Case nicht braucht.

2. Excessive Permissions, die Token/Keys sind zu breit (Scope, Tenant‑Weite, Admin‑Level).

3. Excessive Autonomy, der Agent darf ohne ausreichende Checks irreversible Aktionen ausführen.

Ein typisches Attack‑Pattern (auch in gängigen Security‑Guides beschrieben): Der Agent soll lesen, bekommt aber lesen + löschen + hochladen und ein Angreifer steuert über manipulierten Input eine destruktive Aktion an. Genau dieses Muster taucht als Beispiel in einer Operations‑Guidance zum Thema „Excessive agency“ auf (Dokumentenmanagement: Lesen gedacht, aber Delete möglich → Datenverlust).

Der „Lethal Trifecta“-Gedanke: Tools + untrusted input + sensitive access

Sicherheitspraktiker fassen den Kern der Gefahr oft so zusammen: (1) Toolzugriff, (2) Verarbeitung untrusted Input (Web, Mails, Tickets, Dokumente) und (3) sensitive Credentials in einem System, wenn alle drei zusammenkommen, wird Prompt Injection oder Kontextmanipulation schnell kritisch. Dass Prompt Injection besonders gefährlich wird, wenn Modelle externen Content verarbeiten (indirekte Prompt Injection) und dabei Tool Calls auslösen können, ist im OWASP Prompt Injection Cheat Sheet explizit beschrieben.

Das ist auch der Grund, warum moderne Agenten‑Sicherheit weniger „Prompt Engineering“ ist und mehr Architektur: selbst wenn Prompt Injection nie vollständig verschwindet, muss sie nicht zu schädlichen Tool‑Actions führen dürfen. OWASP formuliert das sinngemäß als Trennung von „Output Handling“ vs. „Agency/Permissions“: Output‑Probleme werden kritisch, wenn sie in echte Operationen übersetzen.

Capability Design statt „Vollzugriff“: Die Bausteine einer sicheren Agenten‑Architektur

Die Gegenstrategie ist kein einzelner „Trick“, sondern konsequentes Capability Design: Tools und Berechtigungen so zu modellieren, dass der Agent nur das kann, was er wirklich können muss und riskante Aktionen gated sind.

Granulare Berechtigungen (Scope‑Design)

Microsoft beschreibt für Graph‑Apps sehr klar, warum Granularität entscheidend ist: Graph‑Berechtigungen sind fein granuliert; Apps sollen nur die wenigsten, least‑privileged Permissions anfragen. Wichtig ist zudem der Unterschied:

• Delegated Access: App handelt „im Auftrag“ eines eingeloggten Users, und der Zugriff ist durch User‑Rechte + Scopes begrenzt.

• Application (App‑only) Access: App handelt mit eigener Identität ohne User; das trägt höhere Privacy‑/Risikoaspekte, weil es nicht auf einen User‑Kontext begrenzt ist.

Agenten‑Implikation: Wenn dein Agent E‑Mails oder Files im M365‑Kontext bearbeiten soll, ist Delegated oft der natürliche „Least‑Privilege‑Pfad“ App‑only ist mächtig, aber eben auch riskanter, weil der Blast Radius größer werden kann.

„Read statt Write“, „Draft statt Send“, „Query statt Mutation“

Diese Muster sind nicht nur „Best Practice“, sondern folgen direkt aus Least Privilege: Die Berechtigung muss so klein sein, dass ein Fehlverhalten keine irreversiblen Aktionen ausführen kann. NISTs Least‑Privilege‑Kontrolle AC‑6 zielt genau darauf ab, nur die Zugriffe zu erlauben, die zur Aufgabe notwendig sind (auch für Prozesse im Auftrag von Nutzern).

Praktisch heißt das:

• E‑Mail: Entwurf erzeugen statt Senden

• Files: Lesen statt Ändern/Löschen

• Tickets: Vorschlag statt Statuswechsel

• Daten: SELECT/GET statt UPDATE/DELETE

  
  

Consent & Human-in-the-Loop für riskante Aktionen

Wenn eine Aktion riskant oder irreversibel ist, sollte sie explizite Freigabe benötigen. Das ist ein Standardmuster in Agenten‑SDKs und Integrationsguides: „Pause and resume“ bzw. „needsApproval“ für sensitive Tool‑Executions. Wichtig dabei: Die Approval‑Logik gehört in die Tool‑Implementierung (nicht nur in den Prompt), damit ein Prompt‑Hijack die Kontrolle nicht aushebeln kann.

Rate Limits, Zielsystem- und Datenklassen‑Constraints

OWASP empfiehlt als generelle Strategie, Extensions/Tools auf das notwendige Minimum zu begrenzen und defense‑in‑depth zu betreiben. Daraus abgeleitet sind technische Guardrails:

• Rate‑Limits pro Capability (z. B. max. 3 Mails/Std.)

• Allowlist von Zielsystemen/Endpoints (kein „wildes“ HTTP)

• Datenklassen‑Policy (PII/Secrets: nie schreiben, nur maskiert lesen)

• Zeit-/Kontextbindung (Token kurzlebig, nur für aktuellen Run gültig)

Ein praktikables Vorgehensmodell: Von „Agent kann alles“ zu „Agent kann sicher“

Hier ist ein Vorgehen, das sich an etablierten Security‑Rahmen orientiert und sich gut in Enterprise‑Projekte übersetzen lässt:

Schritt 1: Agent‑Threat‑Modeling auf Tool‑Ebene

• Liste alle Tools/Skills auf, die der Agent nutzen kann (inkl. „harmloser“ Admin‑Tools).

• Markiere untrusted Inputs (Webseiten, Mails, Tickets, Dokumente, RAG‑Quellen). OWASP nennt indirekte Prompt Injection explizit als Risiko, wenn externe Inhalte in den Kontext gelangen.

Schritt 2: Capability‑Matrix + Least Privilege Mapping

Baue eine Matrix: Use Case → Capability → Permission/Scope → Datenklasse → Risiko → Gate.

• Für Microsoft‑Integrationen: wähle die kleinstmöglichen Graph‑Permissions (delegated bevorzugen; app‑only nur wenn nötig).

• Folge NIST‑Least‑Privilege: nur Zugriffe, die zur Aufgabe notwendig sind.

Schritt 3: Action Gating / Approval für irreversible Aktionen

• Tools mit „Send/Delete/Refund/Close“ bekommen needsApproval (oder äquivalente Kontrolle) und pausieren ohne Freigabe.

Schritt 4: Laufzeit-Kontrollen (Defense in Depth)

OWASP empfiehlt mehrere Schichten: Tool‑Minimierung plus weitere Security‑Layer.

• Logging aller Tool Calls (Wer? Was? Warum? Input‑Quelle?)

• Monitoring/Alerting bei ungewöhnlichen Aktionsmustern

• Token‑Hygiene: kurze TTL, kein „shared super token“

Schritt 5: Kontinuierliche Risikosteuerung (Governance)

NIST AI RMF betont ein Lifecycle‑basiertes Risikomanagement für AI‑Systeme (Govern/Map/Measure/Manage). Das bedeutet für Agenten konkret: Policies + Reviews sind nicht einmalig, sondern kontinuierlich – besonders wenn neue Tools dazukommen.

Anti‑Pattern: Woran man Excessive Agency in der Praxis erkennt

Einige typische „Smells“:

1. Ein Token für alles (Mailbox + Files + Admin‑API)→ widerspricht Least Privilege (AC‑6).

2. App‑only, obwohl delegated möglich wäre→ Microsoft beschreibt Application Permissions als riskanter bzgl. Privacy, weil Zugriff ohne User‑Kontext.

3. Toolset ist größer als der Use Case→ OWASP: Root Cause „excessive functionality“.

4. Kein Approval für irreversible Actions→ Human‑in‑the‑loop ist ein etabliertes Muster für sensitive Tool‑Calls.

5. Agent konsumiert untrusted Content und darf mutieren→ OWASP Prompt Injection Cheat Sheet warnt vor indirekter Prompt Injection aus externem Content.

Autonomie ist eine Berechtigung

Excessive Agency ist keine abstrakte Ethik‑Debatte, sondern ein handfestes Security‑Problem: Agenten‑Autonomie ist funktional eine privilegierte Rolle. OWASP stuft „Excessive Agency“ nicht umsonst als High‑Risk ein, weil zu breite Capabilities aus einem Modellfehler sofort einen Systemfehler machen können.

Die gute Nachricht: Die wirksamsten Maßnahmen sind aus klassischer Security bekannt und lassen sich sauber auf Agenten übertragen:

• Least Privilege (NIST AC‑6) auf Token/Scopes/Funktionen

• Capability Design: Read vs Write, Draft vs Send, Query vs Mutation

• Consent/HITL für riskante Tools

• Defense in Depth rund um Tools/Extensions (OWASP)

Wenn du Agenten so behandelst wie privilegierte Identitäten mit Scoping, Gates, Reviews und Monitoring, dann bleiben sie auch im Fehlerfall kontrollierbar.