Die Lethal Trifecta: Ein praktischer Test für Prompt-Injection-Risiko

Alle paar Wochen verkündet ein Anbieter, Prompt Injection gelöst zu haben. Ein neuer Klassifikator, ein strengerer System-Prompt, ein Guardrail-Modell, das die Ausgabe überwacht. Und alle paar Wochen veröffentlicht jemand einen Bypass, meist binnen Tagen, meist peinlich simpel.

Das ist keine Inkompetenz, sondern die Form des Problems. Ein LLM erhält einen einzigen Token-Strom und hat keine verlässliche Möglichkeit zu erkennen, welche davon Anweisungen von dir waren und welche Daten von irgendwoher. Das OWASP-GenAI-Projekt sagt es unumwunden: Angesichts der Funktionsweise dieser Modelle ist unklar, ob narrensichere Prävention überhaupt existiert. Die nützliche Frage lautet also nicht „wie blockiere ich Injections”, sondern „was passiert, wenn eine durchkommt” — und dafür gibt es einen sehr guten Test.

Warum 99 % eine Fünf sind

Der Vergleich, zu dem alle greifen, ist SQL-Injection — und er ist genau der falsche. Nicht weil der Mechanismus abweicht, sondern weil sich die Lösung nicht übertragen lässt.

SQL-Injection wurde gelöst. Parametrisierte Abfragen schaffen eine echte Grenze: Die Abfragestruktur läuft über einen Kanal, die Werte über einen anderen, und die Datenbank verwechselt sie nie. Die Fehlerklasse ist konstruktiv geschlossen.

Für ein LLM gibt es keine parametrisierte Abfrage. Deine Anweisungen, das abgerufene Dokument, das Support-Ticket und die Webseite kommen alle aneinandergehängt im selben Kontext an, und das Modell entscheidet über Gehorsam anhand von nicht viel mehr als Tonfall und Plausibilität. Simon Willison, der im Sommer 2022 zu denen gehörte, die den Begriff „Prompt Injection” unabhängig voneinander prägten, hat die Konsequenz auf einen merkenswerten Satz gebracht:

In der Anwendungssicherheit sind 99 % eine Fünf.

Ein Spamfilter mit 99 % ist hervorragend, weil Spammer im Moment nicht adaptiv sind. Ein Prompt-Injection-Filter mit 99 % ist eine Tür, die beim hundertsten Versuch aufgeht — und der Angreifer hat unbegrenzt Versuche und keine Deadline.

Wir haben das beobachten können. Microsoft betreibt Klassifikatoren für das, was sie XPIA nennen — cross/indirect prompt injection attack. Die Schwachstelle EchoLeak in Microsoft 365 Copilot, geführt als CVE-2025-32711, umging sie mit der raffinierten Technik, die bösartige E-Mail so zu formulieren, als richte sie sich an einen Menschen, ohne KI oder Assistenten je zu erwähnen.

Die Lethal Trifecta

Im Juni 2025 benannte Willison das Muster, das aus einer lästigen Injection einen Vorfall macht. Ein LLM-System ist gefährlich, wenn es alle drei Eigenschaften hat:

1. Zugriff auf private Daten — deine E-Mails, deine Repositories, deine Kundendaten
2. Kontakt mit nicht vertrauenswürdigen Inhalten — alles, was ein Angreifer beeinflussen kann
3. Die Fähigkeit zur externen Kommunikation — jeder Kanal, der Daten hinausträgt

Zwei davon sind überlebbar. Ein Agent mit deinen privaten Daten und einem Ausgangskanal, aber ohne von Angreifern kontrollierte Eingaben, bekommt keine bösartigen Befehle. Ein Agent, der feindliche Webseiten liest, aber keine privaten Daten hat, besitzt nichts Stehlenswertes. Erst das dritte Bein schließt den Stromkreis.

Wenn dir diese Form bekannt vorkommt: zu Recht. Das Chromium-Sicherheitsteam arbeitet seit 2019 nach der Rule of 2 — kombiniere niemals nicht vertrauenswürdige Eingaben, eine unsichere Implementierungssprache und hohe Privilegien; wähle höchstens zwei. Die Trifecta ist derselbe Ingenieursinstinkt, angewandt auf Agenten, und das spricht für sie. Kein neu erfundenes KI-Framework, sondern ein Muster, das ein Jahrzehnt Browsersicherheit überstanden hat.

Wende den Test auf dein eigenes System an

Der Wert der Rahmung liegt darin, dass sie sich in ein Audit übersetzt. Drei Fragen, in dieser Reihenfolge.

Auf welche privaten Daten kommt dieser Agent? Nicht, worauf er kommen soll — worauf seine Zugangsdaten tatsächlich Zugriff geben. Der Supabase-MCP-Vorfall ist lehrreich: Der Agent arbeitete mit dem service_role-Schlüssel, der Row-Level Security vollständig umgeht. Beabsichtigter und tatsächlicher Geltungsbereich waren zwei verschiedene Dokumente.

Wo dringen nicht vertrauenswürdige Inhalte ein? Dieses Bein wird durchgängig unterschätzt. Bösartige Anweisungen kamen bereits über Zendesk-Tickets, die zu Jira-Issues wurden, über öffentliche GitHub-Issues, ein PDF mit weißer Schrift auf weißem Grund, eine Webseite in 1-Pixel-Schrift, Code-Kommentare und Paketdokumentation, die dem Agenten sagte, er solle einen Installer ausführen. Wenn ein Fremder auch nur ein Byte beeinflussen kann, das dein Modell liest, brennt dieses Bein.

Wie könnten Daten hinausgelangen? Ebenfalls breiter als gedacht. Nicht nur HTTP-Aufrufe — ein gerendertes Markdown-Bild, ein Link, den der Nutzer anklickt, eine Antwort im öffentlichen Issue, das den Angriff startete, ein Datenbankschreibvorgang, eine Suchanfrage an eine vom Angreifer kontrollierte URL. Im Bericht zu Notion 3.0 war der Exfiltrationskanal das eigene Websuch-Werkzeug des Agenten, weil es neben Suchbegriffen auch URLs akzeptierte.

Drei Ja bedeuten: Du hast die Trifecta. Nicht „du bist möglicherweise verwundbar” — du hast die Voraussetzung, und offen ist nur noch, ob sich jemand die Mühe gemacht hat.

Eine Integration kann alle drei sein

Die Falle, in die Teams tappen, ist die Annahme, die Beine kämen aus verschiedenen Quellen — also verantwortet niemand die Summe.

Der Exploit des GitHub-MCP-Servers, von Invariant Labs im Mai 2025 veröffentlicht, brauchte gar keine Kombination. Eine offizielle Integration lieferte privaten Repository-Zugriff, Kontakt mit von Angreifern verfassten öffentlichen Issues und einen Veröffentlichungskanal über Pull Requests. Ein Nutzer, der seinen Agenten bat, „mal in die Issues zu schauen”, reichte aus, um die Namen seiner privaten Repositories zu leaken.

Dieselbe Form wurde seither gegen den Supabase-MCP und Atlassians Remote-MCP-Server gezeigt — letzteres von Catos Forschern treffend als „living off AI” zusammengefasst. Atlassians eigene Beschreibung verrät es: Arbeit zusammenfassen, Issues anlegen, mehrstufige Aktionen ausführen. Das sind private Daten, nicht vertrauenswürdige Eingaben aus öffentlichen Issues und ein Ausgangskanal, in einem Produkt.

Deshalb zählt Autorisierung pro Werkzeug mehr als Vertrauen pro Server — und das ist die praktische Begründung für die benutzerbezogene Zugriffskontrolle für MCP-Gateways: standardmäßig verweigern, einzelne Werkzeuge freigeben, bei der Ausführung durchsetzen und nicht nur zur Inferenzzeit. Wer selbst Server baut statt sie zu konsumieren, findet dasselbe Grenzdenken im MCP-Server-Leitfaden.

Welches Bein du kappst

Den Zugriff auf private Daten kannst du nicht entfernen — er ist meist der ganze Zweck des Agenten. Nicht vertrauenswürdige Inhalte kannst du realistisch ebenso wenig ausschließen; die Liste oben zeigt, wie viele Türen dieses Bein hat, und Cursors Antwort auf den Jira-Exploit lief darauf hinaus, Nutzer mögen nur vertrauenswürdige Quellen anbinden — das ist keine Kontrolle.

Bleibt die externe Kommunikation, und sie ist aus einem Grund die richtige Antwort, der nichts mit Bequemlichkeit zu tun hat: Sie ist das einzige Bein, das sich deterministisch außerhalb des Modells durchsetzen lässt, durch Code, den man nicht umstimmen kann.

OpenAIs Lockdown Mode, inzwischen verfügbar, tut genau das — er begrenzt ausgehende Netzwerkanfragen, um die letzte Stufe der Exfiltration zu verhindern. Die eigene Dokumentation ist erfrischend ehrlich: Injections verhindert er nicht, nur deren Auszahlung.

Der Haken ist, dass „ausgehend beschränken” schwerer ist, als es klingt, und die öffentliche Aktenlage ist ein Museum gescheiterter Allow-Lists:

Lies die Zeile zu Claude Cowork zweimal. Der Exfiltrationskanal war die eigene API des Anbieters, aus naheliegenden Gründen auf der Allow-List, benutzt mit einem vom Angreifer gelieferten Schlüssel. Jede Domain, die einen Schreibvorgang annimmt und ihn später von jemand anderem lesen lässt, ist ein Exfiltrationsvektor — und diese Kategorie ist weit größer, als ein Bedrohungsmodell üblicherweise zugibt.

Das Gegenargument von 2026

Im August 2026 machte Anthropic den Auto-Modus in Claude Code zum Standard und veröffentlichte Zahlen, die man ernst nehmen sollte. Eine Drittprüfung von Trajectory Labs führte 72 zurückgehaltene Szenarien indirekter Prompt Injection aus; keiner von 720 Angriffsversuchen war gegen ihre Modelle im Auto-Modus erfolgreich. In derselben Arbeit wurde bei 1.053 bezahlten Testern eine Freigabeabfrage gegen einen klar gefährlichen Befehl getauscht: Nur 13,6 % der Menschen verweigerten ihn, während der Auto-Modus 89 % blockiert hätte.

Beide Hälften verdienen Ehrlichkeit. Die zweite ist die unangenehmere — sie ist starkes Indiz dafür, dass Klick-zum-Bestätigen keine echte Kontrolle ist. Bestätigungsmüdigkeit ist kein Charakterfehler, sondern das absehbare Ergebnis davon, einen Menschen im Sekundentakt urteilen zu lassen.

Aber 720 zurückgehaltene Szenarien sind eine Messung gegen bekannte Angriffsformen, kein Beweis, dass die Klasse geschlossen ist. Willison — der öffentlich einen schweren Sicherheitsvorfall bei Coding-Agenten für 2026 vorhergesagt hat — bat um unabhängige Bestätigung und nannte einen Angriff, den der Auto-Modus aus seiner Sicht nicht adressiert: ein bösartiges Paket, dessen Dokumentation den Agenten anweist, während eines harmlos wirkenden Test-Setups etwas anderes zu holen und auszuführen.

Die vernünftige Position: Diese Maßnahmen erhöhen die Angriffskosten erheblich und ändern nichts an der Architektur, die du bauen solltest. Eine geringere Wahrscheinlichkeit einer erfolgreichen Injection ist es wert. Sie ist kein Grund, einem Agenten deine Produktions-Zugangsdaten zu geben.

Was du konkret tust

Kappe das ausgehende Bein, wo es geht. Deterministisch, im Code durchgesetzt, nicht von einem Modell beurteilt. Standardmäßig verweigern und die Allow-List auf offene Redirects, abgelaufene Registrierungen und alles prüfen, was Daten speichert, die andere lesen können.

Schneide Zugangsdaten so zu, dass Diebstahl langweilig ist. Die wirksamste einzelne Kontrolle für Coding-Agenten: Jeder Schlüssel, den ein Agent sehen kann, gehört zu einem Nicht-Produktionskonto mit hartem Ausgabenlimit. Wenn er leakt, rotierst du ihn und machst weiter.

Gib Werkzeuge frei, nicht Server. Eine Integration kann alle drei Beine tragen. Erteile einzelne Fähigkeiten und wiederhole den Trifecta-Test bei jeder neuen — das Risiko liegt in der Kombination, nicht in der einzelnen Ergänzung.

Verlange menschliche Freigabe bei Seiteneffekten, nicht bei allem. Die 13,6 % sind das Ergebnis ständiger Bestätigungsabfragen. Reserviere die Unterbrechung für Aktionen, die das System verlassen: senden, posten, schreiben, veröffentlichen.

Behandle nicht vertrauenswürdige Inhalte als Daten. Externe Inhalte abtrennen und markieren statt sie in den Anweisungsstrom zu hängen, wie es die OWASP-LLM01-Leitlinie vorsieht. Das löst das Problem nicht — auf der Prompt-Ebene löst es nichts — aber es macht die Grenze für die Menschen sichtbar, die den Code lesen.

Teste adversarial. OWASP empfiehlt, das Modell als nicht vertrauenswürdigen Nutzer zu behandeln und die Vertrauensgrenze zu pentesten. Nimm an, die Injection landet; überprüfe den Schadensradius.

Das Fazit

Prompt Injection ist als benanntes Problem inzwischen vier Jahre alt. Sie ist LLM01 in den OWASP Top 10 für LLM-Anwendungen, in MITRE ATLAS katalogisiert — und geht weiterhin in Flaggschiffprodukten von Microsoft, Google, Atlassian, Salesforce, Notion und Anthropic in Produktion, also bei Unternehmen mit ernstzunehmenden Sicherheitsorganisationen. Diese Bilanz sollte jede Erwartung beenden, dass ausgerechnet dein Klassifikator hält.

Die Lethal Trifecta ist gerade deshalb wertvoll, weil sie diese Frage nicht mehr stellt. Sie versucht nicht, das Modell vertrauenswürdig zu machen. Sie fragt, was das Modell tun darf, wenn es unweigerlich getäuscht wird — und gibt dir drei konkrete Dinge, die du in einer Architektur prüfen kannst, die du schon hast.

Wende den Test auf den Agenten an, den du letztes Quartal ausgeliefert hast. Private Daten, nicht vertrauenswürdige Inhalte, externe Kommunikation. Wenn du dreimal ja sagst, hast du kein hypothetisches Risiko — du hast eine funktionierende Angriffskette, die darauf wartet, dass sich jemand genug dafür interessiert.