Tool-Output-Injection

Was ist Tool-Output-Injection?

Tool-Output-Injection ist indirekte Prompt Injection über die Daten, die ein Tool an das Modell zurückliefert. Träger können ein Browser- oder Fetch-Tool, ein Connector, ein Retriever, ein API-Wrapper, ein Plugin, ein Datenbank-Client, ein interner Service-Adapter oder ein weiterer Agent sein, der als Tool aufgerufen wird. Der beeinflussende Inhalt erreicht das AI-System auf der Antwortseite eines Tool-Aufrufs, also nachdem die Anwendung den Aufruf bereits als zulässig bewertet hat.

Die aufrufende Komponente kann dabei völlig legitim sein: authentifiziert, signiert, intern betrieben und korrekt implementiert. Das sagt etwas über Transport und Betreiber aus. Über die Autorität des transportierten Inhalts sagt es nichts, denn dieser Inhalt stammt in der Regel aus einem externen oder teilweise angreiferbeeinflussten System.

Modellbeeinflussung ist außerdem nicht automatisch eine Sicherheitsauswirkung. Ein Tool-Ergebnis kann einen Plan, eine Zusammenfassung oder einen vorgeschlagenen Folgeaufruf verändern, ohne dass etwas sicherheitsrelevant passiert. Eine echte Auswirkung braucht zusätzlich erreichbare Daten oder Fähigkeiten und eine fehlende, zu weite oder versagende deterministische Kontrolle.

Vertrauenswürdiges Tool versus vertrauenswürdiger Inhalt

Viele produktive Tools wirken als Multiplexer: eine vertrauenswürdige Schnittstelle vor vielen Inhaltsautoren. Ein CRM-Tool liefert Notizen von Kundinnen und Kunden, ein Ticket-Tool liefert Text von Meldenden, ein Browser-Tool liefert Seiten beliebiger Herkunft. Die Vertrauensentscheidung gehört deshalb zum Inhalt und zu seiner Provenienz, nicht zur Komponente.

Umfang und verwandte Angriffsklassen

Tool Description oder Tool Registration Poisoning, auf dieser Website als MCP-Tool-Metadaten-Injection behandelt, wirkt vor jedem Aufruf auf den Katalog; Tool-Output-Injection beginnt nach dem Aufruf.

In realen Vorfällen treten diese Klassen kombiniert auf. Eine über ein Browser-Tool erreichte manipulierte Seite ist zugleich Website Prompt Injection und Tool-Output-Injection; derselbe Inhalt wird nach Indexierung zu RAG Prompt Injection. Dieser Artikel behandelt das gemeinsame Primitive: den Moment, in dem von einem Tool gelieferte Daten in den Modellkontext gelangen und den nächsten Schritt beeinflussen können.

Tool-Selection-Manipulation bleibt bewusst außen vor. Forschung zu dieser Klasse, etwa ToolHijacker, zielt auf die Tool-Bibliothek und den Auswahlschritt vor dem Aufruf. Tool-Output-Injection beginnt nach dem Aufruf und betrifft die Antwort.

Die Tool-Aufruf-Pipeline

Tool, Parser und Policy sind Systemkomponenten unter Kontrolle des Betreibers. Die durchfließenden Daten sind standardmäßig untrusted. Eine Provenienz- und Vertrauensentscheidung kann ändern, wie ein Ergebnis gekennzeichnet, aufbewahrt und bewertet wird, macht aber aus externem oder nutzerbeeinflusstem Inhalt niemals eine autorisierte Anweisung: bekannte Provenienz ist keine Instruktionsautorität, und ein vertrauenswürdiger Verarbeiter ist keine vertrauenswürdige Nutzlast. Deployments unterscheiden sich: manche Agenten rufen ein einziges lesendes Tool auf, andere verketten Abruf, Transformation und mutierende Tools über viele Schritte.

Flächen von Tool-Ergebnissen

All diese Inhalte können vollkommen legitim sein. Relevant sind sie hier, weil an diesen Stellen die Worte externer Autoren in einer systemartigen Hülle ankommen.

Daten versus Instruktionsautorität

Sprache in einem Tool-Ergebnis ist Evidenz über ein externes System. Ein Satz, der wie eine Anweisung klingt, bleibt zunächst Dateninhalt: Er kann beschreiben, was eine Kundin wünscht, was eine Seite behauptet oder was ein Datensatz enthält. Ihn als Workflow-Anweisung zu behandeln, ist eine Designentscheidung der Anwendung und fast immer die falsche.

Ergebnisbestandteile brauchen getrennte Behandlung, und strukturierte Ausgabe ist nicht dasselbe wie vertrauenswürdige Ausgabe. Ein JSON-Dokument, das gegen ein Schema validiert, liefert strukturelle Sicherheit über Form und Typen, kann aber in Freitextfeldern weiterhin extern verfassten Inhalt tragen; Schemagültigkeit sagt nichts über semantische oder Instruktionsvertrauenswürdigkeit aus. Innerhalb einer Antwort sollten vom System erzeugte Kontrollmetadaten wie Status, Identifikatoren und Typen getrennt in Kontext und Policy einfließen von Nutzlasttext, den eine externe Partei geschrieben hat. Strukturierte Felder, Identifikatoren, Statuscodes, Header und Freitextwerte haben unterschiedliche Vertrauenseigenschaften und sollten nicht vor dem Kontextaufbau zu einem undifferenzierten Textblock verschmelzen.

Anfrageseite versus Antwortseite

Aufrufautorisierung und Ergebnisbehandlung beantworten verschiedene Fragen. Die Aufrufautorisierung fragt, ob diese initiierende Identität in dieser Aufgabe dieses Tool mit diesen Argumenten gegen dieses Ziel aufrufen darf. Die Ergebnisbehandlung fragt, wie die zurückgelieferten Daten in den Kontext gelangen dürfen, welche Teile erhalten bleiben, welche Provenienz sie tragen und was sie beeinflussen dürfen.

Die Vermischung beider Ebenen erzeugt einen häufigen Architekturfehler: Weil der Aufruf die Autorisierung passiert hat, gilt alles Zurückgelieferte als Teil des genehmigten Workflows.

Provenienz, Transformation und modellsichtbare Repräsentation

Zwischen externem System und Modell liegt meist eine Kette von Transformationen, und jeder Schritt kann Quellidentität verlieren:

Provenienz muss all das überstehen. Eine Zusammenfassung, die nicht mehr nennt, aus welchem Datensatz, welcher URL oder welchem Feld sie stammt, lässt sich nicht prüfen, und eine prüfende Person kann Anwendungsaussage und Fremdsatz nicht mehr unterscheiden.

Untersuchungsgegenstand ist die modellsichtbare Repräsentation. Sie ist gegenüber der Rohantwort oft kürzer, umsortiert und umformatiert. Telemetrie, die nur die Rohnutzlast speichert, kann deshalb nicht erklären, was den Plan tatsächlich beeinflusst hat.

Mehrstufige und agentische Verstärkung

Ein einzelnes Ergebnis richtet selten allein Schaden an. Das Risiko wächst, wenn das Ergebnis den nächsten Schritt formt: eine weitere Suche, ein weiteres Tool, einen anderen Host, einen Dateipfad, einen Empfänger, einen Endpunkt oder eine Mutation. Das ist der Cross-Tool-Einfluss: Ergebnis A darf legitim beeinflussen, welches Tool B gegen welchen Host, welchen Empfänger oder welchen Pfad aufgerufen wird, aber es darf niemals selbst Tool-Berechtigung, Ziel-Freigabe oder Datenautorität erzeugen. In mehrstufigen Agenten wird Ausgabe zu Eingabe, und mit jedem Sprung kann die Beeinflussung weiterwirken, während die Zuordnung verblasst.

Eine Universalannahme über die Rechte eines Agenten ist nicht gerechtfertigt. Viele Deployments dürfen ausschließlich lesen. Andere dürfen Datensätze schreiben, Nachrichten senden, externe Endpunkte aufrufen oder Code ausführen. Jede dieser Fähigkeiten ist ein eigenes Gate, und jede Cross-Tool-Kante ist ein neues Autorisierungsgate: Dass Tool A vertrauenswürdig war oder sein Aufruf autorisiert wurde, überträgt keine Autorität auf Tool B oder dessen Parameter. Jedes Gate sollte gegen die aktuellen Parameter geprüft werden und nicht gegen die ursprüngliche Aufgabenfreigabe.

Offensive Perspektive für autorisierte Prüfungen

Für autorisierte Tests ist nicht die Frage entscheidend, ob ein Modell beeinflussbar ist. Das ist es meist. Entscheidend ist, welcher realistische Pfad von einer legitim kontrollierbaren Quelle zu einer sicherheitsrelevanten Wirkung führt und welches Gate ihn zuerst stoppt.

Berichtet wird das tiefste tatsächlich beobachtete Gate. Ein beeinflusster Plan, der die Autorisierung nie passiert hat, ist ein Beeinflussungsbefund und keine unautorisierte Aktion. Diese Präzision macht das Ergebnis erst verwertbar. Die Seite beschreibt Barrieren und Messung; sie liefert keine wiederverwendbaren Injection-Strings, keine Verschleierung und keine Exfiltrationsprozedur.

Die Erfolgskette der Tool-Output-Injection

Konkurrierende Randbedingungen

Diese Randbedingungen sind zugleich die Entwurfsziele. Jede deterministische Schranke unterbricht die Kette. Je nachdem, an welcher Stelle sie hält, reicht das Ergebnis von gar keiner Modellexposition bis zu beobachtbarer Beeinflussung ohne sicherheitsrelevante Wirkung.

Offensive Review-Fragen

Beispielszenario: begrenzte Fallprüfung im Support

Ein Support-Agent-Workflow soll einen synthetischen Kundendatensatz zusammenfassen und einen nächsten Schritt vorschlagen. Ein kundenbeschreibbares Feld in den Testdaten enthält anweisungsartigen Text, der ein sachfremdes Ziel formuliert und ein anderes internes Tool sowie eine externe Empfängeradresse benennt.

Das Szenario nutzt synthetische Daten, begrenzte Berechtigungen und umkehrbare Effekte. Sein Wert liegt darin, zu zeigen, welches Gate gehalten hat: Der Agent wurde beeinflusst, der Vorschlag war beobachtbar, und die deterministische Schicht außerhalb des Modells hat entschieden.

Fähigkeiten und Autorisierungsgrenzen

Ein Vorschlag ist eine Anfrage, keine Erlaubnis. Jede der folgenden Handlungen ist eine eigene Fähigkeit mit eigener Entscheidung: einen Datensatz lesen, eine Folgesuche ausführen, eine URL abrufen, eine Datei öffnen, eine Nachricht senden, einen Datensatz aktualisieren, ein Ticket anlegen, einen ausgehenden Netzaufruf tätigen und Code ausführen.

1. 01
   Initiierende Identität

   Jede Aktion gegen die aktuellen Rechte der startenden Person oder des startenden Dienstes prüfen, nicht gegen die maximale Reichweite des Agenten.

2. 02
   Aufgabenbezogene Fähigkeit

   Kurzlebige, eng begrenzte Fähigkeiten für die konkrete Aufgabe vergeben statt dauerhaft verfügbarer Zugriffe.

3. 03
   Ziel und Datenklasse

   Getrennt entscheiden, welche Ressourcen gelesen werden dürfen und welche Empfänger, Hosts oder Endpunkte Daten erhalten dürfen.

4. 04
   Bindung an die exakte Aktion

   Freigabe und Autorisierung an eine unveränderliche oder eindeutig identifizierbare Aktion, Ressource, ein Ziel, Parameter und Zustand binden, niemals pauschal an den Workflow.

5. 05
   Neuautorisierung bei Änderung

   Ändern sich relevante Parameter oder der zugrunde liegende Zustand zwischen Vorschlag und Ausführung, erneut autorisieren; eine pauschale Workflow-Freigabe ersetzt das nicht und schließt TOCTOU-Lücken.

6. 06
   Trennung der Wirkungen

   Vorschlagen, Lesen, Schreiben, Senden und Ausführen als unabhängig vergebbare Rechte führen.

Informationsfluss und Egress

Tool-Ergebnisse sind doppelt flussrelevant: Sie können sensible Daten enthalten und zugleich neue Ziele dafür vorschlagen. Ein Workflow, der vertrauliche Datensätze liest und beliebige ausgehende Endpunkte aufrufen darf, vereint beide Hälften eines Exfiltrationspfads in einem Agenten.

Erkennung, Telemetrie und ihre Grenzen

Prompt-Injection-Klassifikatoren, Ergebnis-Scanner und Heuristiken sind wertvolle Signale und können Annotate-and-Block-Kontrollen stützen, sie sind aber probabilistisch. Sie erzeugen falsch positive und falsch negative Befunde und dürfen weder alleinige Autorisierungskontrolle noch Beweis für die Unbedenklichkeit eines Ergebnisses sein. Auch Telemetrie belegt Abfolge und Korrelation, nicht die interne Kausalität im Modell.

Prävention und sichere Architektur

1. 01
   Standardmäßig untrusted

   Jedes Tool-Ergebnis als nicht vertrauenswürdig behandeln, solange keine eigene, explizite Provenienz- und Vertrauensentscheidung vorliegt.

2. 02
   Provenienz und Feldgrenzen erhalten

   Quellidentität, Feldgrenzen und Struktur sichtbar halten, statt alles zu einem Textblock zu verschmelzen.

3. 03
   Zurückgelieferten Inhalt minimieren

   Nur benötigte Felder auswählen, Größen begrenzen und keine vollständigen Nutzlasten in den Kontext kippen.

4. 04
   Schema-bewusstes Parsing

   Struktur und Typen validieren, dabei klar benennen, dass Schema-Gültigkeit kein semantisches Vertrauen ist.

5. 05
   Kanäle trennen

   Datenkanäle in der Prompt-Architektur von Anweisungs- und Konfigurationskanälen getrennt halten.

6. 06
   Deterministische Autorisierung

   Aktionen, Ressourcen und Ziele außerhalb des Modells in Code und Policy entscheiden.

7. 07
   Least Privilege und aufgabenbezogene Tools

   Nur die für eine Aufgabe nötigen Tools bereitstellen, mit engstem Umfang und kürzester Lebensdauer.

8. 08
   Egress einschränken

   Ausgehende Ziele und Datenklassen unabhängig von der Modellausgabe begrenzen.

9. 09
   Freigabe an die exakte Aktion

   Menschliche Freigaben an geprüfte Aktion, Parameter und Ziel binden und bei Änderung neu prüfen.

10. 10
    Isolation

    Ausführung und Dateiverarbeitung in Sandboxes ohne im Agentenkontext dauerhaft verfügbare Secrets und ohne sensiblen lokalen Zustand betreiben.

11. 11
    Minimierung sensibler Daten

    Sensible Werte redigieren oder zurückhalten, wo die Aufgabe sie nicht benötigt.

12. 12
    Erkennung als Signal

    Scanning und Anomalieerkennung zur Ereignisbildung nutzen, nie als Ersatz für Autorisierung.

13. 13
    Abgeleiteten Zustand invalidieren

    Lineage führen, damit Zusammenfassungen, Memory, Caches und Indizes gezielt invalidiert und neu aufgebaut werden können.

Persistenz und abgeleitete Artefakte

Tool-Ergebnisse enden oft nicht mit der Aufgabe. Sie fließen in Gesprächszusammenfassungen, Agent-Memory, Caches, Vektorindizes, erzeugte Tickets, Notizen und Berichte. Diese abgeleiteten Artefakte können den Quelldatensatz überdauern und in späteren Aufgaben, auch für andere Personen, ohne ursprüngliche Zuordnung wieder auftauchen.

Incident Response

Kontrollierte Sicherheitstests und Metriken

Getestet wird mit synthetischen Daten, begrenzten Berechtigungen und umkehrbaren Effekten in einer Umgebung, die die reale Tool-Topologie abbildet. Jedes Gate wird getrennt mit explizitem Nenner berichtet und nicht zu einer Gesamtzahl verrechnet, weil ein Summenwert verdeckt, welche Kontrolle tatsächlich gehalten hat.

Das Lab zur Tool-Output-Injection ist eine kontrollierte Simulation, um diese Grenzen zu üben: ein vertrauenswürdiges Tool mit nicht vertrauenswürdigem Inhalt, antwortseitige Ergebnisbehandlung sowie die Autorisierung von Folge-Tools, Zielen und Aktionen. Es nutzt nur fiktive Daten und enthält keine Payloads.

Ob eine erfolgreiche Beeinflussung für die nutzende Person sichtbar gewesen wäre, ist eine legitime zusätzliche Forschungsdimension. Neuere Arbeiten zu Tool-nutzenden Agenten zerlegen Angriffserfolg in verdeckte und offene Ergebnisse und argumentieren, dass die Sichtbarkeit im Antworttext das praktische Risiko verändert. Das gehört als attribuierte Nuance in den Bericht, nicht als Hauptmetrik.

Häufige Missverständnisse

Standards und Forschungskontext

OWASP LLM01:2026 behandelt indirekte Injection über externe Quellen, die eine Anwendung verarbeitet. NIST definiert indirect prompt injection als Prompt Injection über resource control und definiert resource control gesondert als Kontrolle externer Ressourcen, die zur Inferenzzeit konsumiert werden. Beide beschreiben Mechanismus, nicht garantierte Auswirkung.

Die Zero-Trust- und Retrieval-Hygiene-Leitlinien von Microsoft empfehlen, externe Daten und Daten im Modellkontext als nicht vertrauenswürdig zu behandeln und Provenienz sowie Berechtigungen bei jedem Lesen und Schreiben zu erhalten. Microsoft Foundry dokumentiert Tool Response als Interventionspunkt, derzeit in der Preview, an dem die vollständige von einem Tool zurückgegebene Nutzlast auf indirekte Angriffe geprüft werden kann, bevor sie in den Agent-Speicher gelangt oder an die nutzende Person zurückgeht; die Interventionspunkte für Tool-Aufruf und Tool-Antwort gelten nur für die dort als unterstützt dokumentierten Tool-Pfade und nicht als allgemeine Eigenschaft von Foundry. Die Sicherheitsleitlinie des Microsoft Agent Framework behandelt Inhalte der Rolle Tool ausdrücklich als nicht vertrauenswürdig, weil von Tools gelieferte Daten aus externen oder nutzerbeeinflussten Quellen stammen können. Das sind Produktfähigkeiten und Empfehlungen und werden hier auch so benannt, nicht als universelle Eigenschaften.

Greshake et al. berichten die praktische Umsetzbarkeit indirekter Prompt Injection gegen reale LLM-integrierte Anwendungen. Neuere Arbeiten adressieren gezielt die Tool-Grenze: AttriGuard beschreibt adversariale Anweisungen in nicht vertrauenswürdigen Tool-Ausgaben und schlägt eine Laufzeitverteidigung über kausale Attribution von Tool-Aufrufen vor; eine Arbeit von 2026 schlägt Abwehr indirekter Prompt Injection über Tool Result Parsing vor; eine Studie von 2026 zerlegt Angriffserfolg aus Nutzersicht in verdeckte und offene Ergebnisse. ToolHijacker betrifft einen anderen Schritt, nämlich die Manipulation der Tool-Auswahl über die Tool-Bibliothek, und wird hier nur zur Abgrenzung genannt. Keine dieser Arbeiten wird hier als Angriffsprozedur reproduziert.

Häufige Fragen