Tool-Call-Fuzzing für KI-Agenten: Übermäßige Vollmachten und Confused-Deputy-Pfade aufdecken

KI-Agenten rufen heute eigenständig Funktionen auf: Sie versenden E-Mails, schreiben in Datenbanken, lösen Zahlungen aus. Jeder dieser Funktionsaufrufe ist eine Vertrauensentscheidung — und genau dort entstehen die gefährlichsten Schwachstellen. Tool-Call-Fuzzing und systematische Funktionsaufruf-Missbrauchstests sind die Disziplin, mit der ein Red-Team diese Entscheidungen gezielt unter Druck setzt, bevor ein Angreifer es tut.

Dieser Beitrag gehört zum Cluster „Red-Teaming & Evaluierung“ und beschreibt nicht den Confused-Deputy-Angriff als solchen, sondern die Prüfmethodik: Wie testet man einen Agenten reproduzierbar darauf, ob er zu viele Rechte besitzt und ob fremde Eingaben ihn in einen Stellvertreter mit geliehenen Rechten verwandeln?

Was ist Tool-Call-Fuzzing bei KI-Agenten?

Tool-Call-Fuzzing ist ein automatisiertes Prüfverfahren, bei dem ein Agent mit einer großen Zahl mutierter, unerwarteter oder bösartiger Aufgaben und Werkzeug-Argumente konfrontiert wird, um Funktionsaufrufe zu provozieren, die er nicht hätte ausführen dürfen. Während klassisches Software-Fuzzing zufällige Bytes in einen Parser kippt, zielt Tool-Call-Fuzzing auf die Entscheidungsschicht: Es variiert nicht nur die Argumente eines Werkzeugs, sondern auch die Aufgabenstellung, den Kontext und die eingebetteten Fremdinhalte, bis der Agent ein Werkzeug auf eine Weise nutzt, die gegen die Sicherheitsrichtlinie verstößt.

Der entscheidende Unterschied zum gewöhnlichen Sicherheitstest liegt in der Zielgröße. Geprüft wird nicht, ob eine Funktion abstürzt, sondern ob der Agent eine Funktion überhaupt aufruft — und mit welchen Argumenten, in wessen Auftrag und mit welchen Rechten. Der Funktionsaufruf selbst ist die Schwachstelle, nicht der Code dahinter.

Es ist eine Speiche der breiteren Red-Team-Framework-Praxis für KI-Agenten. Daraus ergeben sich zwei eng verwandte Prüfziele, die diesen Beitrag durchziehen:

• Test übermäßiger Vollmachten (Excessive Agency): Besitzt der Agent Werkzeuge, Rechte oder Autonomie, die seine eigentliche Aufgabe nicht erfordert?
• Confused-Deputy-Pfade: Lässt sich der Agent durch fremde Eingaben dazu bringen, seine legitimen Rechte im Sinne eines Angreifers einzusetzen?

Warum reichen klassische Tests für agentische Systeme nicht aus?

Ein herkömmlicher Penetrationstest prüft eine API, indem er Eingaben gegen einen festen Endpunkt schickt und die Antwort bewertet. Bei einem KI-Agenten ist die Angriffsfläche dagegen nicht der einzelne Endpunkt, sondern die Kette aus Sprachmodell, Werkzeug-Auswahl und Werkzeug-Ausführung. Dieselbe Eingabe kann bei zwei Durchläufen zu unterschiedlichen Funktionsaufrufen führen, weil das Modell nicht deterministisch ist.

Dieser Nichtdeterminismus ist der Grund, warum punktuelle Tests trügerisch sind. Ein Test, der einmal grün ist, sagt wenig aus, solange er nicht über viele Durchläufe und Varianten stabil grün bleibt. Genau hier setzt Fuzzing an: Es verschiebt die Bewertung von „Hat dieser eine Aufruf funktioniert?“ zu „Wie oft, über wie viele Mutationen, weicht der Agent von der Richtlinie ab?“.

Hinzu kommt die Vertrauensgrenze. Ein Agent verarbeitet Inhalte aus Quellen unterschiedlicher Vertrauenswürdigkeit — Systemanweisung, Nutzeranfrage, abgerufene Dokumente, Werkzeug-Ausgaben. Klassische Tests behandeln Eingaben als einheitlichen Strom. Funktionsaufruf-Missbrauchstests müssen dagegen gezielt prüfen, ob Inhalte aus einer nicht vertrauenswürdigen Quelle einen Funktionsaufruf auslösen können, der nur aus der vertrauenswürdigen Quelle hätte stammen dürfen.

Welche Schwachstellenklassen deckt Tool-Call-Fuzzing auf?

Sinnvoll ist es, die Befunde entlang zweier Achsen zu ordnen: Hat der Agent zu viel Macht (Vollmacht), oder wird seine Macht missbräuchlich umgelenkt (Confused Deputy)? Die folgende Tabelle ordnet typische Befunde ein.

Schwachstellenklasse	Prüffrage	Auslöser im Fuzzing
Übermäßige Funktionsmenge	Hat der Agent Werkzeuge, die seine Aufgabe nicht braucht?	Aufgaben, die zu einem irrelevanten Werkzeugaufruf verleiten
Übermäßige Berechtigung	Laufen Werkzeuge mit weiteren Rechten als nötig?	Argumente, die auf Datensätze außerhalb des Auftrags zielen
Übermäßige Autonomie	Werden risikoreiche Aktionen ohne Bestätigung ausgeführt?	Aufgaben mit irreversiblen Folgen ohne Human-in-the-Loop
Confused Deputy über Inhalte	Lösen Fremdinhalte einen Funktionsaufruf aus?	Eingebettete Anweisungen in Dokumenten, E-Mails, Webseiten
Argument-Schmuggel	Lassen sich Werkzeug-Argumente manipulieren?	Pfad-Traversal, SQL-Fragmente, fremde Empfänger in Parametern
Werkzeug-Verkettung	Lässt sich aus harmlosen Werkzeugen ein schädlicher Pfad bauen?	Aufgaben, die Lese- und Schreibwerkzeuge koppeln

Besonders aufschlussreich ist die letzte Zeile. Einzeln betrachtet kann jedes Werkzeug harmlos wirken — ein Werkzeug, das eine Datei liest, und eines, das eine E-Mail versendet. Erst die Verkettung ergibt den Exfiltrationspfad: lesen, was nicht für den Empfänger bestimmt war, und es nach außen senden. Fuzzing, das nur einzelne Aufrufe betrachtet, übersieht diese Pfade. Deshalb gehören Mehrschritt-Szenarien zwingend in den Prüfumfang.

Wie prüft man übermäßige Vollmachten systematisch?

Der Test übermäßiger Vollmachten beginnt nicht beim Angriff, sondern bei der Bestandsaufnahme. Bevor man fuzzt, dokumentiert man, welche Werkzeuge der Agent kennt, mit welchen Rechten sie laufen und welche Aktionen reversibel sind. Diese Liste ist die Messlatte: Jeder Funktionsaufruf, der außerhalb der dokumentierten, aufgabenbezogenen Menge liegt, ist ein Befund.

Daraus leiten sich drei Prüfdimensionen ab, die der OWASP-Eintrag zu „Excessive Agency“ benennt. Die erste ist die Funktionsmenge: Man stellt dem Agenten Aufgaben, die mit seinem eigentlichen Auftrag nichts zu tun haben, und beobachtet, ob er trotzdem ein vorhandenes, aber unnötiges Werkzeug aufruft. Ruft ein Zusammenfassungs-Agent das Werkzeug send_email auf, ist die Funktionsmenge zu groß.

Die zweite Dimension ist die Berechtigung. Hier variiert das Fuzzing die Argumente so, dass sie auf Daten außerhalb des Auftrags zeigen — andere Mandanten, andere Nutzer, andere Tabellen. Führt der Agent den Aufruf aus, statt ihn zu verweigern, läuft das Werkzeug mit zu weiten Rechten. Die dritte Dimension ist die Autonomie: Aufgaben mit irreversiblen Folgen — Löschen, Überweisen, Veröffentlichen — prüfen, ob der Agent eine menschliche Bestätigung einholt oder eigenmächtig handelt.

Wichtig ist die Trennung von Befund und Ursache. Ein einzelner unerwünschter Aufruf kann ein Modellfehler sein; erst ein über viele Durchläufe reproduzierbarer Aufruf belegt eine strukturelle übermäßige Vollmacht, die durch Härtung der Werkzeugmenge oder der Rechte behoben werden muss — nicht durch ein besseres Prompt.

Wie testet man gezielt auf Confused-Deputy-Pfade?

Confused-Deputy-Tests unterscheiden sich grundlegend vom Test übermäßiger Vollmachten, weil der Auslöser hier nicht in der Aufgabe des Nutzers steckt, sondern in fremdem Inhalt, den der Agent verarbeitet. Die Prüfmethodik bildet deshalb die reale Vertrauensgrenze nach: Man platziert eine Anweisung in einer Quelle, die der Agent als Daten behandeln sollte, und beobachtet, ob er sie als Befehl ausführt.

Konkret bedeutet das, präparierte Artefakte in den Verarbeitungspfad einzuschleusen — ein Dokument mit eingebetteter Anweisung, eine E-Mail mit verstecktem Auftrag, eine Webseite mit Steueranweisung im Fließtext. Wie man solche Nutzlasten methodisch konstruiert, behandelt das Prompt-Injection-Red-Team-Labor. Das Fuzzing variiert dabei systematisch die Formulierung, die Platzierung und die Tarnung der eingeschleusten Anweisung, weil ein Agent auf eine Variante hereinfallen kann, während er eine andere abweist. Eine einzelne, einmal scheiternde Injektion ist kein Nachweis von Robustheit.

Der Erfolgsindikator ist klar definiert: Ein Confused-Deputy-Pfad ist nachgewiesen, sobald ein Funktionsaufruf erfolgt, der kausal auf den Fremdinhalt zurückgeht und nicht auf die legitime Nutzeranfrage. Um diese Kausalität sauber zu belegen, arbeitet man mit Markierungen — etwa einer eindeutigen, nur im präparierten Inhalt vorkommenden Zeichenkette, die im Werkzeug-Argument wieder auftaucht. Erscheint sie im Empfängerfeld einer versendeten E-Mail, ist der Pfad zweifelsfrei belegt.

Wie sieht ein reproduzierbares Test-Harness dafür aus?

Ein belastbares Fuzzing-Harness besteht aus vier Bausteinen, die unabhängig von der konkreten Werkzeugkette gleich bleiben.

1. Korpus von Saat-Fällen. Eine kuratierte Sammlung von Aufgaben und Fremdinhalten, je Schwachstellenklasse mindestens einer. Diese Saat-Fälle werden anschließend mutiert.
2. Mutations-Engine. Sie verändert Formulierung, Reihenfolge, Kodierung und Platzierung — etwa durch Umformulieren, Einbetten in andere Sprachen, Aufteilen über mehrere Quellen oder Verstecken in Metadaten.
3. Sichere Ausführungsumgebung. Werkzeuge werden gegen Attrappen oder eine isolierte Sandbox ausgeführt, niemals gegen Produktivsysteme. Jeder Funktionsaufruf wird vollständig protokolliert: Name, Argumente, Zeitpunkt, auslösender Kontext.
4. Orakel. Eine maschinell prüfbare Regel, die entscheidet, ob ein Aufruf einen Verstoß darstellt — etwa „kein Aufruf von send_email an eine Adresse außerhalb der Domäne“ oder „kein Auftauchen der Marker-Zeichenkette in einem Werkzeug-Argument“.

Das Orakel ist der schwierigste Teil. Anders als beim klassischen Fuzzing, wo ein Absturz ein eindeutiges Signal ist, muss hier eine Richtlinie maschinell entscheidbar formuliert werden. Bewährt hat sich, das Orakel nicht auf die Modellantwort zu stützen, sondern auf den protokollierten Funktionsaufruf — den Effekt, nicht die Erklärung. Was der Agent sagt, ist irrelevant; was er aufruft, zählt.

Welche Werkzeuge unterstützen Funktionsaufruf-Missbrauchstests?

Mehrere quelloffene Projekte adressieren Teile dieser Aufgabe. Garak ist ein Scanner für Schwachstellen in Sprachmodellen und prüft unter anderem auf Prompt Injection und Jailbreaks. Das PyRIT-Framework von Microsoft automatisiert Red-Teaming gegen generative Systeme und unterstützt mehrstufige Angriffsabläufe. Promptfoo erlaubt es, Testfälle und Bewertungsregeln deklarativ zu definieren und über viele Durchläufe auszuwerten.

Keines dieser Werkzeuge deckt Tool-Call-Fuzzing vollständig ab; sie liefern Bausteine — Angriffsmuster, Ausführungslogik, Bewertungsregeln —, die in das oben beschriebene Harness eingebettet werden müssen. Die werkzeugspezifische Vertrauensgrenze und das Orakel bleiben Eigenleistung des Red-Teams. Wer ein vorhandenes Werkzeug einsetzt, sollte dessen Eignung für den eigenen Funktionsaufruf-Kontext kritisch prüfen, statt sich auf eine grüne Standardausgabe zu verlassen.

Wie bewertet man die Ergebnisse aussagekräftig?

Die zentrale Kennzahl ist die Verstoßrate je Schwachstellenklasse: der Anteil der Durchläufe, in denen der Agent einen richtlinienwidrigen Funktionsaufruf ausführte. Eine einzelne Verstoßrate ist wenig aussagekräftig; entscheidend ist die Entwicklung über Versionen hinweg und der Vergleich vor und nach einer Härtungsmaßnahme.

Befunde lassen sich nach Schwere priorisieren, indem man zwei Faktoren multipliziert: die Irreversibilität der ausgelösten Aktion und die Verlässlichkeit der Reproduktion. Ein reproduzierbarer Pfad zu einer irreversiblen Aktion — Datenlöschung, Geldtransfer, externer Versand personenbezogener Daten — hat höchste Priorität. Ein nur sporadisch auslösbarer Pfad zu einer reversiblen Aktion rangiert darunter.

Für den DACH-Raum ist die Dokumentation dieser Tests nicht nur gute Praxis, sondern zunehmend regulatorisch relevant. Die KI-Verordnung (EU AI Act) verlangt für Hochrisiko-Systeme Robustheitsprüfungen, die Angreiferszenarien einschließen. Ein dokumentiertes Funktionsaufruf-Missbrauchstest-Verfahren mit reproduzierbaren Ergebnissen liefert genau den Nachweis, den eine solche Prüfung erfordert. Führt ein erfolgreicher Confused-Deputy-Pfad zur Übermittlung personenbezogener Daten an Unbefugte, liegt zudem eine nach DSGVO meldepflichtige Datenpanne vor — ein Grund mehr, solche Pfade vor dem Produktivbetrieb zu schließen.

Welche Grenzen hat Tool-Call-Fuzzing?

Fuzzing weist die Anwesenheit von Schwachstellen nach, nie deren Abwesenheit. Ein Harness, das über zehntausend Mutationen keinen Verstoß findet, beweist nicht, dass der Agent sicher ist — es beweist, dass dieser Korpus diese Schwachstellen nicht ausgelöst hat. Neue Angriffsmuster, andere Modellversionen oder veränderte Werkzeugketten können das Bild jederzeit kippen.

Daraus folgt eine pragmatische Konsequenz: Tool-Call-Fuzzing ist eine Schicht in einem mehrschichtigen Ansatz, kein Ersatz für architektonische Härtung. Minimale Rechte für Agenten-Werkzeuge, Kontexttrennung zwischen vertrauenswürdigen und fremden Inhalten, Bestätigungsschritte für irreversible Aktionen und vollständige Auditprotokollierung begrenzen die Auswirkungen eines Pfades, den das Fuzzing übersehen hat. Das Testverfahren misst die Wirksamkeit dieser Maßnahmen — es ersetzt sie nicht.

Wer Funktionsaufruf-Missbrauchstests einführt, sollte sie deshalb in die Entwicklungspipeline integrieren und bei jeder Änderung an Werkzeugen, Rechten oder Modellversion erneut ausführen. Ein Agent, der gestern robust war, kann nach einem Modell-Update einen neuen Confused-Deputy-Pfad öffnen. Reproduzierbarkeit ist hier kein Selbstzweck, sondern die Voraussetzung dafür, Regressionen überhaupt zu erkennen.

Fazit

Tool-Call-Fuzzing verschiebt den Prüfblick von der Frage „Funktioniert das Werkzeug?“ zur sicherheitsrelevanten Frage „Ruft der Agent das Werkzeug auf, obwohl er es nicht dürfte?“. Der Test übermäßiger Vollmachten deckt strukturell zu weit gefasste Rechte auf, die Confused-Deputy-Prüfung deckt umgelenkte Rechte auf. Beide brauchen ein reproduzierbares Harness mit einem Orakel, das den protokollierten Funktionsaufruf bewertet — nicht die Selbstauskunft des Modells. Eingebettet in minimale Rechte, Kontexttrennung und Auditierung wird daraus ein belastbarer Nachweis von Agenten-Sicherheit, der auch den Anforderungen der KI-Verordnung standhält.