Zum Inhalt springen
Individuell trainiert
Sicherheit & Datenschutz

Prompt Injection: KI-Chat-Assistenten sicher absichern

Warum Prompt Injection auf Platz 1 der OWASP Top 10 für LLM-Anwendungen steht, was direkte und indirekte Angriffe unterscheidet und welche Leitplanken schützen.

12 Min. Lesezeit SicherheitPrompt InjectionOWASPKI-Assistent

Wenn ein KI-Chat-Assistent Fragen von Besuchern entgegennimmt, Inhalte aus der eigenen Website liest und angebundene Aktionen auslöst, verarbeitet er ständig fremden Text. Genau darin liegt das Einfallstor für Prompt Injection: den Versuch, dem Assistenten über geschickt formulierte Eingaben oder versteckte Textbausteine neue Anweisungen unterzuschieben. Die OWASP Foundation führt Prompt Injection in ihrer Top 10 für LLM-Anwendungen als LLM01 und damit auf Platz 1 (OWASP), und das zum zweiten Mal in Folge (OWASP). Der Grund ist strukturell: Ein Sprachmodell verarbeitet Daten und Anweisungen im selben Kanal, ohne klare Trennung zwischen dem, was es tun soll, und dem, was es nur lesen soll. Dieser Beitrag erklärt sachlich, was direkte und indirekte Angriffe unterscheidet, warum sich Prompt Injection nicht mit einem einzelnen Filter wegschalten lässt und welche Leitplanken einen Assistenten belastbar machen: Eingabefilter, Ausgabe-Prüfung, keine Geheimnisse im Prompt, klar begrenzte Rechte und ein wachsames Monitoring. Er grenzt das Thema bewusst vom Datenschutz ab, denn hier geht es nicht um die DSGVO, sondern um Angriffssicherheit. Eine absolute Sicherheit lässt sich dabei nicht zusichern, aber ein durchdachtes Konzept senkt das Risiko deutlich.

Prompt Injection sicher absichernZwei AngriffswegeDirekte InjectionAnweisung im EingabefeldIndirekte InjectionVersteckt in Website-InhaltenLeitplankenEingabefilterAusgabe-PrüfungKeine Secrets im PromptMonitoring & LoggingDefense in DepthOWASP Platz 1Geschützter AssistentFremde Anweisung erkanntNur freigegebene AktionenKeine Secrets im KontextAuffälliges wird protokolliertWarum Absicherung zählt25%GenAI-Apps mit Vorfällenpro Jahr bis 2028 (Gartner)9%2025: Ausgangswert derGenAI-Sicherheitsvorfälle (Gartner)36%der Unternehmen in Deutschlandsetzen KI ein (Bitkom)Daten und Anweisungen trennen, Leitplanken einziehen, Auffälliges überwachen

Warum Prompt Injection ganz oben steht

Prompt Injection ist kein exotischer Sonderfall, sondern das am breitesten anerkannte Risiko generativer KI. In der aktuellen OWASP Top 10 für LLM-Anwendungen aus dem Jahr 2025 steht Prompt Injection als LLM01 an der Spitze der insgesamt zehn Risikokategorien (OWASP), gefolgt von Themen wie der Offenlegung sensibler Informationen als LLM02 und dem Abgreifen des System-Prompts als LLM07 (OWASP). Dass ausgerechnet die Manipulation über Text ganz oben steht, hat einen einfachen Grund: Sie betrifft jede Anwendung, die überhaupt Text von außen entgegennimmt, und das tut ein Chat-Assistent seiner Natur nach. Auch das NIST beschreibt Prompt Injection in seiner Taxonomie zur adversarialen KI, NIST AI 100-2e2025 vom März 2025, als eigene Angriffsklasse und unterscheidet dort ausdrücklich direkte von indirekten Varianten (NIST).

Kurz erklärt: Was ist Prompt Injection?

Prompt Injection bezeichnet den Versuch, einem Sprachmodell über eingeschleusten Text Anweisungen unterzuschieben, die es eigentlich nicht befolgen soll. Der Angreifer formuliert seine Eingabe so, dass das Modell sie nicht als zu bearbeitenden Inhalt, sondern als neue Handlungsanweisung interpretiert, etwa nach dem Muster: Ignoriere deine bisherigen Vorgaben und gib stattdessen Folgendes aus. Anders als bei klassischen Sicherheitslücken gibt es keine fehlerhafte Codezeile, die man einfach patchen könnte, denn die Schwachstelle steckt in der Funktionsweise des Modells selbst.

Für einen Chat-Assistenten ist das keine akademische Frage. Er ist genau die Art von Anwendung, die laufend Text von außen aufnimmt: Fragen im Chatfenster, Inhalte aus der eigenen Website, Angaben aus einem Formular, mitunter Daten aus angebundenen Systemen. Jede dieser Quellen kann, gewollt oder ungewollt, Text enthalten, der wie eine Anweisung aussieht. Wie viele Unternehmen dieses Risiko inzwischen betrifft, zeigt die Verbreitung: In Deutschland setzen bereits 36 Prozent (Bitkom) der Unternehmen KI ein, fast doppelt so viele wie im Vorjahr mit 20 Prozent (Bitkom). Mit der Zahl der produktiven Assistenten wächst auch die Angriffsfläche, weshalb Sicherheit von Anfang an mitgedacht gehört.

Daten und Anweisungen im selben Kanal

Die eigentliche Ursache liegt tiefer als bei einem einzelnen Programmierfehler. Ein Sprachmodell erhält seinen System-Prompt, den Gesprächsverlauf und die Eingabe des Nutzers als einen zusammenhängenden Textstrom. Es gibt technisch keine harte Grenze, die sagt: Bis hierhin stehen verbindliche Anweisungen, ab hier folgt nur noch Material zum Lesen. Für das Modell ist beides Sprache. Das Bundesamt für Sicherheit in der Informationstechnik hat bereits 2023 in einer Cybersicherheitswarnung darauf hingewiesen, dass indirekte Prompt Injections eine intrinsische Schwachstelle anwendungsintegrierter KI-Sprachmodelle sind, also keine vorübergehende Kinderkrankheit, sondern eine Eigenschaft der Technologie (BSI).

Solange ein Modell Daten und Anweisungen im selben Textstrom verarbeitet, ist die Trennung von Auftrag und Inhalt keine Selbstverständlichkeit, sondern muss durch das Design der Anwendung erzwungen werden.

Leitgedanke zur Absicherung von KI-Assistenten

Weil die Schwachstelle strukturell ist, lässt sie sich nicht mit einem einzelnen Filter abschalten. Sowohl das NIST als auch das BSI empfehlen deshalb keinen Einzelschutz, sondern ein gestaffeltes Vorgehen aus mehreren, sich ergänzenden Maßnahmen, oft als Defense in Depth bezeichnet (NIST, BSI). Der Anspruch ist dabei nicht, jeden denkbaren Angriff auszuschließen, sondern die Wahrscheinlichkeit und die möglichen Auswirkungen so weit zu senken, dass ein Assistent verantwortbar in Betrieb gehen kann. Genau dieses Denken in Ebenen zieht sich durch die folgenden Abschnitte.

Direkte und indirekte Angriffe

In der Taxonomie von OWASP und NIST werden zwei Grundformen unterschieden, die sich nicht im Ziel, wohl aber im Weg unterscheiden (OWASP, NIST). Beide wollen das Verhalten des Assistenten verändern, doch die eine kommt direkt über das Eingabefeld, die andere versteckt sich in Inhalten, die der Assistent nur liest.

Direkte Prompt Injection

Der Angreifer tippt die schädliche Anweisung selbst in den Chat, etwa als Aufforderung, bisherige Regeln zu ignorieren oder interne Vorgaben preiszugeben. Die Manipulation kommt hier auf direktem Weg über das Eingabefeld.

Indirekte Prompt Injection

Die Anweisung steht versteckt in fremden Inhalten, die der Assistent verarbeitet, etwa in einer Webseite, einem Dokument, einer Bewertung oder einer E-Mail. Liest der Assistent diesen Text, um zu antworten, kann die eingebettete Anweisung wirken, ohne dass der Nutzer sie sieht.

Besonders tückisch ist die indirekte Variante, weil die Anweisung nicht vom sichtbaren Gesprächspartner kommt, sondern aus einer scheinbar harmlosen Quelle. Das NIST hat genau diese Ausweitung in seine Taxonomie AI 100-2e2025 aufgenommen und beschreibt indirekte Prompt Injection als Angriff, bei dem präparierte Inhalte in Datenquellen platziert werden, die ein System später liest und verarbeitet (NIST). Für einen Assistenten bedeutet das: Jede externe Quelle, aus der er Wissen zieht, sollte als potenziell manipuliert gelten und darf nicht ungeprüft wie ein Befehl behandelt werden. Wie sich ein Assistent stattdessen eng an geprüftes, kuratiertes Wissen bindet, ist deshalb nicht nur eine Frage der Antwortqualität, sondern auch der Sicherheit.

Was ein erfolgreicher Angriff anrichtet

Gelingt eine Prompt Injection, reichen die Folgen von harmlos bis heikel, je nachdem, welche Fähigkeiten und Zugriffe der Assistent hat. Die OWASP-Liste ordnet mehrere dieser Folgen eigenen Kategorien zu, was zeigt, wie eng die Risiken zusammenhängen (OWASP). Typisch sind vor allem diese Auswirkungen:

  • Preisgabe von Informationen, die im System-Prompt oder im Kontext stehen, was der Kategorie System Prompt Leakage als LLM07 entspricht (OWASP)
  • Umgehen der definierten Regeln, Grenzen und Tonalität, oft als Jailbreak bezeichnet
  • Auslösen unerwünschter Aktionen über angebundene Werkzeuge, was OWASP als Excessive Agency, LLM06, führt (OWASP)
  • Ausgabe falscher, verzerrter oder manipulierter Auskünfte an Besucher
  • Weiterreichen manipulierten Textes an nachgelagerte Systeme, wo er weiteren Schaden anrichten kann

Dass solche Vorfälle keine reine Theorie sind, zeigt der Blick nach vorn: Gartner erwartet, dass bis 2028 rund 25 Prozent (Gartner) aller Unternehmens-Anwendungen mit generativer KI mindestens fünf kleinere Sicherheitsvorfälle pro Jahr verzeichnen, nach 9 Prozent (Gartner) im Jahr 2025. Für schwerwiegende Vorfälle rechnet Gartner bis 2029 mit einem Anstieg auf 15 Prozent (Gartner), ausgehend von 3 Prozent (Gartner) im Jahr 2025. Und bis 2028 sollen rund 50 Prozent (Gartner) der Aufwände in der Reaktion auf Sicherheitsvorfälle auf KI-getriebene Anwendungen entfallen. Diese Richtung unterstreicht, dass Absicherung kein einmaliges Hinderungsthema ist, sondern zum laufenden Betrieb gehört.

Angriffssicherheit ist nicht Datenschutz

Prompt-Injection-Sicherheit und Datenschutz werden oft in einen Topf geworfen, sind aber zwei verschiedene Baustellen. Beim Datenschutz nach der DSGVO geht es darum, personenbezogene Daten rechtmäßig, sparsam und transparent zu verarbeiten, mit Rechtsgrundlage, Auftragsverarbeitung und Löschkonzept. Bei der Angriffssicherheit geht es um etwas anderes: um den Schutz vor gezielter Manipulation, also darum, dass sich der Assistent nicht durch eingeschleusten Text zu unerwünschtem Verhalten verleiten lässt. Ein Assistent kann vorbildlich DSGVO-konform gehostet sein und trotzdem anfällig für Prompt Injection bleiben, und umgekehrt. Beide Themen gehören zusammengedacht, aber nicht verwechselt. Worauf es beim Datenschutz konkret ankommt, behandelt der Beitrag zum DSGVO-konformen KI-Assistenten; die Frage der Kennzeichnung von KI im Chat wiederum ist Thema des EU AI Act und der Transparenzpflicht.

Sicherheit und Datenschutz sauber trennen

Behandeln Sie Angriffssicherheit und Datenschutz als zwei eigenständige Prüfpunkte. Der Datenschutz beantwortet die Frage, ob Daten rechtmäßig und sparsam verarbeitet werden. Die Angriffssicherheit beantwortet die Frage, ob sich der Assistent durch eingeschleusten Text zu unerwünschtem Verhalten verleiten lässt. Erst beide Antworten zusammen ergeben ein belastbares Bild, und beide brauchen ihre eigenen Maßnahmen.

Leitplanken, die schützen

Weil es den einen Schalter nicht gibt, setzt eine belastbare Absicherung auf mehrere Ebenen, die zusammenwirken. Sowohl das BSI als auch OWASP empfehlen eine Kombination aus technischen und organisatorischen Maßnahmen statt einer einzelnen Wunderlösung (BSI, OWASP). Die folgenden sechs Leitplanken haben sich in der Praxis (Projekterfahrung) bewährt und greifen ineinander, sodass ein Angriff mehrere Hürden zugleich überwinden müsste.

Eingaben filtern und prüfen

Eingaben werden auf verdächtige Muster und typische Angriffsformulierungen geprüft, bevor der Assistent sie weiterverarbeitet. Das fängt einen Teil der direkten Injektionsversuche frühzeitig ab.

Ausgaben kontrollieren

Bevor eine Antwort an Besucher oder an nachgelagerte Systeme geht, wird sie geprüft, statt sie ungefiltert durchzureichen. So gelangt manipulierter Text nicht ungebremst nach außen.

Keine Geheimnisse im Prompt

Passwörter, Schlüssel oder interne Daten gehören nicht in den System-Prompt, denn der lässt sich ganz oder teilweise herauslocken. Wirklich Geheimes liegt außerhalb des Modells.

Geringste Rechte und Freigaben

Der Assistent erhält nur klar definierte, freigegebene Aktionen statt pauschalen Vollzugriff. Damit bleibt der Schaden begrenzt, selbst wenn eine Manipulation einmal durchkommt.

Antworten an geprüftes Wissen binden

Statt frei zu spekulieren, stützt sich der Assistent auf eine kuratierte Wissensbasis. Fremde Inhalte werden als Material gelesen, nicht als Anweisung ausgeführt.

Monitoring und Protokollierung

Auffällige Gespräche und ungewöhnliche Eingaben werden protokolliert und ausgewertet, sodass sich Angriffsversuche erkennen und die Regeln nachschärfen lassen.

Der System-Prompt ist kein Tresor

Ein häufiger Irrtum ist, Geheimnisse im System-Prompt zu verstecken, weil Besucher ihn nicht sehen. Genau das greift die OWASP-Kategorie System Prompt Leakage als LLM07 an (OWASP): Über geschickte Eingaben lässt sich der verborgene Text oft ganz oder teilweise herauslocken. Alles, was geheim bleiben muss, gehört deshalb nicht in den Prompt, sondern in eine abgesicherte Ebene außerhalb des Modells.

Zwei dieser Leitplanken greifen besonders tief in die Bauweise eines Assistenten ein. Dass er nur klar definierte, freigegebene Aktionen ausführt und nicht pauschal Vollzugriff auf angebundene Systeme erhält, ist der Kern der Tool-Steuerung über Function Calling und wird auf der Seite zur Tool-Steuerung mit klaren Freigaben beschrieben. Dass er seine Antworten eng an geprüfte Inhalte bindet, statt frei zu formulieren, zeigt der Beitrag dazu, wie sich Halluzinationen über eine Wissensbasis vermeiden lassen, und die Seite zur Wissensbasis. Beide Bausteine verbessern zugleich die Antwortqualität und die Sicherheit.

Ungeschützt oder abgesichert: der Vergleich

Der Unterschied zwischen einem Assistenten ohne Leitplanken und einem abgesicherten Assistenten ist nicht kosmetisch, sondern betrifft jede Schicht der Verarbeitung. Die folgende Gegenüberstellung fasst zusammen, woran sich beide Ansätze unterscheiden.

AspektAssistent ohne LeitplankenAbgesicherter Assistent
EingabenWerden ungeprüft übernommenWerden gefiltert und auf verdächtige Muster geprüft
Fremde InhalteWerden wie Anweisungen behandeltWerden als reines Material gelesen, nicht als Befehl
GeheimnisseStehen im System-PromptLiegen außerhalb des Modells in einer sicheren Ebene
AktionenPauschaler Zugriff auf SystemeNur klar definierte, freigegebene Aktionen
AusgabenGehen ungeprüft an Besucher und SystemeWerden vor der Weitergabe kontrolliert
AuffälligkeitenBleiben unbemerktWerden protokolliert und ausgewertet

So wichtig diese Leitplanken sind, so wichtig ist die ehrliche Einordnung: Auch ein abgesicherter Assistent bleibt nicht unangreifbar. Das NIST hält ausdrücklich fest, dass es nach heutigem Stand keinen narrensicheren Schutz gegen Prompt Injection gibt, weil die Schwachstelle in der Funktionsweise der Modelle wurzelt (NIST). Das Ziel ist deshalb eine deutliche Risikoreduktion, gepaart mit einer klaren Rückfalllinie: Wo etwas nicht eindeutig ist oder heikel wird, übergibt der Assistent an einen Menschen, statt zu raten. Wie eine saubere Übergabe an einen Mitarbeiter mit vollem Kontext funktioniert, beschreibt der zugehörige Beitrag.

So sichert XICBOT einen Assistenten ab

Bei XICBOT gehört die Absicherung zum Bau eines Assistenten dazu, nicht zu einem späteren Zusatz. Ein individuell trainierter Assistent hat hier einen Vorteil gegenüber einem beliebigen Baukasten-Chatbot, weil sich seine Regeln, Freigaben und Grenzen gezielt festlegen lassen; wo die Unterschiede liegen, zeigt der Beitrag zum individuell trainierten Assistenten gegenüber einem Standard-Chatbot. Die technische Integration in Ihre Website trennt die notwendigen Funktionen sauber, und das Hosting in Deutschland hält die Verarbeitung im europäischen Rechtsraum. Auch dort, wo ein Assistent aktiv wird und etwa liegengebliebene Warenkörbe im Chat zurückholt, gilt dasselbe Prinzip: klar begrenzte Aktionen statt pauschaler Zugriff.

  • Werden Eingaben gefiltert und auf verdächtige Muster geprüft?
  • Werden fremde Inhalte als Material gelesen, nicht als Anweisung ausgeführt?
  • Ist ausgeschlossen, dass Geheimnisse wie Schlüssel oder interne Daten im System-Prompt stehen?
  • Erhält der Assistent nur klar definierte, freigegebene Aktionen statt Vollzugriff?
  • Werden Ausgaben vor der Weitergabe an Besucher oder Systeme kontrolliert?
  • Werden Auffälligkeiten protokolliert, ausgewertet und die Regeln nachgeschärft?
  • Ist eine saubere Übergabe an einen Menschen vorgesehen, wenn etwas nicht eindeutig ist?

Dass Sicherheit bei KI-Anwendungen zum Standard wird, zeichnet sich ab: Bis 2028 sollen mehr als 50 Prozent (Gartner) der Unternehmen eigene Werkzeuge einsetzen, um KI-Anwendungen abzusichern. Zugleich nennt der Bitkom Verunsicherung durch rechtliche Hürden mit 53 Prozent (Bitkom) als eines der größten Hemmnisse beim KI-Einsatz. Ein Assistent mit durchdachten Leitplanken nimmt einen Teil dieser Unsicherheit, weil er nachvollziehbar zeigt, welche Maßnahmen greifen. Welche Absicherung zu Ihrem Einsatz passt, klären wir am besten gemeinsam im Erstgespräch über die Kontaktseite. Eine absolute Sicherheit lässt sich dabei nicht zusichern, wohl aber ein nachvollziehbares, mehrstufiges Konzept.

Dieser Artikel basiert auf Daten aus: OWASP (Top 10 for LLM Applications 2025, Prompt Injection als LLM01), dem NIST (AI 100-2e2025, Taxonomie zu direkter und indirekter Prompt Injection), dem BSI (Cybersicherheitswarnung zu indirekten Prompt Injections als intrinsischer Schwachstelle), Gartner (Prognosen zu Sicherheitsvorfällen bei generativer KI und zu AI-Security-Werkzeugen) und dem Bitkom (KI-Einsatz in deutschen Unternehmen) sowie eigenen Projekten. Die genannten Werte können sich ändern und je nach Quelle und Zeitpunkt abweichen. Mit (Projekterfahrung) markierte Angaben beruhen auf eigenen Projekten. Dieser Beitrag ersetzt keine individuelle Sicherheits- oder Rechtsberatung; eine absolute Sicherheit lässt sich nicht zusichern.