KI-Agenten & Sicherheit

Prompt Injection bei KI-Agenten: Warum Filter nicht reichen und was wirklich schützt

Von Wladimir Neuberger · Aktualisiert

Die kurze Antwort

Prompt Injection bedeutet, dass Eingaben oder fremde Inhalte das Verhalten eines Sprachmodells unbeabsichtigt ändern. Filter allein genügen nicht, weil Modelle Daten und Anweisungen nicht zuverlässig trennen. Wirksam ist, die Folgen zu begrenzen: wenige Rechte, getrennte Inhalte, menschliche Freigabe bei riskanten Aktionen, Prüfung der Ausgaben und regelmäßige Angriffstests.

Was Prompt Injection ist

Prompt Injection steht in der OWASP-Liste der zehn größten Risiken für Anwendungen mit Sprachmodellen (Ausgabe 2025) an erster Stelle (LLM01:2025). Gemeint ist: Eingaben verändern das Verhalten eines Modells auf eine Weise, die niemand vorgesehen hat. Die Eingaben müssen für Menschen nicht lesbar sein, es genügt, dass das Modell sie verarbeitet. Je nach Anwendung kann das zur Preisgabe sensibler Informationen führen, zu verfälschten Ergebnissen, zum unbefugten Zugriff auf Funktionen oder zur Ausführung von Befehlen in angebundenen Systemen.

Wie schwer der Schaden wiegt, hängt nach OWASP vom Geschäftsumfeld ab und davon, wie viel Eigenständigkeit das Modell hat. Bei einem reinen Chatbot bleibt es meist bei einer falschen oder unpassenden Antwort. Bei einem Agenten, der Werkzeuge aufruft, reicht die Wirkung so weit wie dessen Rechte.

Direkt und indirekt

OWASP unterscheidet zwei Wege, auf denen ein Modell umgelenkt wird. Beide können absichtlich oder versehentlich entstehen.

  • Direkte Injection: Die Eingabe der Nutzerin oder des Nutzers verändert das Verhalten des Modells unerwartet.
  • Indirekte Injection: Das Modell liest externe Inhalte wie Webseiten oder Dateien, und darin stehen Anweisungen, die sein Verhalten verändern.

Für Agenten ist die indirekte Variante die unbequemere. Ein Agent soll ja gerade fremde Inhalte lesen: E-Mails zusammenfassen, Webseiten auswerten, Dokumente durchsuchen. Stellen Sie sich vor, ein Agent fasst eingehende E-Mails zusammen und darf zusätzlich Nachrichten versenden. Enthält eine Mail versteckte Anweisungen, könnte der Agent sie für einen echten Auftrag halten. Das Beispiel ist hypothetisch, es folgt aber dem Szenario, das OWASP bei „Excessive Agency“ beschreibt.

Warum Filter allein nicht reichen

Das britische National Cyber Security Centre (NCSC) erklärt den Kern in einem Blogbeitrag vom 8. Dezember 2025: Bei SQL Injection lässt sich das Problem mit parametrisierten Abfragen vollständig beheben, weil Daten und Anweisungen auf Ebene der Datenbank getrennt bleiben. Sprachmodelle machen diese Unterscheidung nicht. Das NCSC nennt sie deshalb „inherently confusable“, grundsätzlich verwechselbar. Das Risiko lasse sich senken, aber vermutlich nicht vollständig beseitigen. OWASP formuliert vorsichtig, es sei unklar, ob es überhaupt eine narrensichere Methode gebe, und die genannten Maßnahmen sollten die Wirkung verringern. Auch Retrieval-Verfahren und Feintuning mindern das Problem laut OWASP nicht vollständig.

Das NCSC rät außerdem davon ab, sich auf Sperrlisten bekannter Formulierungen zu verlassen, weil Angreifer endlos umformulieren können, und empfiehlt Skepsis gegenüber Produkten, die versprechen, Prompt Injection zu „stoppen“. Simon Willison, der den Begriff geprägt hat, schreibt, dass Anbieter von Schutzprodukten oft hohe Erkennungsraten versprechen; im Webbereich sei eine Quote unterhalb von 100 Prozent kein befriedigendes Ergebnis, und man wisse bislang nicht, wie sich diese Angriffe zuverlässig verhindern lassen. Eine Auswertung zu zwölf veröffentlichten Schutzverfahren („The Attacker Moves Second“, Oktober 2025) kommt laut Willisons Zusammenfassung zu dem Ergebnis, dass die Autoren die meisten davon mit angepassten Angriffen umgehen konnten, obwohl sie ursprünglich sehr gute Werte gemeldet hatten.

Filter sind eine nützliche Schicht, aber keine Garantie. Planen Sie so, als würde eine Injection irgendwann gelingen, und begrenzen Sie, was dann passieren kann.

Was wirkt: die Folgen begrenzen

Die folgenden Punkte stammen aus den Empfehlungen von OWASP (LLM01:2025) und NCSC. Die Reihenfolge und die Auswahl für kleine Projekte sind unsere Einordnung.

  • Inhalt und Anweisung trennen: Externe Inhalte klar kennzeichnen und von Nutzeranweisungen abgrenzen, damit sie weniger Einfluss haben. Das NCSC nennt als Technik das Markieren oder Einpacken fremder Inhalte und betont zugleich, dass dies nur erschwert und nicht verhindert.
  • Rechte begrenzen: Die Anwendung bekommt eigene Zugangsdaten mit minimalen Rechten; privilegierte Funktionen laufen im Anwendungscode statt im Modell. Nach der Regel des NCSC sinken die Rechte eines Modells auf das Niveau dessen, dessen Eingabe es verarbeitet: Ein Modell, das fremde E-Mails liest, sollte keinen Zugriff auf privilegierte Werkzeuge haben.
  • Freigaben einbauen: Bei riskanten oder privilegierten Aktionen entscheidet ein Mensch, bevor sie ausgeführt werden.
  • Ausgaben prüfen: Das Modell soll ein festes Ausgabeformat liefern, und deterministischer Code prüft, ob die Ausgabe dazu passt, bevor etwas Weiteres geschieht.
  • Überwachen: Das NCSC empfiehlt, genug zu protokollieren, um Auffälliges zu erkennen, etwa Ein- und Ausgaben, Werkzeugaufrufe und fehlgeschlagene Aufrufe, die auf Abtasten durch einen Angreifer hindeuten können.
  • Regelmäßig testen: OWASP empfiehlt Penetrationstests und Angriffssimulationen, bei denen das Modell wie ein nicht vertrauenswürdiger Nutzer behandelt wird, um Vertrauensgrenzen und Zugriffskontrollen zu prüfen.

Die gefährliche Kombination vermeiden

Simon Willison beschreibt drei Eigenschaften, die zusammen besonders gefährlich sind, die „lethal trifecta“. Meta hat daraus im Oktober 2025 die „Agents Rule of Two“ abgeleitet, die zusätzlich Änderungen von Zuständen berücksichtigt. Danach sollte ein Agent in einer Sitzung höchstens zwei dieser drei Eigenschaften erfüllen:

  • Er verarbeitet nicht vertrauenswürdige Eingaben, etwa Webseiten oder E-Mails von Fremden.
  • Er hat Zugriff auf sensible Systeme oder private Daten.
  • Er kann Zustände ändern oder nach außen kommunizieren, etwa Nachrichten senden oder Daten schreiben.

Braucht eine Aufgabe alle drei, sollte der Agent laut Meta nicht autonom arbeiten, sondern beaufsichtigt werden, zum Beispiel durch menschliche Freigabe. Willison hält die Regel für den derzeit besten praktischen Anhaltspunkt, merkt aber an, dass auch die Kombination aus fremden Eingaben und Zustandsänderung allein Schaden anrichten kann.

Tests und Red-Teaming

Die Untersuchung „The Attacker Moves Second“ empfiehlt laut Willisons Zusammenfassung angepasste, iterative Angriffe statt einzelner statischer Testsätze, weil diese Schutzverfahren zu gut aussehen lassen. Für Ihre Praxis heißt das, ohne dass wir es als Quellenaussage ausgeben: Ein einmaliger Test mit einer Handvoll Beispielsätzen sagt wenig.

  • Testen Sie Ihren Agenten vor dem Livegang mit absichtlich präparierten Dokumenten und E-Mails in einer Testumgebung.
  • Prüfen Sie nicht nur, ob das Modell widersteht, sondern was passieren würde, wenn es nachgibt: Welche Werkzeuge, Daten und Empfänger wären erreichbar?
  • Wiederholen Sie Tests nach jeder Änderung an Modell, Werkzeugen oder Rechten.

Unsere Empfehlung: Beginnen Sie mit dem, was Sie sofort kontrollieren, nämlich den Rechten und Freigaben (siehe den Ratgeber zu Rechten und Freigaben für KI-Agenten), und ergänzen Sie Filter und Tests als weitere Schichten. Wenn ein Einsatz das verbleibende Restrisiko nicht verträgt, ist nach Einschätzung des NCSC ein Sprachmodell dafür möglicherweise nicht geeignet.

Häufige Fragen

Was ist der Unterschied zwischen direkter und indirekter Prompt Injection?

Bei der direkten Variante verändert die Eingabe des Nutzers das Verhalten des Modells. Bei der indirekten liest das Modell externe Inhalte wie Webseiten oder Dateien, die Anweisungen enthalten. Beides kann absichtlich oder versehentlich geschehen.

Kann man Prompt Injection vollständig verhindern?

Nach heutigem Stand nicht verlässlich. OWASP hält es für unklar, ob es eine narrensichere Methode gibt, das NCSC erwartet, dass sich das Risiko nur senken lässt. Deshalb zählt, die Folgen eines erfolgreichen Angriffs zu begrenzen.

Warum schützt eine Anweisung wie „Ignoriere fremde Befehle“ nicht?

Weil das Modell Anweisung und Inhalt nicht zuverlässig trennt. OWASP nennt das Einschränken des Verhaltens im Systemprompt nur als eine von mehreren Maßnahmen. Technische Grenzen wie begrenzte Rechte und Freigaben sind verlässlicher.

Was ist die „Agents Rule of Two“?

Eine Faustregel von Meta (Oktober 2025): Ein Agent soll in einer Sitzung höchstens zwei von drei Eigenschaften haben, nämlich fremde Eingaben verarbeiten, auf sensible Systeme zugreifen und Zustände ändern oder nach außen kommunizieren.

Quellen

Die Einordnung beruht auf den genannten Veröffentlichungen. Prüfen Sie bei Entscheidungen die Originalquelle.

Weiterlesen

Sie möchten wissen, wo Sie stehen?

Ein Basic Scan zeigt, wo Ihre Systeme von außen angreifbar sind — mit Festpreis und Bericht. Oder Sie lassen sich kostenlos vor neuen Lücken warnen.

Sicherheitspakete ansehen Warnungen abonnieren Kontakt aufnehmen