Prompt Injection: was eigene KI-Anwendungen angreifbar macht

Prompt Injection ist der Angriff, gegen den kein Update hilft. Ein Sprachmodell lässt sich mit gewöhnlichem Text dazu bringen, seine Vorgaben zu übergehen. Für Unternehmen mit eigenem KI-Assistenten wird daraus eine unbequeme Frage. Trägt am Ende der Dienstleister das Risiko, wenn ein Prompt-Injection-Angriff gelingt, oder das Unternehmen selbst?
Ein Mann schüttet helle Flocken auf ein Küchensieb mit gelbgrünem Rand, das eine Frau mithält, während das Material vollständig hindurchfällt. Sinnbild dafür, dass Filter eine Prompt Injection nur verlangsamen und nicht aufhalten.
© KI-generiert (TenMedia)

Warum Prompt Injection keine normale Lücke ist

41 Prozent der Unternehmen ab 20 Beschäftigten nutzen inzwischen Künstliche Intelligenz, im Vorjahr waren es 17 Prozent. Mit jeder dieser Anwendungen entsteht eine Angriffsfläche, die es vorher nicht gab, weil sich Anweisungen als gewöhnlicher Text einschmuggeln lassen.

Prompt Injection bezeichnet einen Angriff auf Anwendungen mit Sprachmodellen, bei dem eine bösartige Eingabe das Modell dazu bringt, seine ursprünglichen Vorgaben zu übergehen und stattdessen der eingeschmuggelten Anweisung zu folgen. Ursache ist die Bauweise, denn Systemvorgabe und Nutzerdaten erreichen das Modell als einen einzigen Textstrom, den es nicht nach Herkunft trennen kann.

Systemvorgabe und Eingabe sind derselbe Text

Die Vorgabe des Betreibers, ein Chatfenster solle nur Fragen zum Produktkatalog beantworten, steht im selben Feld wie der Text eines Nutzers. Für das Modell ist beides Sprache, und Sprache trägt kein Merkmal für ihre Herkunft. Ein Sprachmodell kann Anweisung und Inhalt grundsätzlich nicht auseinanderhalten. Daraus folgt, dass sich Schutz nicht zusichern, sondern nur an Testfällen der Abnahme belegen lässt.

Was ist Prompt Injection, wenn kein Fehler vorliegt?

Klassische Sicherheitslücken entstehen aus einem Programmierfehler und verschwinden mit dem Patch. Hier liegt kein Fehler vor, denn die Anwendung tut genau das, wofür sie gebaut wurde, nämlich Text lesen und darauf reagieren. Angegriffen wird also die vorgesehene Funktion. Wie ein Prompt-Injection-Angriff funktioniert, hängt daher nicht an einer Version, sondern an den Rechten der Anwendung.

Indirect Prompt Injection als stillere Variante

Das BSI führt den gefährlicheren Fall unter Indirect Prompt Injection und nennt ihn eine intrinsische Schwachstelle anwendungsintegrierter KI-Sprachmodelle. Gemeint ist der Angriff über einen Umweg. Nicht die Person am Chatfenster tippt die Anweisung ein, sondern sie steht in einem Dokument, einer Webseite oder einer E-Mail, die das Modell im Auftrag liest. Betreiber einer KI-Anwendung im Unternehmen behandeln deshalb jede fremde Textquelle als Eingabekanal.

Direkte Prompt Injection im Vergleich

Bei der direkten Prompt Injection kommt die Anweisung von der Person am Chatfenster. Sie schreibt dem Modell, es solle seine Vorgaben vergessen, und probiert Formulierungen aus, bis eine wirkt. OWASP führt solche Beispiele für Prompt Injection als eigene Angriffsart. Für Unternehmen ist die direkte Form leichter zu beherrschen, weil der Kreis der Angreifer auf die eigenen Nutzer begrenzt bleibt.

Welche eigenen Anwendungen betroffen sind

Die Frage ist nicht, wie viel Künstliche Intelligenz ein Unternehmen einsetzt, sondern an welche Texte es sie heranlässt. Nach Zahlen des Bitkom stellen 26 Prozent der Unternehmen Zugang zu generativer KI bereit, während nur 23 Prozent Regeln für den Einsatz aufgestellt haben. Zwischen diesen beiden Zahlen liegt das eigentliche Risiko. Eine KI-Integration für Unternehmen verschiebt die Aufgabe von der Technik in die Organisation.

Indirect Prompt Injection im Postfach

Das BSI nennt drei Wege, auf denen fremder Text in ein Sprachmodell gelangt, nämlich die Auswertung von Internetseiten und Dokumenten, den Zugriff auf Programmierumgebungen und den Zugriff auf E-Mail-Postfächer. Alle drei sind in Unternehmen längst im Einsatz, meist als Komfortfunktion, selten als Projekt. Ein Assistent, der Nachrichten zusammenfasst, liest jede Nachricht, auch die mit einer versteckten Anweisung darin.

Typische Stellen, an denen fremder Text ungeprüft in ein Modell läuft:

Ist ein Chatbot mit eigenen Dokumenten sicher?

Nein, und das ist die häufigste Fehlannahme. Ein Chatbot, der nur freigegebene Unterlagen aus der eigenen Ablage auswertet, gilt intern schnell als geschlossenes System. Die Ablage ist aber nicht geschlossen, denn dort liegen Angebote, Bewerbungen und gescannte Schreiben von außen. Ein RAG-System holt sie als Kontext heran, samt einer darin versteckten Indirect Prompt Injection. Nicht die Freigabe entscheidet, sondern die Herkunft. Prompt Injection im Chatbot verhindern heißt daher, jede Quelle einzeln zu bewerten.

Prompt Injection bei KI-Agenten

Ein Assistent, der nur Auskunft gibt, kann höchstens falsch antworten, ein Agent mit Handlungsrechten dagegen etwas auslösen. Ein manipuliertes Modell mit Zugriff auf Postfach und Bestellsystem verschickt Daten oder startet Vorgänge. Der Schaden wächst mit den Rechten, nicht mit der Modellgröße. Wie viel Autonomie KI-Agenten erhalten, ist deshalb die wichtigste Sicherheitsentscheidung des Projekts.

Prompt-Injection-Angriffe gestaffelt abwehren

Eine Maßnahme, die das Problem löst, gibt es nicht, deshalb arbeiten Schutzkonzepte in Stufen. Die erste begrenzt, was das Modell überhaupt darf, die zweite prüft Ein- und Ausgaben durch vorgeschaltete LLM Guardrails, die dritte holt einen Menschen dazu, bevor etwas Folgenreiches passiert. Allein die erste Stufe wirkt unabhängig davon, ob ein Angriff erkannt wird. Ein Prompt-Injection-Angriff scheitert dort an fehlenden Rechten und nicht am Filter.

Fünf Festlegungen tragen den Schutz im Betrieb:

❗ Rechte des Modells auf das Nötige begrenzen
❗ Fremden Text als unsicher behandeln, auch aus eigener Ablage
❗ Folgenreiche Aktionen nur nach menschlicher Freigabe
❗ Ein- und Ausgaben samt Kontext protokollieren
❗ Grenzen vor dem Livegang mit Angriffsversuchen prüfen

Reicht ein Eingabefilter als Schutz?

Nicht auf Dauer. In der Ausgabe 2025 der OWASP LLM Top 10 steht der Angriff unter LLM01 und damit an erster Stelle aller Risiken für Anwendungen mit Sprachmodellen, wie schon in der Ausgabe 2023/24. Im Leitfaden zur Abwehr unterscheidet die Organisation primäre und ergänzende Gegenmaßnahmen und dazu eine abgesicherte Umsetzungskette. Sie hält zugleich fest, dass Angreifer mit genügend Rechenleistung die meisten heutigen Schutzmaßnahmen am Ende umgehen. Filter verlangsamen einen Angriff, sie beenden ihn nicht.

Prompt Injection erkennen und protokollieren

Ein gelungener Angriff sieht im Protokoll aus wie eine normale Anfrage, solange nur die Anfrage protokolliert wird. Aussagekräftig wird die Aufzeichnung erst mit dem Kontext, den das Modell zusätzlich gelesen hat, also den abgerufenen Dokumenten und den aufgerufenen Werkzeugen. Bei einer Indirect Prompt Injection steht die Anweisung genau dort. LLM Guardrails liefern zusätzliche Signale, ersetzen die Aufzeichnung aber nicht. Damit rückt die Aufgabe in den Sicherheitsbetrieb, denn dieselben Fragen stellt Cybersecurity an jedes andere System auch.

Prompt Injection in Auftrag, Abnahme, Betrieb

Die technische Seite ist damit beschrieben, die vertragliche nicht. Bei einer beauftragten KI-Funktion entscheidet das Lastenheft darüber, ob Schutz von Anfang an eingebaut wird oder später nachträglich bezahlt werden muss. Als Prüfliste taugen die OWASP LLM Top 10, weil sie die Angriffsarten benennen, gegen die eine Abnahme testen muss.

Was zu einer KI-Funktion im Lastenheft festgelegt wird:

Woran die Abnahme das prüft

Übliche Abnahmekriterien greifen hier nicht, weil sie fragen, ob eine Funktion tut, was sie soll. Umgekehrt lautet die Frage, ob die Anwendung auch dann nichts Unerlaubtes tut, wenn jemand sie dazu auffordert. Belegen lässt sich das nur mit vorher festgelegten Prompt-Injection-Angriffen und einem protokollierten Ergebnis. Zugesichert werden kann Schutz nicht, belegt schon. Dieselbe Logik gilt für Abnahmekriterien für KI-gestützte Projekte, denn ein Modell liefert bei gleicher Eingabe nicht zwingend dieselbe Ausgabe.

Restrisiko, Verantwortung, laufender Betrieb

Ein Restrisiko bleibt, und das ist keine Nachlässigkeit, sondern eine Eigenschaft der Technik. Das Restrisiko wird verteilt, nicht beseitigt, über Rechte, Freigaben, Protokolle und die Festlegung, wer im Vertrag für welchen Fall einsteht. Getrennte Rechte lassen sich schon in der Benutzerführung verankern, wie eine Oberfläche für individuell trainierte Sprachmodelle zeigt, in der Zugriff und Bedienung von Anfang an auseinandergehalten wurden. Die eigene KI-Anwendung vor Prompt Injection zu schützen bleibt eine Betriebsaufgabe, keine einmalige Prüfung.

FAQs

Wer haftet, wenn eine manipulierte KI-Anwendung Schaden anrichtet? keyboard_arrow_down keyboard_arrow_up
Die Zuordnung folgt Vertrag und Rolle. Betreibt ein Unternehmen die Anwendung selbst, steht es gegenüber Kunden und Aufsicht dafür ein. Der Dienstleister ist an zugesagte Eigenschaften gebunden, etwa begrenzte Rechte und Protokollierung. Ohne Festlegung im Vertrag bleibt die Frage nach einem Prompt-Injection-Angriff offen.
Ist ein lokal betriebenes Sprachmodell weniger angreifbar? keyboard_arrow_down keyboard_arrow_up
Nein. Der Betriebsort ändert nichts an der Ursache, denn auch ein lokal betriebenes Modell verarbeitet Vorgaben und Nutzerdaten als einen Textstrom. Ein eigener Betrieb begrenzt den Datenabfluss nach außen und erleichtert die Protokollierung. Die Manipulation selbst bleibt in beiden Betriebsmodellen möglich.
Lässt sich eine bereits laufende KI-Funktion nachträglich absichern? keyboard_arrow_down keyboard_arrow_up
In den meisten Fällen ja, und der Aufwand hängt weniger am Modell als an der Anbindung. TenMedia entwickelt und betreut Individualsoftware mit Sprachmodell-Anbindung und setzt dabei an drei Stellen an, nämlich an den Rechten der Anwendung gegenüber Fachsystemen, an der Trennung zwischen Systemvorgabe und fremdem Text, und an der Protokollierung, die einen Vorfall später rekonstruierbar macht. Aufwendig wird es, wenn eine Anwendung ohne Rechtekonzept gewachsen ist, weil dann jede Schnittstelle einzeln bewertet werden muss. Ein Testlauf mit gezielten Angriffsversuchen zeigt vorab, wie weit eine Anwendung gegen Prompt Injection trägt.