Prompt-Injection-Angriffe auf KI-Agenten: Was sie sind und wie Runtime-Enforcement sie stoppt

Dies ist Prompt Injection, und im Jahr 2026 ist es das Sicherheitsrisiko Nummer eins für autonome KI-Agenten. Es ist zugleich ein Problem, das das Modell nicht allein lösen kann.

Was Prompt Injection ist

Prompt Injection ist ein Angriff, bei dem nicht vertrauenswürdige Inhalte — ein E-Mail-Text, eine Webseite, ein PDF, ein Suchergebnis, ein Datenbankfeld — Anweisungen enthalten, die von einem LLM ausgeführt werden sollen. Da LLMs allen Text im Kontextfenster als Anweisungen unterschiedlicher Priorität behandeln, kann ein Angreifer Befehle in die Reasoning-Schleife des Agenten einschleusen, indem er schlicht einen Teil der verarbeiteten Eingabe kontrolliert.

Es gibt zwei Hauptvarianten:

• Direkte Injection: Der Angreifer interagiert direkt mit dem Agenten — etwa durch adversarielle Texteingabe in einem Chat oder an einem API-Endpunkt. Dies ist die Variante, an die die meisten Menschen zuerst denken.
• Indirekte Injection: Der Angreifer platziert schädliche Anweisungen in Inhalten, die der Agent später liest — eine Webseite, die der Agent besucht, eine E-Mail, die er verarbeitet, ein Dokument, das er zusammenfasst. Der Angreifer kommuniziert dabei nie direkt mit dem Agenten. Diese Variante ist weitaus gefährlicher, weil die Nutzenden dem Agenten vertrauen und der Agent seinen Eingaben vertraut.

Reale Vorfälle haben beide Kategorien berührt: die Bing/Sydney-Enthüllungen von 2023, die EchoLeak-Klasse von Schwachstellen in E-Mail-verarbeitenden Agenten aus dem Jahr 2024 sowie eine wachsende Sammlung von Forschungsdemonstrationsfällen, bei denen Agenten mit Browser-Tools, Shell-Zugriff oder Zahlungsschnittstellen durch vollständig passive Eingaben zu destruktiven Aktionen verleitet wurden.

Warum Schutzmaßnahmen auf Modellebene versagen

Alle großen Modellanbieter haben eine Form von “Instruction Hierarchy” eingeführt — eine Konvention, bei der der System-Prompt den User-Prompt überwiegt, der wiederum Tool-Outputs überwiegt. In der Theorie sollte dies Prompt Injection erschweren. In der Praxis sind Instruction Hierarchies Präferenzen, keine Invarianten. Das Modell entscheidet weiterhin Token für Token, was als Nächstes passiert. Eine hinreichend überzeugende Injection — insbesondere eine, die Ton und Struktur einer legitimen Systemnachricht imitiert — wird einen gewissen Anteil der Zeit befolgt.

Drei Eigenschaften machen dies auf der Modellebene allein unlösbar:

• Keine kryptografische Grenze zwischen Daten und Code. Alle Texte im Kontextfenster teilen dasselbe Vertrauensniveau. Es gibt kein Äquivalent zur prepared-statement-Parametrisierung wie in SQL.
• Vom Angreifer kontrollierte Distributionsverschiebung. Der Angreifer schreibt den Prompt; das Modell muss auf adversarielle Eingaben generalisieren, die es nie zuvor gesehen hat. Eine einzige erfolgreiche Variante genügt.
• Komposierbarkeit. Agenten verketten Tool-Calls. Eine harmlos erscheinende Aktion (eine URL abrufen) kann Inhalte erzeugen, die die nächste Aktion kapern (eine E-Mail versenden). Die Injection muss in der Kette nur einmal gelingen.

Erkennung ist keine Prävention

Eine verbreitete Reaktion auf Prompt Injection ist das Hinzufügen eines Klassifikators: Jede Eingabe wird auf verdächtige Muster gescannt (“Ignoriere vorherige Anweisungen,” Base64-Payloads, ungewöhnliche Unicode-Zeichen), und auffällige Eingaben werden markiert oder blockiert. Muster-Scanner, Perplexitätsheuristiken und Klassifikatorensembles gehören alle in diese Kategorie.

Sie helfen — bis sie es nicht mehr tun. Erkennungssysteme führen ein Wettrennen mit einem kreativen, motivierten Angreifer. Angreifer verschleiern Payloads mit Homoglyphen, übersetzen Anweisungen in seltene Sprachen, verstecken Befehle in Metadaten oder arbeiten sich per Chain-of-Thought an einem Klassifikator vorbei. Schlimmer noch: Ein Detektor befindet sich weiterhin außerhalb des Enforcement-Loops. Er produziert einen Score, keine Entscheidung. Wird der Score ignoriert, falsch weitergeleitet oder erst nach der bereits ausgeführten Aktion ausgewertet, bietet er keinen Schutz.

Das Ziel ist nicht zu wissen, ob eine Eingabe adversariell ist. Das Ziel ist sicherzustellen, dass der Agent — ob adversariell oder nicht — nur Aktionen ausführen kann, die für diesen Kontext autorisiert sind.

Runtime-Enforcement: Der Tool-Call als Vertrauensgrenze

Runtime-Enforcement akzeptiert, dass das Modell manchmal getäuscht wird, und verschiebt die Vertrauensgrenze nach außen — an den Punkt, an dem der Agent tatsächlich etwas tun möchte. Bevor ein Tool-Call ausgeführt wird, bewertet eine Governance-Schicht den Aufruf anhand einer deklarativen Policy und entscheidet: erlauben, ablehnen oder menschliche Genehmigung erfordern.

Dies ist konzeptionell identisch damit, wie Betriebssysteme mit nicht vertrauenswürdigen Programmen umgehen: Das Programm kann berechnen, was es möchte, aber es kann ohne die Zustimmung des Kernels keinen Socket öffnen, keine Datei schreiben und keinen Prozess starten. Das Modell ist das nicht vertrauenswürdige Programm. Die Policy-Engine ist der Kernel.

Die wichtigsten Enforcement-Muster für Prompt-Injection-Resistenz:

• Tool-Allowlists. Ein Agent, der nur read_inbox und summarize benötigt, sollte physisch nicht in der Lage sein, send_email, delete_message oder exec_shell aufzurufen — unabhängig davon, was die Injection forderte.
• Datengrenzen-Policies. Ein Tool-Call, dessen Argumente aus nicht vertrauenswürdigen Inhalten stammen (eine abgerufene URL, ein eingehender E-Mail-Text), wird mit einem Taint markiert. Sensible Senken — Zahlungs-APIs, ausgehende E-Mails, Datenbankschreibzugriffe — lehnen mit Taint behaftete Argumente ab.
• Genehmigungstore für Menschen. Hochriskante Aktionen — Geldtransfers, Nachrichten an externe Empfänger, Privilegieneskalationen — werden für eine menschliche Freigabe via Slack, Dashboard oder Webhook angehalten. Injizierte “dringende” Formulierungen können das Gate nicht umgehen, weil das Gate außerhalb der Kontrollebene des Modells liegt.
• Rate-Limits und Kostenbudgets. Selbst wenn eine Injection durchschlüpft, begrenzen ein begrenzter Blast-Radius (N Tool-Calls pro Stunde, $X Tagesausgaben für bezahlte APIs) den Schaden eines Vorfalls.

Ein konkretes Policy-Beispiel

Stellen Sie sich einen Agenten vor, der E-Mails liest, lange Threads zusammenfasst und im Namen des Nutzers antworten kann. Der offensichtliche Injection-Vektor ist eine eingehende E-Mail, deren Text den Agenten anweist, sensible Nachrichten weiterzuleiten. Eine Policy, die dies verhindert, sieht so aus:

policy "outbound-email-requires-user-origin" {
  target  = "tool:send_email"
  deny_if = argument("to").domain NOT IN workspace.allowed_domains
           OR argument("body").taint CONTAINS "fetched_content"
           OR argument("body").taint CONTAINS "inbound_email_body"
  require_approval_if = argument("to").is_external
}

Diese Regel versucht nicht, Prompt Injection zu erkennen. Sie kümmert sich nicht darum, ob der E-Mail-Text adversariell ist. Sie erklärt schlicht: Wenn der Inhalt einer ausgehenden E-Mail aus einer nicht vertrauenswürdigen Quelle stammt, wird der Versand blockiert. Injection wird irrelevant, weil die injizierte Aktion nicht ausgeführt werden kann.

Tiefenverteidigung statt Wundermittel

Runtime-Enforcement ersetzt keine Erkennung, keine Eingabe-Bereinigung und kein Least-Privilege-Design — es ergänzt diese. Eine produktionsreife Sicherheitsstrategie schichtet alle vier:

1. Angriffsfläche minimieren. Jeden Agenten auf die kleinstmögliche Menge an Tools und Daten beschränken, die er wirklich benötigt.
2. Eingaben bereinigen und kennzeichnen. Steuerzeichen entfernen, Inhalte nicht vertrauenswürdiger Herkunft markieren, Provenienz-Metadaten erhalten, damit Policies sie einsehen können.
3. Adversarielle Eingaben erkennen. Klassifikatoren einsetzen, um offensichtliche Injection-Versuche abzufangen und Incidents zu erzeugen — nützliches Signal, aber niemals die letzte Verteidigungslinie.
4. Am Tool-Call durchsetzen. Deklarative Policies, synchron ausgewertet, die jede Aktion blockieren oder pausieren können — unabhängig davon, wie sie zustande kam.

Die ersten drei reduzieren die Häufigkeit erfolgreicher Injections. Das vierte stellt sicher, dass der Blast-Radius an der Policy-Grenze stoppt, wenn eine Injection dennoch gelingt.

Einordnung in ein Agenten-Governance-Programm

Prompt Injection ist eine Bedrohungsklasse innerhalb eines umfassenderen Bildes der Agenten-Governance, das auch Datenlecks, Kostenüberschreitungen, unbefugten Tool-Einsatz und Compliance-Nachweise umfasst. Die gemeinsame Infrastruktur — eine Policy-Engine vor jedem Tool-Call mit audit-tauglichen Protokollen zu jeder Entscheidung — adressiert alle diese Anliegen gleichzeitig. Sie nachträglich nach einem Vorfall einzurichten ist schwieriger, langsamer und macht die E-Mail, die nicht hätte versendet werden dürfen, nicht ungeschehen.

Execlave liefert Runtime-Policy-Enforcement, Taint-Tracking-Datengrenzen und Genehmigungstore direkt einsatzbereit, mit erstklassiger Unterstützung für die wichtigsten Agenten-Frameworks. Die vollständige Grammatik finden Sie in der Policy Reference; wie diese Kontrollen mit SOC 2, HIPAA und dem EU AI Act übereinstimmen, zeigen die Compliance-Mappings.