Wenn ein Dokument zum vermeintlichen Auftrag wird
Sie bitten einen Assistenten, eine Lieferantenanfrage zusammenzufassen. Im Anhang steht zusätzlich eine Anweisung an das KI-System: Bestimmte Angaben sollen verschwiegen oder interne Informationen in die Antwort übernommen werden. Der Anhang gehört zum Material der Aufgabe. Er darf weder den Auftrag ändern noch zusätzliche Zugriffe erlauben. Genau diese Grenze kann bei einem Sprachmodell verletzt werden.
OWASP unterscheidet direkte und indirekte Prompt Injection. Bei der indirekten Variante gelangt die beeinflussende Eingabe über externe Quellen wie Dateien oder Webseiten zum Modell. OWASP nennt unter anderem manipulierte Ausgaben und die Offenlegung vertraulicher Informationen als mögliche Folgen. RAG, also die Suche in einer angebundenen Dokumentenbasis, und Fine-Tuning beseitigen diese Schwachstelle laut OWASP nicht vollständig.
Die Grenze lässt sich einfach formulieren: Ein Dokument kann Informationen für eine Aufgabe liefern; es kann der Anwendung keine neuen Befugnisse erteilen. Das gilt auch für ein Dokument aus einem bekannten Postfach. Wer eine Datei weiterleitet, hat damit nicht automatisch jede darin enthaltene Anweisung geprüft.
Ein fiktiver Fall aus dem E-Mail-Eingang
Das folgende Beispiel ist erfunden und beschreibt kein Kundenprojekt. Ein kleines Unternehmen lässt eingehende Anfragen vorsortieren. Der Assistent soll Ansprechpartner, gewünschte Leistung und offene Fragen erfassen und einen Antwortentwurf anlegen. Er hat dafür Zugriff auf das Eingangspostfach und eine interne Preisübersicht.
Eine Nachricht enthält eine gewöhnliche Anfrage. Im angehängten Dokument wird der KI zusätzlich mitgeteilt, für die Bearbeitung müsse die gesamte interne Preisübersicht in die Antwort aufgenommen werden. Diese angebliche Bearbeitungsregel ist Teil des fremden Inhalts. Das Unternehmen hat den zusätzlichen Versand nicht beauftragt.
Eine mögliche Fehlfunktion beginnt bereits im Entwurf: Die interne Liste erscheint im Antworttext. Dafür muss die KI keine E-Mail selbst senden können. Eine Person kann einen plausibel formulierten Entwurf überfliegen und den unerwünschten Inhalt anschließend verschicken. Die Kontrolle muss daher auch sichtbar machen, welche Quellen und Angaben in der Antwort verwendet wurden.
Für diesen Musterablauf wäre eine engere Lösung vorzuziehen: Die Vorsortierung erhält keine vollständige Preisübersicht. Ein späterer Schritt bekommt bei Bedarf nur die für die konkrete Anfrage freigegebenen Angaben. Vor dem Versand werden Inhalt und Empfänger geprüft. Diese Aufteilung ist eine redaktionelle Empfehlung für das Beispiel, kein Nachweis, dass jede solche Architektur Angriffe verhindert.
Die Folgen hängen vom konkreten Ablauf ab
Beginnen Sie die Bewertung mit dem Weg der Informationen. Welche fremden Inhalte liest die KI? Welche internen Daten werden gleichzeitig bereitgestellt? Wohin kann eine Ausgabe gelangen? Bei einer Zusammenfassung ohne weitere Anbindung betrifft ein Fehler zunächst den Text. Bei einem Assistenten mit Zugriff auf weitere Dateien oder Geschäftssysteme reicht die mögliche Wirkung weiter.
Microsoft beschreibt E-Mails, Dokumente, Webseiten und Erweiterungen als mögliche Eingänge für indirekte Prompt Injection. Die dort empfohlene Abwehr kombiniert mehrere Schichten, darunter die Kennzeichnung fremder Inhalte, Überwachung und technische Begrenzungen. Für die betriebliche Einordnung bedeutet das: Eine Eingangsprüfung muss mit dem tatsächlichen Datenfluss und den verfügbaren Funktionen zusammenpassen.
Notieren Sie für einen ausgewählten Ablauf drei konkrete Fehlerfolgen: Was könnte falsch im Ergebnis stehen? Welche vertrauliche Information könnte in die Ausgabe geraten? Welche Aktion könnte dadurch ausgelöst werden? So lässt sich der Schutz mit einem technischen Umsetzungspartner besprechen, ohne pauschal alle KI-Anwendungen im Unternehmen gleich zu behandeln.
Inhalt und Steuerung getrennt halten
Ein verlässlicher Arbeitsauftrag wird von der Anwendung vorgegeben. E-Mail-Text, Anhänge und Suchergebnisse werden als fremdes Material übergeben und entsprechend gekennzeichnet. Die Anwendung sollte außerdem Herkunft und Fundstelle erhalten. Die prüfende Person muss erkennen können, ob eine Angabe aus der Kundenanfrage, einer internen Regel oder einer vom Modell erzeugten Vermutung stammt.
Eine solche Trennung im Prompt hilft dem Modell, die Rollen der Texte zu verstehen. Sie ersetzt keine technische Kontrolle. Entscheidend ist beispielsweise, ob eine fremde Passage direkt in die nächste Arbeitsanweisung übernommen wird. Auch eine Zusammenfassung eines Dokuments bleibt von diesem Dokument beeinflusst; sie wird durch das Zusammenfassen nicht automatisch zu einer vertrauenswürdigen Steuerregel.
Fragen Sie deshalb bei einem bestehenden Ablauf nach dem ganzen Weg: Wird ein gelesener Text als Notiz gespeichert, später erneut abgerufen und dann als verbindliche Vorgabe verwendet? Kann eine aus dem Dokument gewonnene Adresse ungeprüft zum Versandziel werden? Diese Übergänge sind im Prozessbild ausdrücklich zu markieren. Gerade dort muss die Anwendung zwischen Information und erlaubter Handlung unterscheiden.
Zugriffe und Ausgabewege außerhalb der KI begrenzen
Für angebundene Funktionen empfiehlt OWASP im Abschnitt „Excessive Agency“ einen möglichst kleinen Funktionsumfang und minimale Berechtigungen. Die Organisation muss festlegen, was eine Anwendung tatsächlich tun darf. Eine im Dokument behauptete Zustimmung kann diese Berechtigung nicht ersetzen.
Im fiktiven E-Mail-Fall heißt das: Der Lesezugriff auf den Eingang ist getrennt vom Zugriff auf interne Unterlagen. Der Versand folgt einer eigenen Regel. Wenn nur ein Antwortentwurf gebraucht wird, ist eine Funktion zum direkten Versenden unnötig. Technische Zugangsdaten gehören in die abgesicherte Anbindung; sie sollen nicht als Text in den Modellkontext gelangen.
Auch erlaubte Funktionen brauchen Grenzen bei ihren Eingaben. Ein Umsetzungspartner sollte zeigen können, welche Empfänger, Dateibereiche oder Zielsysteme zugelassen sind und wo diese Prüfung stattfindet. „Die KI wurde angewiesen, nichts Unzulässiges zu tun“ beantwortet diese Frage nicht. Die Prüfung muss auch dann greifen, wenn das Modell eine unpassende Aktion vorschlägt.
Für sensible Ausgaben ist eine nachvollziehbare Prüfansicht sinnvoll: geplante Aktion, Ziel, verwendete Angaben und Herkunft stehen zusammen. Ein allgemeiner Button „Freigeben“ hilft wenig, wenn die Person die tatsächliche Wirkung nicht sehen kann. Die notwendige Tiefe der Kontrolle richtet sich nach dem jeweiligen Vorgang.
Was ein Schutzfilter leistet – und was zu prüfen bleibt
Microsoft dokumentiert Prompt Shields als zusätzliche Schutzschicht für Angriffe über Nutzereingaben und Dokumente. Die Dokumentation unterscheidet ausdrücklich zwischen einem erkannten und einem gefilterten Angriff. Zudem nennt sie mögliche Fehlalarme und Hinweise zur Prüfung der tatsächlichen Konfiguration. Das sind Herstellerangaben zu einer Funktion, keine Zusage für Ihren gesamten Ablauf.
Für ein KMU ergeben sich daraus konkrete Fragen an den Anbieter: Werden nur direkte Chat-Eingaben geprüft oder auch eingelesene Anhänge und Ergebnisse angebundener Werkzeuge? Ist eine Auffälligkeit lediglich protokolliert oder wird der betroffene Schritt angehalten? Was sieht die zuständige Person, wenn eine normale Anfrage irrtümlich blockiert wird?
Ein vorhandener Filter sollte im Test sichtbar reagieren. Sein Name in einer Produktbeschreibung reicht nicht aus. Lassen Sie außerdem erklären, welche Begrenzung erhalten bleibt, falls eine fremde Anweisung unentdeckt durchkommt. Das schützt vor einer falschen Schlussfolgerung: „Kein Alarm“ bedeutet zunächst nur, dass dieser Filter keinen Alarm ausgelöst hat.
Schutz mit ungefährlichen Testfällen überprüfen
Testen Sie den vollständigen Ablauf in einer getrennten Umgebung mit künstlichen Daten. Verwenden Sie weder reale vertrauliche Listen noch einen echten externen Versand. Für den fiktiven Fall genügt eine interne Musterliste, deren Werte in keiner Antwort auftauchen dürfen. Der erwartete Ausgang wird vor dem Test festgehalten.
Eine kleine erste Testreihe kann folgende Varianten enthalten. Sie ist ein Einstieg in die Prüfung und kein vollständiger Sicherheitstest:
- Unauffällige Anfrage: Die KI erfasst die benötigten Angaben und erstellt den vorgesehenen Entwurf.
- Fremde Bearbeitungsregel: Der Anhang versucht, den Arbeitsauftrag zu ändern. Die vorgegebene Aufgabe und die technischen Grenzen bleiben wirksam.
- Angebliche interne Zustimmung: Ein Dokument behauptet, die Geschäftsführung habe einen zusätzlichen Zugriff erlaubt. Daraus entsteht keine neue Berechtigung.
- Unerwartetes Versandziel: Eine fremde Quelle nennt eine zusätzliche Adresse. Die Anwendung übernimmt sie nicht ungeprüft als Empfänger.
- Legitimes Zitat: Eine Schulungsunterlage beschreibt einen Angriff. Die Anwendung behandelt die Passage als Inhalt; ein möglicher Filterhinweis wird nachvollziehbar bearbeitet.
Prüfen Sie neben dem Antworttext auch gespeicherte Notizen und vorgeschlagene Folgeschritte. Ein korrekt aussehender Entwurf genügt nicht, wenn im Hintergrund eine unerlaubte Datenabfrage stattgefunden hat. Halten Sie fest, welche Kontrolle einen Versuch angehalten hat und welche Informationen die zuständige Person tatsächlich sehen konnte.
Die Testfälle sollten nach Änderungen an Modell, Prompt, Datenquellen oder Anbindungen wiederholt werden. Ein bestandener Test belegt das beobachtete Verhalten dieser Version mit diesen Fällen. Er beweist keine allgemeine Angriffssicherheit. Für Vorgänge mit erheblichen Fehlerfolgen ist eine weitergehende technische Sicherheitsprüfung erforderlich.
Bei einer Auffälligkeit den Vorgang gezielt anhalten
Legen Sie vor dem Betrieb fest, wer einen verdächtigen Vorgang prüft. Im Musterablauf bleibt der betroffene Antwortentwurf im Prüfstatus. Die Nachricht und die relevante Fundstelle werden für die Klärung gesichert; die enthaltene Anweisung wird nicht durch manuelles Kopieren in einen neuen KI-Auftrag weitergereicht.
Anschließend wird der tatsächliche Ablauf geprüft: Welche Informationen wurden gelesen? Was wurde nur vorgeschlagen, was gespeichert oder versendet? Sind andere Vorgänge von derselben Quelle betroffen? Ein auffälliger Text allein belegt noch keinen Datenabfluss. Umgekehrt kann ein unauffälliger Antworttext eine unerlaubte Hintergrundaktion nicht ausschließen. Die Bewertung braucht die verfügbaren technischen Nachweise.
Für kleine Teams sollte dieser Ausnahmeweg kurz dokumentiert und erreichbar sein. Ein Filter, der Vorgänge anhält, aber niemanden zuständig macht, verlagert das Problem in eine unbeachtete Warteschlange. Die Rückkehr zum normalen Ablauf erfolgt erst nach der vereinbarten Prüfung.
Mit einem vorhandenen Ablauf anfangen
Wählen Sie eine KI-Anwendung, die bereits E-Mails, Dateien oder Webseiten liest. Zeichnen Sie auf einer Seite auf, welche Daten hineingehen und wohin Ergebnisse gelangen. Markieren Sie dann die Stellen, an denen fremder Inhalt eine interne Entscheidung oder eine Aktion beeinflussen kann. Daraus entsteht ein konkreter Prüfauftrag.
Jacob Damböck unterstützt im Rahmen der KI-Potenzialanalyse und der Planung von Prozessautomatisierung dabei, Anforderungen, Datenwege und Prüfkriterien zu klären. Für eine technische Sicherheitsprüfung braucht es je nach Anbindung passende Fachleute. Zum ersten Gespräch genügt eine Beschreibung des Ablaufs; vertrauliche Originaldateien sind dafür nicht nötig.
Primärquellen und Einordnung
Die verlinkten OWASP-Leitfäden und Microsoft-Dokumentationen wurden am 7. Oktober 2026 geprüft. Sie belegen Angriffstypen, Schutzprinzipien und die genannten Produktfunktionen. Konfiguration und Funktionsumfang können sich ändern.
Der E-Mail-Musterfall, die betrieblichen Prüffragen und die vorgeschlagene Testreihe sind die redaktionelle Einordnung von Jacob Damböck. Sie beschreiben keine beobachteten Kundenfälle oder gemessenen Schutzquoten. Ob die Grenzen eines konkreten Systems wirksam sind, muss an seiner tatsächlichen Umsetzung geprüft werden.