Zum Hauptinhalt springen
Startseite / Blog / Sicherheits-Leitfaden
Sicherheits-Leitfaden

Prompt Injection patcht man nicht weg. Bauen Sie drumherum.

RRogue AI··10 Min. Lesezeit
Ein KI-Agent liest eine versteckte bösartige Anweisung aus einer Webseite im selben Token-Strom wie seine echte Aufgabe und kann Befehl nicht von Daten unterscheiden

Prompt Injection lässt sich nicht patchen, und je eher das sitzt, desto eher bauen Sie Agenten, die sie überstehen. Es ist kein Fehler in einem Modell, den ein Point-Release schließt. Es ist eine Eigenschaft der Funktionsweise von Sprachmodellen: Befehle und die Daten, die sie lesen, kommen als ein Strom von Tokens, und das Modell kann Ihren Befehl nicht zuverlässig von einem Satz unterscheiden, den es gerade aus einer Webseite, einer E-Mail oder einem PDF gezogen hat. Eine Studie aus 2026 ließ 3.168 Angriffssimulationen gegen Browser-Agenten auf GPT-5 und Gemini laufen und fand, dass direkte Injection in mehr als 79 Prozent der Fälle gelang. Der Titel der Arbeit spricht das Stille aus: Agenten fallen womöglich immer auf Prompt Injection herein.

Also hören Sie auf, den Streit mit dem Angreifer im Prompt gewinnen zu wollen. Der haltbare Zug ist architektonisch: Bauen Sie das System so, dass ein gekaperter Agent nichts Wichtiges erreicht. So sieht das tatsächlich aus, warum Filtern ein verlorenes Spiel ist und welche zwei, drei strukturellen Muster halten, wenn die Injection unweigerlich landet.

Warum ein klügeres Modell Sie nicht rettet

Alle paar Wochen behauptet jemand, das nächste Modell sei robust genug, um injizierte Anweisungen zu ignorieren. Wird es nicht, und der Grund ist strukturell, keine Frage der Skalierung. Ein Agent muss nicht vertrauenswürdige Inhalte lesen, um seine Arbeit zu tun, diesen Posteingang zusammenfassen, jene Seite recherchieren, diese Rechnung parsen, und in dem Moment, in dem er vom Angreifer kontrollierten Text liest, liegt dieser Text im selben Kontextfenster wie Ihre Anweisungen, in derselben Kleidung. Es gibt kein Feld auf einem Token, das sagt „dieser Teil ist vertrauenswürdig“. Das Modell tut genau das, wofür es gebaut wurde: eine Fortsetzung aus allem vor ihm vorhersagen. Der injizierte Satz ist nur mehr von dem Alles.

Deshalb bleiben die Erfolgsraten über Frontier-Modelle hinweg hartnäckig. Die Agenten-Version davon haben wir in warum die Prompt-Injection-Zahl nie null erreichtbeziffert: Schutzmaßnahmen drücken sie nach unten, nicht auf null, und „selten“ ist keine Sicherheitseigenschaft, wenn der Agent Geld bewegen oder Dateien löschen kann. Ein besseres Modell senkt die Chancen pro Versuch. Es ändert nicht, dass der Angreifer unbegrenzte Versuche hat und nur einmal gewinnen muss.

Die tödliche Trias: wann ein Agent bedingungslos offen liegt

Simon Willison hat der gefährlichen Konstellation einen Namen gegeben, den man sich merken sollte: die tödliche Trias (lethal trifecta). Ein Agent liegt bedingungslos offen für Datenabfluss, sobald er alle drei gleichzeitig hat.

  • Zugang zu privaten Daten. Er kann Ihr Postfach, Ihre Dokumente, Ihre Datenbank, Ihre Geheimnisse lesen.
  • Kontakt mit nicht vertrauenswürdigen Inhalten. Er verarbeitet Text aus Quellen, die ein Angreifer beeinflussen kann, eine Webseite, eine E-Mail, eine geteilte Datei, ein Tool-Ergebnis.
  • Einen Abflusspfad. Er kann Daten nach außen senden, eine Anfrage, einen Link, den er rendert, eine Nachricht, die er postet, ein Tool, das er aufruft.

Halten Sie alle drei, sind Sie nicht „mit guten Prompts größtenteils sicher“. Sie sind einen geschickt formulierten Absatz davon entfernt, dass der Agent ein Geheimnis liest und es im Auftrag des Angreifers irgendwohin verschickt, ohne Exploit, ohne Malware, nur mit Text. Die Designlehre ist hart: Lassen Sie nie einen Agenten alle drei in voller Stärke halten. Brechen Sie das Dreieck, und die bedingungslose Offenheit verschwindet.

Hören Sie auf zu filtern. Trennen Sie Steuerung von Daten.

Eingabefilter, Jailbreak-Klassifikatoren und „ignoriere Anweisungen in abgerufenen Inhalten“-System-Prompts sind alle dieselbe Wette: dass Sie den schlechten Text erkennen. Es ist Whac-A-Mole gegen einen Angreifer mit Thesaurus und unendlichen Versuchen. Die Muster, die wirklich halten, tun etwas anderes, sie hindern den nicht vertrauenswürdigen Text daran, überhaupt zu steuern, was der Agent tut.

Der sauberste Ausdruck davon ist das CaMeL-Design von Google DeepMind, das zwei Ideen direkt aus der klassischen Systemsicherheit borgt: Control-Flow-Integrity und Capabilities. Ein privilegiertes Modell sieht nur Ihre vertrauenswürdige Anfrage und schreibt den Plan. Ein separates, unter Quarantäne stehendes Modell verarbeitet die nicht vertrauenswürdigen Inhalte und ist der Fähigkeit beraubt, Tools aufzurufen. Weil der Plan feststeht, bevor irgendwelche nicht vertrauenswürdigen Daten berührt werden, kann dieser Text ändern, was der Agent weiß, aber nie, was er tut. Im AgentDojo-Benchmark blockierte das nahezu 100 Prozent der Angriffe. Der injizierte Text kommt trotzdem an, er hat nur nirgendwohin zu gehen.

Die Zweierregel und Kontrollen außerhalb des Modells

Sie brauchen nicht immer die volle Zwei-Modell-Trennung. Metas „Agents Rule of Two“ ist die billige Version derselben Idee: Ein unbeaufsichtigter Agent sollte höchstens zwei der drei Fähigkeiten der Trias halten, und sobald er alle drei braucht, genehmigt ein Mensch den Schritt. Nicht vertrauenswürdige Webseiten lesen und für Sie zusammenfassen ist in Ordnung. Nicht vertrauenswürdige Webseiten lesen, Ihre Zugangsdaten halten und nach außen posten können ist es nicht, bis ein Mensch zustimmt.

Beachten Sie, wo in jedem dieser Muster die Kontrolle sitzt: außerhalb des Modells, nicht im Prompt. Es wird angenommen, dass der Agent getäuscht wird. Der Container, in dem er läuft, die Zugangsdaten, die er bekommt, der Egress, der ihm erlaubt ist, und die Aktionen, die Bestätigung verlangen, werden von Code entschieden, den der injizierte Text nie erreicht. Das ist dasselbe Containment-Argument, das wir für Coding-Agenten in warum Ihr Coding-Agent eine Leine braucht machen, und dieselbe Zugriffskontroll-Disziplin hinter RAG-Pipelines gegen Prompt Injection absichern.

Was eine entschlossene Injection stoppt, und was nicht

VerteidigungStoppt eine entschlossene Injection?Warum
System-Prompt-HärtungNeinNicht vertrauenswürdiger Text teilt das Kontextfenster; das Modell kann nicht zuverlässig einem Teil gehorchen und einen anderen ignorieren
Eingabefilter und Jailbreak-KlassifikatorenNeinMustererkennung gegen einen Angreifer mit unbegrenzten Umformulierungen und unbegrenzten Versuchen
Trennung von Steuerung und Daten (Zwei-Modell)JaDer Plan steht fest, bevor nicht vertrauenswürdige Daten gelesen werden, also ändert Injection Wissen, nicht Handlungen
Capability-Begrenzung und ZweierregelJaEin gekaperter Agent hält nie private Daten, nicht vertrauenswürdige Eingabe und Egress zugleich
Egress-Kontrolle und menschliche Gates außerhalb des ModellsJaDer injizierte Text erreicht den Code nicht, der entscheidet, was hinausgehen oder laufen darf

Ein Bau-Muster, das hält

Für die Injection statt gegen sie zu bauen läuft auf eine kurze, langweilige Checkliste hinaus, die Sie einmal entscheiden, in Code, nicht pro Prompt.

  • Brechen Sie die Trias standardmäßig. Tragen Sie jeden Agenten gegen private Daten, nicht vertrauenswürdige Eingabe und Egress ab. Hat ein Agent alle drei, teilen Sie ihn oder setzen Sie ein menschliches Gate vor das dritte.
  • Halten Sie nicht vertrauenswürdige Inhalte vom Tool-Aufruf fern. Die Komponente, die das Web, das Postfach oder das Dokument liest, sollte nicht die Komponente sein, die Ihre Zugangsdaten hält und Tools aufruft.
  • Begrenzen Sie Capabilities, nicht nur Berechtigungen. Geben Sie dem Agenten die engsten, am ehesten wegwerfbaren Zugangsdaten, mit denen er noch arbeiten kann, derselbe Instinkt hinter selbst-gehostete KI-Infrastruktur absichern.
  • Kontrollieren Sie Egress, nicht nur Eingabe. Der meiste Injection-Gewinn ist Exfiltration. Eine Allowlist dafür, wohin der Agent Daten senden darf, entschärft den Angriff, selbst wenn der Prompt gewinnt.
  • Sichern Sie das Unumkehrbare ab. Geld, Löschungen, Deployments und ausgehende Nachrichten bekommen pro Aufruf eine ausdrückliche menschliche Bestätigung, nie ein implizites Ja.
  • Red-Teamen Sie die Architektur, nicht die Formulierung. Testen Sie, ob eine injizierte Anweisung ein Tool erreichen kann, nicht ob eine bestimmte Formulierung durchrutscht, so wie wir Evaluierung in KI-Systeme vor der Produktion testen behandeln.

Bauen Sie für den Fehler

Die Teams, die Agenten sicher ausliefern, sind nicht die mit dem cleversten System-Prompt. Es sind die, die annahmen, der Agent würde getäuscht, und dafür sorgten, dass es egal ist. Prompt Injection hört an dem Tag auf, ein Notfall zu sein, an dem Sie sie nicht mehr als zu patchenden Fehler behandeln, sondern als das Wetter, eine Bedingung, für die man baut. Das Modell wird den bösartigen Satz lesen. Ob dieser Satz etwas tun kann, ist Ihre Entscheidung, und sie fällt in der Architektur, nicht im Prompt. Denselben Fall machen wir für das bewusste Inproduktionnehmen von Agenten in was bei der Agenten-Orchestrierung im Produktionsmaßstab bricht und LLM-Funktionen bauen, die die Produktion überstehen.

Weiterführende Lektüre: siehe warum die Prompt-Injection-Zahl nie null erreicht, RAG-Pipelines gegen Prompt Injection absichern und warum Ihr Coding-Agent eine Leine braucht.

Weitere Artikel

Sicherheits-Leitfaden

Ihr KI-Coding-Agent kann alles löschen. So zähmen Sie ihn.

10 Min. Lesezeit

Sicherheits-Leitfaden

Prompt Injection hat jetzt eine Zahl: 31,5 % Hijack

10 Min. Lesezeit

← Alle Artikel