Prompt-Injection-Abwehr am Gateway: Direkte, indirekte und tool-gestützte Angriffe

Prompt Injection ist das zentrale Problem der Anwendungssicherheit bei LLM-Systemen und hat eine strukturelle Ursache: Das Modell liest vertrauenswürdige Anweisungen und nicht vertrauenswürdige Daten über denselben Kanal, ohne dass eine zuverlässige Unterscheidung möglich ist. Dieser Beitrag erläutert das Bedrohungsmodell und die Verteidigungsstrategien – wie direkte, indirekte und toolgestützte Injection funktionieren, warum das Modell Anweisungen nicht von Daten trennen kann, warum kein einzelner Detektor ausreicht und wie Input- und Output-Guardrails sowie eine Privilegien-Trennung am Gateway das Schadensausmaß begrenzen.

Mittwoch bei Northwind. Yuki, eine Ingenieurin für Anwendungssicherheit, beobachtete eine Demo des neuen Support-Agenten, als dieser plötzlich etwas tat, das niemand angefordert hatte. Ein Kundendienstmitarbeiter hatte die E-Mail eines Anbieters in den Agenten kopiert und ihn gebeten, den Streitfall zusammenzufassen. In der E-Mail verborgen – in blassem Text, den der Mitarbeiter nie gelesen hatte – befanden sich Anweisungen, die nicht an den Menschen, sondern an den Assistenten gerichtet waren: den offenen Streitfall zu schließen und eine Kulanzgutschrift zu erteilen. Der Agent verfügte über ein Tool zur Anpassung von Kontogutschriften. Er las die E-Mail, „verstand“ die Anweisungen als Teil seiner Aufgabe und erteilte die Gutschrift. Kein Kunde hatte etwas angegriffen. Kein Passwort war durchgesickert. Die bösartigen Anweisungen waren einfach in einem Dokument enthalten, das der Agent lesen sollte, und der Agent konnte nicht zwischen der Anfrage des Mitarbeiters und dem Inhalt der E-Mail unterscheiden.

Das ist Prompt Injection, und es ist kein Problem der Formulierung, das durch einen besseren System-Prompt gelöst werden kann. Es ist strukturell bedingt: Das Modell empfängt Anweisungen und Daten über einen einzigen Kanal. Dieser Beitrag zeigt, wie diese Angriffsfamilie funktioniert und wie man ihr Schadensausmaß minimiert – im Bewusstsein, dass es hier keine vollständige Verteidigung gibt, sondern nur eine mehrschichtige.

Was das AI Gateway von TrueFoundry hier bietet

Jede Verteidigungsmaßnahme in diesem Beitrag – Erkennung auf der Input-Seite, Überprüfung auf der Output-Seite, Scannen von Kontext und Tool-Ergebnissen sowie die Rollout-Disziplin, die es ermöglicht, eine Guardrail bereitzustellen, bevor sie die Produktion beeinträchtigen kann – findet sich in TrueFoundrys Guardrail-System als Konfiguration, die an vier Lifecycle-Hooks angewendet wird: llm_input, llm_output, mcp_pre_tool, und mcp_post_tool. Die Hooks entsprechen dem Bedrohungsmodell dieses Beitrags: llm_input fängt die direkte Injection im User-Turn ab; llm_output ist die Exfiltrationsprüfung; mcp_pre_tool ist der Punkt, an dem eine Cedar- oder OPA-Richtlinie entscheidet, ob ein Tool-Aufruf überhaupt zulässig ist; mcp_post_tool ist der Punkt, an dem Sie prüfen, was das Tool zurückgegeben hat, bevor das Modell es liest – der Einfügepunkt für indirekte Injektionen, den reine Eingabesysteme übersehen.

Jede Leitplanke verfügt über zwei operativ relevante Einstellungen: einen Betriebsmodus (Validieren – prüft und blockiert; oder Mutieren – schreibt um und fährt fort, z. B. bei der PII-Schwärzung) und eine Durchsetzungsstrategie (Audit, Durchsetzen, aber bei Fehlern ignorieren, oder Erzwingen). Die mittlere Einstellung macht ein Guardrail sicher in der Bereitstellung: Sie bleiben geschützt, wenn das Rail funktioniert, aber ein Ausfall des Sicherheitsanbieters eines Drittanbieters legt nicht Ihre App lahm. Das empfohlene Rollout ist dasselbe, für das dieser Beitrag plädiert: Audit → Erzwingen-aber-bei-Fehler-ignorieren → Erzwingen, in dieser Reihenfolge, wobei die Latenz- und Fehlalarmzahlen in den Request Traces jede Stufe vorantreiben.

Der Anwendungscode bleibt gleich; die Richtlinie befindet sich in den Headern oder der zentralen Regelkonfiguration. Das folgende Beispiel verwendet den Request-spezifischen X-TFY-GUARDRAILS Header (praktisch, wenn verschiedene Routen unterschiedliche Rails benötigen); für die unternehmensweite Durchsetzung befinden sich dieselben Selektoren unter AI Gateway → Controls → Guardrails:

Aufruf des Gateways mit aktivierten Guardrails (Python, OpenAI-kompatibel)

from openai import OpenAI

client = OpenAI(
    base_url="https://<your-truefoundry-gateway-url>",
    api_key="<your-virtual-account-token>",
)

resp = client.chat.completions.create(
    model="openai-main/gpt-5.5",
    messages=[{"role": "user", "content": user_prompt}],   # may include untrusted context (RAG, emails)
    extra_headers={
        # Guardrails attach at the four hooks. Input validation runs in parallel
        # with the model — no TTFT penalty when the request is clean.
        # Values are guardrail FQNs (group/name), copied from AI Gateway → Guardrails.
        "X-TFY-GUARDRAILS": (
            '{"llm_input_guardrails":["my-group/prompt-injection","my-group/pii-redaction"],'
            '"llm_output_guardrails":["my-group/secrets-detection"],'
            '"mcp_tool_pre_invoke_guardrails":["my-group/sql-sanitizer","my-group/cedar-tool-policy"],'
            '"mcp_tool_post_invoke_guardrails":["my-group/pii-redaction"]}'
        ),
    },
)
print(resp.choices[0].message.content)

1. Die strukturelle Wurzel: Anweisungen und Daten teilen sich einen Kanal

Ein herkömmliches Programm trennt Code und Daten: Code ist die Logik, Daten sind das, worauf die Logik operiert, und eine Zeichenfolge von Benutzerdaten kann nicht zu einer neuen Anweisung werden, es sei denn, es liegt ein Injection-Fehler vor. Ein LLM kennt diese Trennung nicht. Der System-Prompt, die Nachricht des Benutzers, ein abgerufener Dokumenteninhalt und die Ausgabe eines Tools werden alle zu einem einzigen Token-Stream zusammengefügt, und das Modell entscheidet anhand des gesamten Inhalts, was zu tun ist. Es gibt kein Feld, das besagt: „Dieser Teil ist eine verbindliche Anweisung“ und „Dieser Teil sind lediglich zu verarbeitende Daten“, das vom Modell zuverlässig respektiert wird.

Dies ist dieselbe strukturelle Form, die auch an anderer Stelle in dieser Serie auftaucht. In RAG und PIIgelangen abgerufene Dokumente in denselben Kontext wie der Prompt des Benutzers, weshalb eine abgerufene Sozialversicherungsnummer (SSN) wieder zitiert wird. Bei Tool-Poisoning-Angriffen auf MCP-Serververstecken sich Anweisungen in Tool-Metadaten, die das Modell als verbindlich behandelt. Prompt Injection ist der allgemeine Fall: Jeder nicht vertrauenswürdige Text, der den Kontext erreicht, kann versuchen, als Anweisung zu fungieren, und das Modell hat keine eingebaute Möglichkeit, dies mit der Begründung abzulehnen, dass „dies aus Daten stammt und nicht von meinem Betreiber“.

2. Eine Taxonomie der Angriffe: Direkt, indirekt, tool-gestützt, Jailbreak

Die Angriffe unterscheiden sich dadurch, wo die bösartige Anweisung eindringt, was deshalb wichtig ist, weil jeder Eintrittspunkt eine andere Kontrollmaßnahme erfordert.

Direkte Injection und Jailbreaks sind zumindest an der Eingabegrenze sichtbar, wo man die Möglichkeit hat, sie zu überprüfen. Indirekte und tool-gestützte Injection sind genau deshalb die schwierigeren Probleme, weil der bösartige Text nicht in der Nachricht des Benutzers ankommt – er gelangt über das Dokument, das der Agent zusammenfassen soll, die Webseite, die der Agent abgerufen hat, oder den Datensatz, den ein Tool zurückgegeben hat, in das System. Jede Verteidigung, die nur die Benutzereingaben prüft, ist gegenüber genau den Fällen blind, die im Einstiegsszenario beschrieben wurden.

3. Das tödliche Trio: Warum Fähigkeiten das Risiko vervielfachen

Injection wird dann kritisch, wenn sie auf Fähigkeiten trifft. Die nützliche Einordnung, oft als das „tödliche Trio“ bezeichnet, besagt, dass die wahre Gefahr dann entsteht, wenn ein einzelner Agent gleichzeitig drei Dinge besitzt: Zugriff auf private Daten, Kontakt mit nicht vertrauenswürdigen Inhalten und einen Kanal, um Daten nach außen zu senden. Wenn alle drei Faktoren zusammenkommen, kann ein Inhalt, den der Agent lediglich liest , ihn dazu anweisen, seine privaten Daten zu nehmen und über den Ausgangskanal zu versenden – wodurch ein passives Dokument zu einem Exfiltrationsbefehl wird.

‍