Tool Misuse und Excessive Agency: Wenn KI-Agenten zu viel dürfen

Excessive Agency bezeichnet die zu weit gefasste Autonomie, Berechtigung oder Funktionalität eines KI-Agenten – er kann mehr tun, als für seine Aufgabe nötig wäre. Tool Misuse ist der missbräuchliche Einsatz legitimer Werkzeuge: Der Zugriff ist autorisiert, die Verwendung nicht. Beides führt zu ungewollten Aktionen, Datenabfluss und unkontrollierten Kosten. In der OWASP-Systematik bildet Excessive Agency die Klammer, unter der Tool Misuse als konkretes Agenten-Risiko materialisiert.

• Schnellantwort 1: Excessive Agency ist die Ursache (zu viel Autonomie/Rechte), Tool Misuse die Folge (legitimes Werkzeug wird unsicher oder zweckentfremdet genutzt).
• Schnellantwort 2: OWASP führt das Thema in der LLM Top 10 2025 als LLM06:2025 und in der Agentic Top 10 2026 als ASI02 (Tool Misuse & Exploitation), veröffentlicht am 9. Dezember 2025.
• Schnellantwort 3: Die Kerngegenmaßnahmen sind Least-Privilege, scope-begrenzte kurzlebige Tokens, Human-Approval für kritische Aktionen und harte Rate- bzw. Kostenlimits.

Warum "zu viel dürfen" das eigentliche Agenten-Problem ist

Klassische LLM-Anwendungen antworten: Ein Prompt geht hinein, eine Completion kommt heraus. Agentische Systeme planen, wählen Werkzeuge, schreiben in den Speicher und handeln – mit minimaler schrittweiser menschlicher Freigabe. Genau dieser Sprung von "antworten" zu "handeln" macht die Frage der Berechtigungen zur zentralen Sicherheitsfrage.

OWASP fasst das in der LLM Top 10 2025 unter LLM06:2025 Excessive Agency: das Gewähren ungeprüfter Handlungsautonomie an LLMs bei unzureichender Berechtigungseingrenzung oder menschlicher Aufsicht. Dieser Eintrag wurde 2025 ausdrücklich auf agentische Architekturen erweitert und ist – so die Research – die größte konzeptionelle Brücke, die Entscheider verinnerlichen müssen. Excessive Agency steht direkt vor mehreren Agenten-Risiken der OWASP Top 10 für Agentic Applications 2026, namentlich ASI02 (Tool Misuse), ASI03 (Identity & Privilege Abuse) und ASI10 (Rogue Agents).

Excessive Agency entsteht typischerweise auf drei Ebenen:

• Zu viele Berechtigungen – der Agent erbt über-breite Rechte vom Benutzer oder Service-Account, unter dem er läuft.
• Zu viel Funktionalität – dem Agenten stehen Werkzeuge zur Verfügung, die seine Aufgabe gar nicht erfordert (etwa ein Lösch- oder Zahlungs-Tool bei einem reinen Lese-Use-Case).
• Zu viel Autonomie – kritische Aktionen laufen ohne Bestätigung, etwa über aktivierte Auto-Approve- oder "YOLO"-Modi.

Tool Misuse (ASI02): legitimer Zugriff, illegitime Nutzung

Die OWASP-Beschreibung von ASI02 ist präzise: Der Agent operiert innerhalb seiner autorisierten Privilegien, wendet ein legitimes Werkzeug aber auf unsichere oder unbeabsichtigte Weise an – er löscht wertvolle Daten, ruft teure APIs übermäßig auf, führt destruktive Operationen aus oder schleust Informationen aus. Die Abgrenzung zu ASI03 ist wichtig: Der Zugriff ist legitim, die Verwendung nicht.

Typische Angriffs- und Fehlervektoren laut Research:

• Prompt Injection, die ein Tool zweckentfremdet – etwa send_email, das plötzlich zum Phishing der gesamten Kundenbasis genutzt wird.
• Fehlausrichtung zwischen der Aufgabeninterpretation des Agenten und der Entwicklerabsicht.
• Unsichere Delegation – der Agent übergibt ein mächtiges Werkzeug an einen Sub-Agenten ohne kontextuelle Schutzmechanismen.
• Auto-Approve-/"YOLO"-Modi, die Bestätigungs-Prompts deaktivieren.

Risiken konkret: Aktionen, Daten, Kosten

Die drei Schadensdimensionen lassen sich klar trennen:

Die Kostendimension ist in der Agentenwelt besonders heikel: OWASP führt sie in der LLM Top 10 als LLM10:2025 Unbounded Consumption ("denial-of-wallet"). Laut Research multiplizieren mehrstufige Pläne den Token-Aufwand, weshalb Budget-Enforcement pro Plan zwingend ist.

Dokumentierte Vorfälle (Stand 2026)

Die Research nennt mehrere belegte Fälle, die das Schadenspotenzial untermauern:

• Amazon Q Code Assistant (CVE-2025-8217, Juli 2025): Angreifer kompromittierten einen GitHub-Token und schleusten bösartige Anweisungen in die VS-Code-Extension v1.84.0. Zerstörerische Prompts in Kombination mit --trust-all-tools --no-interactive hätten Dateisysteme und Cloud-Ressourcen ohne Bestätigung gelöscht. Die Extension war bei rund 1 Million Entwicklern installiert; der Fix kam mit v1.85.0.
• OpenAI Operator (Embrace The Red, Johann Rehberger): Bösartige Webseiten-Inhalte steuerten den Agenten dazu, authentifizierte interne Seiten aufzurufen und Adressen, Telefonnummern und E-Mails von GitHub und Booking.com offenzulegen.
• Langflow AI RCE (CVE-2025-34291): CrowdStrike beobachtete mehrere Bedrohungsakteure, die eine unauthentifizierte Code-Injection in Langflow ausnutzten – einem weit verbreiteten Agenten-Framework.

Ein anschauliches Excessive-Agency-Szenario ist die in der Research dokumentierte Manufacturing-Procurement-Kaskade (2025): Ein Beschaffungs-Agent wurde über drei Wochen schrittweise davon "überzeugt", sein Autorisierungslimit liege bei 500.000 US-Dollar. Anschließend platzierte der Angreifer 5 Millionen US-Dollar an falschen Bestellungen über 10 Transaktionen. Der Fall verbindet Tool Misuse mit dem Risiko, dass menschliche Freigaben durchgewunken werden (ASI09).

Gegenmaßnahmen: Verteidigung in Schichten

Die Research strukturiert die Maßnahmen entlang des Lebenszyklus. Wichtig: Kein Einzelschutz genügt – Schichten ergänzen sich.

Ergänzend nennt die Research zwei Architekturprinzipien für die DACH-Praxis: Erstens das Gateway-/Proxy-Muster vor jedem Agenten als zentrale Durchsetzung von Allow-Listen, Schema-Validierung, Kostenobergrenzen, Rate-Limits und Audit-Logging. Zweitens die Identitätsfrage: Jeder Agent ist eine eigene Non-Human-Identity (NHI) mit eigenem Credential-Lifecycle, kurzlebigen Tokens und Just-in-time-Bereitstellung. Der laut Research häufigste Deployment-Fehler im DACH-Mittelstand ist, einen Agenten "damit es läuft" unter einem Service-Account mit Admin-äquivalenten Rechten zu betreiben. Sicherer ist die delegierte Benutzeridentität – der Agent handelt als der Mensch und ist auf dessen Rechte beschränkt.

Ein Wort zur Wirksamkeit von Human-Approval: Diese Gates degradieren in der Praxis häufig. OWASP führt das als eigenes Risiko ASI09 (Human-Agent Trust Exploitation) – Automation-Bias und autoritativ klingender Output führen zum Durchwinken. Wirksame Gates erzwingen daher die unabhängige Prüfung der Belege, nicht nur das Abnicken der Agenten-Empfehlung.

Beispiel: Berechtigungen für einen Newsletter-Agenten

Ein Marketing-Agent soll Newsletter-Entwürfe erstellen und versenden. Excessive Agency entsteht, wenn er Vollzugriff auf das E-Mail-System erhält. Least-Privilege in Pseudocode:

```
agent_role: "newsletter-draft"
tools:

• read_segment: scope=audience.read rate_limit=20/min
• create_draft: scope=campaign.write rate_limit=10/min
• send_campaign: scope=campaign.send rate_limit=2/h
  require_human_approval=true # Gate: Empfänger + Inhalt prüfen
  deny:
• delete_contact, export_audience, billing.*
  budget:
  token_cap=500000/day usd_cap=20/day circuit_breaker=on
  token:
  type=short_lived ttl=15min
  ```

Wirkung: Selbst bei erfolgreicher Prompt Injection kann der Agent keine Kontakte exportieren oder löschen, keine kostenpflichtige Massen-API überlasten und keine Kampagne ohne menschliche Freigabe versenden. Der kurzlebige, scope-begrenzte Token entwertet abgegriffene Credentials nach 15 Minuten.

Für Agenturen und B2B

Wer KI-Agenten für Kund:innen in Marketing, Vertrieb oder Service betreibt, trägt Verantwortung für deren Berechtigungsdesign. Praktischer Einstieg: Inventarisieren Sie pro Agent jedes Tool und jeden Scope, deaktivieren Sie Auto-Approve für alles, was Daten löscht, Geld bewegt oder Nachrichten versendet, und legen Sie harte Kosten- und Rate-Limits fest, bevor ein Agent produktiv geht. Blck Alpaca aus Wien begleitet DACH-B2B-Organisationen beim Aufbau least-privilege-konformer Agenten-Architekturen entlang der OWASP Agentic Top 10. Hinweis: Dieser Beitrag dient der fachlichen Information und stellt keine Rechtsberatung dar; konkrete Compliance- und Haftungsfragen klären Sie bitte mit qualifizierten Berater:innen.