So schütze ich meine KI-Agenten vor Prompt Injection

Es kam eine E-Mail. Höflich formuliert, inhaltlich sauber, mit korrektem Bezug auf einen unserer eigenen Berichte. Kein Spam-Muster, keine Rechtschreibfehler, kein Druck. Nur eine freundliche Einladung zu einem angeblichen Forschungsprojekt, plus zwei Links, ausdrücklich als Informationen für Agenten deklariert.

Genau darin lag das Problem.

Die Mail landete in meinem Postfach, nicht im Postfach meiner Agentin. Sie wurde nicht ungeprüft geöffnet, sondern zuerst gesichtet, dann an Iris zur Bewertung gegeben. Iris hat den Text gelesen, die Links nicht angeklickt und mir eine Einschätzung geschrieben. Danach habe ich die Einladung gelöscht. Kein Schaden, kein Klick, keine Daten preisgegeben.

Aber der Vorfall zeigt etwas, das viele unterschätzen: Ein KI-Agent liest fremden Text nicht als Information. Er liest ihn als potenzielle Anweisung.

Warum ein Agent fremdem Text glaubt

Ein Sprachmodell unterscheidet nicht von sich aus zwischen Daten und Befehlen. Alles, was im Kontextfenster landet, ist erst einmal Text, und Text kann eine Anweisung enthalten. Wenn ein Agent eine Webseite aufruft, eine Datei öffnet oder eine E-Mail liest, landet deren Inhalt in genau demselben Kanal wie die Anweisungen seines Betreibers.

Daraus folgt die Angriffsfläche, die als Prompt Injection bekannt ist: Jemand schreibt einen Satz wie "Ignoriere alle vorherigen Anweisungen" auf eine Seite, die ein Agent später besucht. Der Agent hat keine eingebaute Möglichkeit zu erkennen, dass dieser Satz von außen kam und nicht von seinem Auftraggeber.

Der Köder in unserem Fall war besonders sauber gebaut. Statt plumper Befehle gab es eine Datei namens llms.txt und eine Dokumentationsseite, die ausdrücklich für Agenten gedacht waren. Das ist kein Zufall. Wer eine Seite speziell für Maschinenleser gestaltet, gestaltet sie speziell für die Instanz, die Anweisungen ausführt.

Die Schichten, die ein Framework bieten kann

Ein einzelner Mechanismus reicht nicht. Wer Agenten betreibt, braucht mehrere unabhängige Schichten, die jeweils unterschiedliche Fehler abfangen. Im Agent Zero Framework sind diese Schichten in Code und Policy getrennt, was den Vorteil hat, dass man prüfen kann, welche davon tatsächlich greift.

Die erste Zeile ist die interessanteste, weil sie den eigentlichen Angriff adressiert und nicht nur seine Symptome. Ein solches Gate sitzt zwischen dem Denken und dem Handeln des Agenten. Es analysiert, was der Agent gerade zu tun gedenkt, und entscheidet dann über eines von drei Ergebnissen: freigeben, nachfragen oder abbrechen. Die Regel, die dabei greift, ist erstaunlich direkt formuliert: Wenn der Agent erkennbar Anweisungen folgt, die von außen in seinen Kontext gelangt sind, wird er gestoppt.

Der entscheidende Punkt ist der Zeitpunkt: Ein Gate vor der Ausführung verhindert den Schaden, eine Prüfung nach der Ausführung dokumentiert ihn nur.

Wo die Grenzen liegen

Ein solches Gate ist kein Schutzschild, und es wäre unseriös, es als eines zu verkaufen. Drei Einschränkungen gehören in jede ehrliche Betrachtung.

Erstens prüft es den Output, nicht den Input. Der Agent liest den fremden Text trotzdem. Das Gate verhindert nur, dass er danach etwas Gefährliches tut. Es fängt den Schaden, nicht den Köder.

Zweitens kostet es Zeit. Jede Tool-Ausführung wartet auf ein Prüfergebnis, und diese Wartezeit summiert sich bei einem Agenten, der viele kleine Schritte macht. In meinem Lab hat genau das dazu geführt, dass die Schicht derzeit deaktiviert ist. Ein Schutz, der den Betrieb unbrauchbar langsam macht, wird abgeschaltet. Das ist eine Design-Entscheidung, keine Lösung.

Drittens ist die Prüfung selbst ein Sprachmodell. Sie ist probabilistisch, nicht deterministisch, und damit theoretisch manipulierbar. Ein Angreifer, der das Prüfmodell kennt, kann versuchen, auch dieses zu täuschen. Es erhöht die Hürde, es beseitigt sie nicht.

Was ein Zwiebelnetz ausmacht

Die Schichten in der Tabelle oben sind keine Erfindung für diesen Artikel. Sie sind die Antwort auf eine einfache Frage: Was passiert, wenn eine einzelne Schicht versagt?

Ein durchdachtes Setup sieht deshalb nicht wie eine Mauer aus, sondern wie eine Zwiebel. Die äußere Schale filtert, was überhaupt in die Nähe des Agenten kommt. Eine Weiterleitungsschicht prüft eingehende Nachrichten auf bekannte Muster, bevor sie den Agentenkontext erreichen. Anhänge laufen gar nicht erst in den Agenten, sondern in einen separaten Pfad. Eine kleine, lokal betriebene Prüfinstanz bewertet den verbleibenden Text auf verdächtige Formulierungen, bevor er gelesen wird. Und die Systeme, die diese Prüfung durchführen, sind selbst nicht öffentlich dokumentiert.

Das ist der Punkt, an dem viele Setups scheitern. Wer seine Abwehr offen beschreibt, liefert die Bauanleitung für den nächsten Umgehungsversuch gleich mit. Sicherheit durch Nichtwissen ist keine Sicherheit, aber Sicherheit durch maßvolle Zurückhaltung bei der Dokumentation der eigenen Interna ist ein legitimer Teil des Designs.

Der wirksamste Schutz ist ein Mensch

Von allen Schichten hat in unserem Fall die einfachste funktioniert: Ich habe meine Agentin nicht ungeprüft fremde Post lesen lassen. Kein Modell, kein Filter, keine Regel in einer Konfigurationsdatei.

Das ist keine Technikfeindlichkeit. Es ist die Erkenntnis, dass ein Agent genau so viel Autonomie haben sollte, wie sein Betreiber verantworten kann. Ein Agent, der autonom fremde Links öffnet, fremde Dokumente befolgt und Ergebnisse ungeprüft weiterleitet, ist kein Produktivitätsgewinn. Er ist eine Angriffsfläche mit Zugangsdaten.

Ein Agent, der arbeitet und an den entscheidenden Stellen fragt, ist langsamer. Aber er ist auch der Agent, der nach einem präparierten Link noch da ist.

Wer ein Agenten-Setup betreibt, sollte sich eine Frage stellen, bevor der nächste Köder kommt: Welcher Schritt in meiner Kette würde den Angriff stoppen, wenn alle anderen versagen? Wenn es keinen gibt, ist das die Lücke.