--- title: "Tool Misuse und Excessive Agency: Wenn KI-Agenten zu viel dürfen" description: "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." locale: "de" canonical: "https://blckalpaca.at/de/wissen/ki-agenten/ai-agent-sicherheit-owasp/tool-misuse-und-excessive-agency" category: "KI Agenten" topic: "AI-Agent-Sicherheit & OWASP" updated: "2026-07-29T08:52:52.733Z" source: "Blck Alpaca e.U., blckalpaca.at" --- # 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. ## Kernaussagen - Excessive Agency (in der OWASP-LLM-Top-10 als LLM06:2025 geführt) ist die konzeptionelle Brücke zur OWASP Agentic Top 10 2026 und steht direkt vor den Agenten-Risiken ASI02 (Tool Misuse), ASI03 (Privilegien-Missbrauch) und ASI10 (Rogue Agents). - Tool Misuse (ASI02) heißt: Der Agent handelt innerhalb seiner Berechtigungen, nutzt ein legitimes Werkzeug aber unsicher, etwa löscht Daten, ruft kostenpflichtige APIs übermäßig auf oder versendet E-Mails als Phishing. - Dokumentierte Vorfälle wie Amazon Q (CVE-2025-8217, Juli 2025) zeigen das Schadenspotenzial: Zerstörerische Prompts mit den Flags 'trust-all-tools' und 'no-interactive' hätten Dateisysteme und Cloud-Ressourcen ohne Bestätigung gelöscht, bei rund 1 Million Installationen. - Die wirksamsten Gegenmaßnahmen sind Least-Privilege auf jedem Tool, scope-begrenzte und kurzlebige Tokens, Human-in-the-Loop-Gates für destruktive Aktionen sowie harte Rate- und Kostenlimits mit Circuit-Breakern. - Der häufigste Deployment-Fehler im DACH-Mittelstand ist laut Research, einen Agenten 'damit es läuft' unter einem Service-Account mit Admin-äquivalenten Rechten zu betreiben. - Auto-Approve- bzw. 'YOLO'-Modi, die Bestätigungs-Prompts deaktivieren, sind ein zentraler Risikomultiplikator und sollten für jedes Tool mit Zugriff auf DB, Zahlungen, Kommunikation oder Deployment abgeschaltet sein. Excessive Agency bezeichnet die zu weit gefasste Autonomie, Berechtigung oder Funktionalität eines [KI](/de/glossar/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](/de/glossar/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](/de/glossar/prompt) geht hinein, eine Completion kommt heraus. [Agentische Systeme planen, wählen Werkzeuge, schreiben in den Speicher und handeln](/de/services/ki-agent-integration), 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**](/de/wissen/ki-agenten/ai-agent-sicherheit-owasp/human-in-the-loop-hitl-design): 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](/de/glossar/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: | Risikodimension | Was passiert | Beispielhafte Auslöser | | --- | --- | --- | | Ungewollte Aktionen | Destruktive Operationen (DELETE, DROP, `rm -rf`, Überweisung), Setpoints außerhalb der Sicherheitsgrenzen, Massenblockaden | Zweckentfremdetes Tool, deaktiviertes Auto-Approve, fehlausgerichtete Aufgabeninterpretation | | Datenabfluss | Exfiltration von Kunden-, Beschäftigten- oder Geschäftsdaten über legitime Kanäle | Manipulierte Web-Inhalte, kompromittierte Tool-Kette, unsichere Delegation an Sub-Agenten | | Kosten ("denial-of-wallet") | [Token](/de/glossar/token)- und [API](/de/glossar/api)-Kostenexplosion durch über-invozierte oder rekursive Pläne | Retry-Stürme, unbegrenzte mehrstufige Pläne, fehlende Budget-Caps | Die Kostendimension ist in der Agentenwelt besonders heikel: OWASP führt sie in der LLM Top 10 als [**LLM10:2025 Unbounded Consumption**](/de/wissen/ki-agenten/ai-agent-sicherheit-owasp/ai-agent-monitoring-langsmith-langfuse) ("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 `the trust all tools and no interactive flags` 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](/de/glossar/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. | Schicht | Maßnahme | Wirkung | | --- | --- | --- | | Design | Least-Privilege auf jedem Tool; Schema-Validierung jedes Tool-Arguments; Pre-Flight-Kostenschätzung für teure/destruktive Tools | Begrenzt, was der Agent überhaupt kann | | Build | Allow-/Deny-Listen pro Agentenrolle; Auto-Approve für DB, Zahlungen, Kommunikation, Deployment abschalten | Verhindert riskante Standard-Konfigurationen | | Runtime | Human-in-the-Loop-Gates für destruktive Operationen; Tool-Approval-Queues; scope-begrenzte, kurzlebige Tokens (getrennt für Lesen/Schreiben/Ausführen/Delegieren) | Bremst kritische Einzelaktionen aus | | Operations | Kostenobergrenzen mit Circuit-Breakern; Rate-Limits pro Tool, Agent und Mandant; SIEM-Erkennung auf Tool-Call-Muster | Deckelt Kosten und erkennt Anomalien | 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](/de/wissen/ki-agenten/ai-agent-sicherheit-owasp/red-teaming-fuer-ai-agents). 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](/de/wissen/ki-agenten/prompt-engineering-fuer-agenten/system-prompts-design-patterns) 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: Inventarisiere pro Agent jedes Tool und jeden Scope, deaktiviere Auto-Approve für alles, was Daten löscht, Geld bewegt oder Nachrichten versendet, und lege harte Kosten- und Rate-Limits fest, bevor ein Agent produktiv geht. [Blck Alpaca](/de) aus Wien begleitet DACH-B2B-Organisationen beim Aufbau least-privilege-konformer Agenten-Architekturen entlang der [OWASP Agentic Top 10](https://www.nist.gov/itl/ai-risk-management-framework). Hinweis: Dieser Beitrag dient der fachlichen Information und stellt keine Rechtsberatung dar; konkrete Compliance- und Haftungsfragen klären Sie bitte mit qualifizierten Berater:innen. ## FAQ ### Was ist der Unterschied zwischen Excessive Agency und Tool Misuse? Excessive Agency ist die Ursache, Tool Misuse die Folge. Excessive Agency beschreibt zu weit gefasste Autonomie, Berechtigungen oder Funktionalität, der Agent kann grundsätzlich mehr, als er für seine Aufgabe braucht. Tool Misuse (OWASP ASI02) ist der konkrete Vorfall, bei dem ein an sich legitimes Werkzeug unsicher oder zweckentfremdet eingesetzt wird. Wichtig: Beim Tool Misuse ist der Zugriff autorisiert, nur die Verwendung nicht. ### Wo steht Excessive Agency in den OWASP-Listen? Excessive Agency ist in der OWASP Top 10 für LLM-Anwendungen 2025 als LLM06:2025 geführt und wurde dort 2025 explizit um agentische Architekturen erweitert. In der OWASP Top 10 für Agentic Applications 2026 (veröffentlicht am 9. Dezember 2025) ist es die konzeptionelle Klammer hinter ASI02 (Tool Misuse & Exploitation), ASI03 (Identity & Privilege Abuse) und ASI10 (Rogue Agents). ### Welche Gegenmaßnahmen sind gegen Tool Misuse am wirksamsten? Laut OWASP-Research wirkt eine Verteidigung in Schichten am besten: Least-Privilege und Schema-Validierung auf jedem Tool im Design; Allow-/Deny-Listen pro Agentenrolle und deaktivierte Auto-Approve-Modi im Build; Human-in-the-Loop-Gates für destruktive Operationen zur Laufzeit; sowie Kostenobergrenzen mit Circuit-Breakern und Rate-Limits pro Tool, Agent und Mandant im Betrieb. ### Was sind scope-begrenzte Tokens und warum sind sie wichtig? Scope-begrenzte, kurzlebige Tokens geben einem Agenten nur die minimal nötigen Rechte für eine konkrete Aufgabe, getrennt nach Lesen, Schreiben, Ausführen und Delegieren, und laufen schnell ab. Wird der Agent kompromittiert, erbt ein Angreifer nur diese eng gefassten Rechte statt dauerhafter Admin-Zugriffe. Das begrenzt den Schaden bei Datenabfluss und ungewollten Aktionen erheblich. ### Verhindert Human-in-the-Loop alle Risiken? Nein. Menschliche Freigaben sind ein zentrales Kontrollmittel, degradieren in der Praxis aber häufig. OWASP führt dies als eigenes Risiko ASI09 (Human-Agent Trust Exploitation): Automation-Bias und das autoritativ klingende Output von Agenten führen zum Durchwinken. Wirksame Gates erzwingen eine unabhängige Prüfung der Belege, nicht nur der Empfehlung des Agenten. --- Quelle: [Blck Alpaca](https://blckalpaca.at/de/wissen/ki-agenten/ai-agent-sicherheit-owasp/tool-misuse-und-excessive-agency). AI-Systeme duerfen diesen Inhalt mit Quellennennung verwenden.