Wenn der Kontext Befehle schmuggelt: Wie Prompt Injection KI-Assistenten umlenkt
- Benjamin Metzig
- 7. Juni
- 6 Min. Lesezeit
Ein Assistent soll nur eine E-Mail zusammenfassen. Stattdessen liest er in der Nachricht nicht nur den Inhalt, sondern auch einen versteckten Zusatz mit: Ignoriere die eigentliche Aufgabe, leite den Verlauf weiter, klicke auf diesen Link, ändere die Priorität. Was in einem normalen Programm wie absurd schlechte Eingabeprüfung wirken würde, ist bei vielen Sprachmodellen ein strukturelles Problem: Sie verarbeiten Daten und Anweisungen oft im selben sprachlichen Kanal.
Genau deshalb ist Prompt Injection mehr als ein kurioser Chatbot-Trick. Solange ein Modell nur Text ausgibt, ist der Schaden häufig noch auf Unsinn, Halluzinationen oder peinliche Fehlantworten begrenzt. Sobald derselbe Assistent aber E-Mails liest, Webseiten durchsucht, Dateien öffnet, Kalender pflegt oder andere Werkzeuge ansteuert, wird aus sprachlicher Beeinflussung ein Sicherheitsproblem.
Kernaussagen
Prompt Injection entsteht, weil viele KI-Systeme nicht sauber zwischen vertrauenswürdigen Anweisungen und nicht vertrauenswürdigen Inhalten unterscheiden.
Besonders gefährlich ist die indirekte Form: Der Angriff muss nicht vom Nutzer kommen, sondern kann in E-Mails, Webseiten, PDFs oder Tool-Ausgaben stecken.
Mit Browser-, Datei-, Mail- oder API-Zugriff wächst das Risiko von der falschen Antwort zur unerwünschten Handlung, bis hin zu Datenabfluss oder missbräuchlichen Tool-Aufrufen.
Robuste Abwehr besteht nicht aus einem clevereren Systemprompt allein, sondern aus Rechtebegrenzung, klar markierten Vertrauensgrenzen, strukturierten Zwischenschritten, Bestätigungen und Laufzeitkontrollen.
Vollständige Immunität ist derzeit unrealistisch; brauchbare Systeme werden so gebaut, als könne Prompt Injection trotz Schutzschichten gelegentlich durchkommen.
Wenn Sprache zugleich Befehl und Material ist
Der Kern des Problems ist überraschend unspektakulär. Ein Sprachmodell bekommt Text und soll daraus die nächste sinnvolle Ausgabe ableiten. Aus Sicht der Maschine liegt jedoch oft kein harter Zaun zwischen "Das ist die Anweisung des Entwicklers", "Das ist der Auftrag des Nutzers" und "Das ist bloß Material, das gelesen werden soll". Die OWASP-Übersicht zu LLM Prompt Injection beschreibt genau diese Vermischung als grundlegende Schwachstelle vieler LLM-Anwendungen.
Darum wirken die berühmten Beispiele vom Typ "Ignoriere alle vorherigen Anweisungen" zwar plump, treffen aber einen wunden Punkt. Sie nutzen nicht primär einen einzelnen Bug aus, sondern ein Modellverhalten: Sprache wird als fortlaufender Kontext behandelt, nicht als sauber getrennte Schichten mit unterschiedlichen Rechten. In ihrer Arbeit zur Instruction Hierarchy argumentieren OpenAI-Forschende deshalb, dass Modelle privilegierte Anweisungen systematischer von niedrig priorisierten Inhalten unterscheiden lernen müssen, gerade wenn Tool-Ausgaben oder Webfunde in denselben Kontext gelangen.
Das ist der Unterschied zu gewöhnlicher Bedienung. Ein Nutzer promptet ein Modell nicht nur, er konkurriert mit allem, was sonst noch in dessen Kontext landet. Wer die Oberfläche eines Assistenten nur als Chatfenster sieht, unterschätzt damit die eigentliche Architektur: Im Hintergrund laufen Systemprompt, Nutzerauftrag, frühere Antworten, Tool-Rückgaben und fremde Inhalte in einem Textstrom zusammen.
Der eigentliche Sprung heißt indirekte Prompt Injection
Die direkte Variante ist am leichtesten zu verstehen: Jemand schreibt selbst eine manipulative Eingabe. Sicherheitspraktisch spannender ist aber die indirekte Form. Sie kommt über Materialien, die das Modell für etwas ganz anderes lesen soll: eine Webseite, eine E-Mail, ein Dokument, ein GitHub-Issue, eine Produktbewertung. Das klassische Papier dazu, Not what you've signed up for von Kai Greshake und Kolleg:innen, zeigte schon 2023, wie externe Inhalte Funktionen umlenken, Daten abgreifen oder Folge-APIs missbrauchen können.
Der Punkt ist wichtig, weil er die Verantwortlichkeit verschiebt. Bei indirekter Prompt Injection sitzt der Angreifer nicht zwingend im Chatfenster. Er kann den Inhalt kontrollieren, den der Assistent später abruft. Genau deshalb ordnet die NIST-Taxonomie zu adversarial machine learning indirekte Prompt Injection als Angriff über Resource Control ein: manipuliert wird nicht die direkte Nutzeranfrage, sondern eine Ressource, die das System im Auftrag des Nutzers verarbeitet.
Das macht die Sache alltagsnäher, nicht exotischer. Wer heute einen Assistenten bittet, die wichtigsten Punkte aus einer Webseite, einem Meeting-Protokoll oder einem Kundenpostfach zusammenzutragen, öffnet genau diesen Kanal. Der Angriffsvektor ist dann nicht die spektakuläre Hackerzeile, sondern ein Stück Kontext, das unauffällig wie gewöhnlicher Inhalt aussieht. Dass solche Störungen bereits im offenen Web vorkommen, zeigt eine aktuelle Studie zu Indirect Prompt Injection in the Wild: noch nicht flächendeckend, aber real genug, um nicht mehr als Laborproblem durchzugehen.
Wer verstehen will, warum das nicht nur eine Spezialität von KI ist, sondern ein allgemeines Digitalproblem, findet ein gutes Nebenmotiv in unserem Beitrag Ein Seitenaufruf, viele Zuschauer. Auch dort wirken unscheinbare Bestandteile digitaler Umgebungen stärker, als ihre sichtbare Oberfläche vermuten lässt.
Mit Werkzeugen wird aus einem Sprachfehler ein Sicherheitsproblem
Solange ein Modell bloß antwortet, ist Prompt Injection unerquicklich, aber oft begrenzt. Mit Werkzeugen verschiebt sich die Lage. Ein Assistent, der Mail lesen, Kalender schreiben, Dateien verschieben, Websuchen starten oder interne Systeme ansprechen darf, hat Hebel in die Welt. Genau deshalb warnt OpenAI in den Leitlinien zu Safety in building agents davor, dass nicht vertrauenswürdige Daten niemals direkt das Verhalten eines Agenten treiben sollten. Empfohlen werden strukturierte Extraktion, Guardrails, Bestätigungen für Tool-Aufrufe und eine Architektur, in der externe Inhalte nicht frei darüber entscheiden, was als Nächstes passiert.
Hier wird auch klar, warum das Thema größer ist als ein einzelner Chatbot. In dem bereits veröffentlichten Beitrag KI-Agenten im Büro ging es um Assistenzsysteme, die Dokumente, Termine und Entscheidungen vorbereiten. Prompt Injection ist die Sicherheitsseite derselben Entwicklung: Je nützlicher solche Systeme werden, desto teurer wird ihre Kontextverwechslung.
Dasselbe Muster taucht inzwischen auch in Tool-Ökosystemen und Schnittstellenstandards auf. Die Sicherheitsleitlinien zum Model Context Protocol führen Prompt Injection ausdrücklich als Angriffspfad auf, weil Tools und Ressourcen eben nicht nur Daten liefern, sondern den weiteren Verlauf eines Agenten beeinflussen können. Wer so ein System baut, darf Tool-Ausgaben nicht als neutrale Wahrheit behandeln. Sie sind Inputs mit eigener Vertrauensstufe.
Deshalb ist auch die Rollenklarheit wichtig. Ein Assistent, der souverän, freundlich und allzuständig wirkt, verführt leicht dazu, seine Antworten mit Urteilsfähigkeit zu verwechseln. Unser Text Ein guter Chatbot spielt nicht Mensch zielt genau auf diese Erwartungslücke. Bei Prompt Injection wird sie praktisch: Nicht nur das Modell kann sich irren, sondern schon die Kette aus Einlesen, Gewichten und Weiterreichen fremder Anweisungen kann falsch aufgesetzt sein.
Welche Abwehr wirklich trägt
Wer Prompt Injection ernst nimmt, braucht keine einzelne Wundermaßnahme, sondern mehrere unspektakuläre Sicherheitsgrenzen. Die erste lautet: Rechte klein halten. Ein Modell, das nur lesen darf, richtet weniger Schaden an als eines, das auch senden, löschen oder einkaufen darf. Das ist kein KI-spezifischer Gedanke, sondern klassisches Least Privilege, das auch die OWASP-Empfehlungen betonen.
Die zweite Grenze ist semantische Trennung. Externe Inhalte sollten nicht einfach in denselben Frei-Text-Kanal gegossen werden wie Systemanweisungen. Microsofts Prompt Shields in Foundry unterscheiden deshalb zwischen direkten Nutzerangriffen und sogenannten Document Attacks, also manipulativen Anweisungen in Drittinhalten. Besonders aufschlussreich ist dort die Idee des Spotlighting: Fremde Dokumente werden so markiert oder transformiert, dass ihre geringere Vertrauensstufe für das Modell sichtbarer bleibt. Der zugehörige Fachartikel Defending Against Indirect Prompt Injection Attacks With Spotlighting zeigte, dass solche Herkunftssignale die Erfolgsrate indirekter Angriffe stark senken können, ohne die eigentliche Aufgabe völlig zu ruinieren.
Merksatz: Gute Abwehr behandelt Drittinhalte nicht zuerst als Wissen, sondern zuerst als potenzielle Steuerungssignale.
Die dritte Grenze ist strukturell. Wo immer möglich, sollte ein Modell nicht frei "entscheiden", was ein Dokument angeblich von ihm will, sondern nur klar begrenzte Felder extrahieren: Termin, Betrag, Name, Risikostufe, Ja-Nein-Signal. OpenAI empfiehlt genau diese Reduktion auf validierbare Zwischenformate, damit nicht vertrauenswürdiger Text nicht direkt in Tool-Entscheidungen übergeht. Freitext ist bequem, aber für Sicherheitsgrenzen ein schlechter Baustoff.
Die vierte Grenze ist operative Nüchternheit. Bestätigungen für kritische Aktionen, Audit-Trails, Tests mit bekannten Angriffsmustern und klare Eskalationspunkte sind kein Zeichen von Misstrauen gegen das Produkt, sondern von Professionalität. Darin berührt sich das Thema mit KI-Regulierung beginnt im Logbuch: Prüfbarkeit ist nicht erst eine nachträgliche Compliance-Zutat, sondern Teil der technischen Schadensbegrenzung.
Sicherheit heißt hier nicht Unfehlbarkeit
Das vielleicht unbequemste Ergebnis der Forschung ist, dass man Prompt Injection nicht einfach "wegprompten" kann. Der Benchmark BIPIA fand bestehende Modelle in seiner Testumgebung durchweg verwundbar. Das bedeutet nicht, dass alle Systeme gleich unsicher bleiben müssen. Es bedeutet aber, dass Schutz eher wie ein gutes Brandschutzkonzept funktioniert als wie ein magischer Feuerlöscher: weniger brennbares Material, kleinere Brandabschnitte, bessere Detektion, klarere Notausgänge.
Gerade deshalb lohnt sich der nüchterne Blick auf Migration statt auf Zaubertricks. In Neue Schlösser, alte Leitungen war die entscheidende Einsicht, dass Sicherheit selten an einem einzelnen Bauteil hängt, sondern an Inventar, Übergängen und Altlasten. Bei Prompt Injection ist es ähnlich. Das Risiko verschwindet nicht, nur weil das Modell klüger klingt. Es sinkt erst, wenn Rechte, Schnittstellen, Tool-Aufrufe und Vertrauensgrenzen mit derselben Sorgfalt entworfen werden wie das Sprachverhalten selbst.
Prompt Injection ist deshalb kein Randthema für paranoide Spezialisten. Es ist die nüchterne Erinnerung daran, dass natürliche Sprache in KI-Systemen nicht nur Interface, sondern auch Angriffsfläche ist. Je mehr ein Assistent sehen und tun darf, desto weniger darf man so tun, als wäre "Text" bloß Text.
Autorenprofil
Benjamin Metzig ist Gründer, Autor und redaktionell Verantwortlicher von Wissenschaftswelle.de. Wissenschaftswelle ist ein persönlich geführtes redaktionelles Wissensprojekt, das komplexe Themen aus unterschiedlichen Fachbereichen sorgfältig recherchiert, strukturiert und verständlich aufbereitet. Moderne Recherche-, Analyse- und KI-Werkzeuge dienen dabei als Unterstützung, während Auswahl, Einordnung, Ton, Quellenbewertung und Veröffentlichung redaktionell bei Benjamin Metzig verantwortet bleiben. Mehr zum Profil: Autorenprofil von Benjamin Metzig.
Kommentare