Was ist Dokument-Prompt-Injection?
Dokument-Prompt-Injection ist indirekte Prompt Injection über eine Datei oder ein Dokument, das ein AI-System liest, parst, konvertiert, zusammenfasst, klassifiziert, indexiert oder anderweitig für ein Modell sichtbar macht. Angreifer können das ganze Dokument, ein bearbeitbares Feld, einen Kommentar, einen Abschnitt einer geteilten Datei, einen hochgeladenen Anhang oder aus einer externen Quelle synchronisierte Inhalte kontrollieren. Direkter Zugriff auf den Zielassistenten ist nicht nötig: Eine berechtigte Person oder ein automatisierter Workflow kann die Verarbeitung später auslösen.
Die maßgebliche Grenze ist keine bestimmte Dateiendung. Office- und Produktivitätsdateien, kollaborative Dokumente, Text- und Markup-Dateien, Präsentationen und andere dokumentartige Container können extern verfasste Sprache in den Modellkontext tragen. PDF hat einen eigenen Artikel: PDF Prompt Injection. Diese Seite konzentriert sich auf den allgemeinen Pfad der Dokumentverarbeitung.
Modellbeeinflussung und Sicherheitsauswirkung bleiben getrennt. Eine veränderte Zusammenfassung, Klassifikation oder Planung belegt Einfluss. Eine Sicherheitsfolge verlangt zusätzlich einen sensiblen Daten- oder Fähigkeitspfad und eine fehlende, zu breite oder versagende Anwendungskontrolle.
Die Dokumentverarbeitungskette von Ende zu Ende
Reale Produkte verbinden oder vertauschen einzelne Stufen. Manche rendern zuerst und wenden OCR an, andere durchlaufen Bestandteile eines Pakets, rufen einen Konvertierungsdienst auf oder übergeben ausgewählten Text direkt an ein Modell. Die Sicherheitsaufgabe besteht darin, den tatsächlichen Laufzeitpfad und die Vertrauensentscheidung an jedem Übergang zu dokumentieren.
Vertrauenswürdige Verarbeitungsinfrastruktur kann angreiferkontrollierten Text korrekt ausgeben. Authentifizierte Speicherung, erfolgreiche Typerkennung und ein erwartungsgemäß arbeitender Parser belegen Eigenschaften der Pipeline, aber keine Anweisungsautorität der Nutzdaten. Modellausgabe bleibt ein Vorschlag, bis deterministische Anwendungspolitik auslösendes Principal, Daten, Aktion, Parameter und Ziel prüft.
Erfolgskette der Dokument-Prompt-Injection
Für eine vollständige Ende-zu-Ende-Auswirkung ist jede Stufe erforderlich. Ein Dokument kann vorhanden sein, aber nie verarbeitet werden, verarbeitet werden, ohne den maßgeblichen Teil offenzulegen, sichtbar sein, ohne Einfluss auszuüben, oder Einfluss ausüben, ohne eine geschützte Fähigkeit zu erreichen. Befunde sollten jede Stufe getrennt ausweisen, statt bloße Dateipräsenz als Kompromittierung zu bezeichnen.
Kontrollen können die Kette durch beschränkte Schreibrechte, isolierte Verarbeitung, eine Positivliste erlaubter Bestandteile, Provenienz, Kontextminimierung, Erkennung, geringste Rechte, Policy und Egress-Kontrollen unterbrechen. So hängt die Sicherheit nicht von perfekter semantischer Erkennung ab, während beobachteter Einfluss weiterhin ein wichtiges Untersuchungssignal bleibt.
Die Kette beschreibt zugleich die Randbedingungen, gegen die ein Angriff antreten muss. Die Verarbeitung wird möglicherweise nie ausgelöst, der maßgebliche Bestandteil nicht extrahiert, Inhalt bei der Konvertierung verworfen oder umsortiert, durch Provenienzkennzeichnung als nicht vertrauenswürdiges Aufgabenmaterial markiert, durch Kontextminimierung ausgeschlossen oder trotz sichtbaren Einflusses von deterministischer Policy abgelehnt.
Offensive Perspektive auf die Dokumentaufnahme
Für eine autorisierte Prüfung beginnt die Analyse nicht bei einer Datei, sondern bei der Frage nach Kontrolle: Welches Dokument, welches Feld, welchen Abschnitt, welchen Kommentar, welchen Anhang oder welchen synchronisierten Datensatz kann die prüfende Person legitim verfassen oder bearbeiten, und unter welcher Identität? Inhaltskontrolle allein belegt nichts. Das Dokument muss anschließend einen Workflow erreichen, der es tatsächlich verarbeitet: über Upload, Posteingang, ein geteiltes Laufwerk, einen Kollaborationsbereich, eine Connector-Synchronisation, einen Ticketanhang oder einen Indexierungslauf.
Die nächsten Schranken sind technischer, nicht sprachlicher Natur. Die Datei muss die Typerkennung passieren, an den tatsächlich verwendeten Parser oder Konverter gelangen und ihren maßgeblichen Bestandteil von dieser Implementierung durchlaufen lassen. Konvertierung nach Text, HTML oder ein anderes Zwischenformat, OCR gerenderter Seiten und Normalisierung entscheiden jeweils, ob kontrollierter Inhalt überhaupt erhalten bleibt und in welcher Reihenfolge er neben dem legitimen Haupttext erscheint.
Welche Dokumentfläche lässt sich verfassen oder bearbeiten, und welches Principal verantwortet die Änderung?
Welche realistische Aufgabe, Freigabe, Synchronisation oder Automatisierung bringt das Dokument in einen Verarbeitungsworkflow?
Welcher Parser in welcher Version und Konfiguration verarbeitet es, und welche Bestandteile durchläuft diese Implementierung wirklich?
Was bleibt nach Konvertierung, OCR, Normalisierung, Kürzung und Chunking übrig?
Welche extrahierten Abschnitte gelangen in den konkreten Modellkontext, mit welcher Provenienzkennzeichnung und Reihenfolge?
Verändert dokumentabgeleitete Sprache Antwort, Klassifikation, Plan oder vorgeschlagene Aktion?
Welche Daten, Tools, Ziele und Schreibpfade könnte ein beeinflusster Plan erreichen?
Welche Policy-Entscheidung müsste fehlen, zu breit oder falsch sein, damit eine echte Nebenwirkung entsteht?
Verschleierungsmethoden, wiederverwendbare Anweisungstexte, Platzierungsrezepte für Bestandteile und Verfahren zur Erhöhung der Extraktionswahrscheinlichkeit werden bewusst nicht dargestellt. Der Wert für Abwehr und autorisierte Prüfung liegt in der Struktur der Schranken und ihrer Messung, nicht in der Konstruktion von Payloads.
Ein Dokument ist mehr als sein sichtbarer Haupttext
Viele Dokumentformate sind Container mit mehreren logischen oder physischen Bestandteilen. Der Haupttext in der gewöhnlichen Leseansicht ist nur eine mögliche Darstellung. WordprocessingML-Pakete können neben dem Hauptdokument getrennte Kommentare, Kopf- und Fußzeilen, Fußnoten und Endnoten enthalten; verwandte Dokumentbereiche können Textfelder und Glossarmaterial umfassen. Präsentationspakete können Notizen enthalten. Andere Formate besitzen eigene Strukturen.
Das bedeutet nicht, dass jeder Extraktor jeden Bestandteil liest. Manche verarbeiten nur den Haupttext, andere nehmen Kommentare oder Notizen auf, und manche liefern abhängig von Konfiguration oder Konvertierung unterschiedliche Ergebnisse. Die Sicherheitsfrage ist daher empirisch und produktspezifisch: Welche Bestandteile werden angenommen, extrahiert, erhalten, gekennzeichnet und in den Modellkontext gerendert?
Absätze, Bereiche oder Folien in der gewöhnlichen Lese- oder Präsentationsansicht.
Kommentare, Anmerkungen und revisionsbezogene Inhalte, sofern Format und Extraktor sie unterstützen.
Kopf- und Fußzeilen sowie vorlagenbezogener Text, der visuell nebensächlich sein kann, aber wiederholt extrahiert wird.
Fußnoten, Endnoten, Sprechernotizen, Textfelder und Glossar- oder Wiederverwendungsinhalte, soweit vorhanden.
Metadaten, verknüpfte Ressourcen und Beschreibungen, wenn ein Produkt sie bewusst modellsichtbar macht.
Menschliche Sicht, Parser-Sicht und Modellsicht
| Sicht | Darstellung | Sicherheitsfrage |
|---|---|---|
| Gerenderte menschliche Sicht | Was eine bestimmte Anwendung, Ansicht und Bildschirmgröße zeigt | Konnte eine prüfende Person das Material vernünftig erkennen, das später das Modell beeinflusste? |
| Datei- oder Paketstruktur | Bestandteile, Beziehungen, Eigenschaften und eingebettete Ressourcen im Container | Welche Bestandteile existieren und wer kontrollierte sie? |
| Parser- oder Extraktorausgabe | Ausgewählter und normalisierter Text, Tabellen, Labels, OCR-Ergebnisse oder Objektbeschreibungen | Was hat die Verarbeitung ausgegeben, ausgelassen oder zusammengeführt? |
| Modellsichtbarer Kontext | Exakte extrahierte Abschnitte, Rahmen, Zusammenfassungen und Anwendungsanweisungen für das Modell | Welche Provenienz- und Autoritätslabels überstanden den Kontextaufbau? |
Kommentare, Kopfzeilen, Notizen, Änderungsinhalte, sofern unterstützt, Textfelder, Metadaten, extrahierte Tabellen, bildabgeleiteter Text, Objektbeschreibungen und vom Konverter erzeugter Text können Unterschiede zwischen diesen Sichten schaffen. Eine Abweichung ist nicht automatisch bösartig. Sie ist eine Sichtbarkeits- und Provenienzbedingung, die relevant wird, wenn ungeprüfte Inhalte Einfluss auf sensible Daten oder Fähigkeiten erhalten.
Ein Bildschirmfoto der normalen Dokumentansicht belegt nicht, was das Modell gesehen hat. Umgekehrt belegt rohe Extraktorausgabe nicht, was eine Person sah oder beabsichtigte. Untersuchung und Test brauchen beide Darstellungen sowie die Transformation zwischen ihnen.
Was tatsächlich für das Modell sichtbar wird
Absätze, Überschriften und Strukturlabels, die der Extraktor auswählt.
Review-Inhalte nur dann, wenn Parser, Connector oder Konverter sie einschließt.
Wiederholte oder bereichsspezifische Regionen, die aufgenommen, ausgelassen oder dedupliziert werden können.
Ergänzender Text, dessen Position im flachen Textstrom von der gerenderten Seite abweichen kann.
Sprecher- oder Präsentationsnotizen und vergleichbare unterstützende Teile, sofern das Format sie vorsieht.
Zelltext, Beschriftungen und Zeilenfolge, rekonstruiert als Text oder strukturierter Kontext.
Metadaten, Alternativtexte oder Beschreibungen nur bei bewusster Offenlegung.
Abgeleiteter Text oder Repräsentationen aus Bildern und Scans, sofern das Produkt sie unterstützt.
Inhalt verwandter Objekte nur, wenn der Workflow diese ausdrücklich verarbeitet.
Konvertertext, Zusammenfassungen und RAG-Chunks aus einem oder mehreren Quellbestandteilen.
Umsetzungen unterscheiden sich, daher ist diese Übersicht nicht universell. Teams sollten für jeden unterstützten Dateityp und jede Verarbeitungskonfiguration die exakte modellsichtbare Darstellung erfassen. Extraktion macht Inhalte sichtbar; sie verleiht ihnen keine Autorität.
Containergültigkeit ist kein Inhaltsvertrauen
| Evidenz | Was sie stützen kann | Was sie nicht belegt |
|---|---|---|
| Gültiges Dateiformat | Der Container entspricht ausreichend den Erwartungen eines Verarbeitungswerkzeugs | Dass natürlichsprachlicher Inhalt sicher oder autorisiert ist |
| Schadsoftwarefreie Prüfung | Ein Scanner fand keine von ihm geprüfte Code- oder Artefaktklasse | Abwesenheit semantischer Prompt Injection |
| Vertrauenswürdiger Parser | Die Organisation akzeptiert die Komponente als Infrastruktur | Vertrauenswürdigkeit ihrer Inhaltsausgabe |
| Internes Repository | Die Datei liegt in einem organisatorischen System | Wer jeden Teil verfasste oder ob er eine AI anweisen darf |
| Gültige digitale Signatur oder Integritätsevidenz | Bestimmte Integritäts- oder Unterzeichnereigenschaften des Mechanismus | Anwendungsautorität jeder Aussage im Dokument |
Diese Kontrollen bleiben nützlich. Dateivalidierung und Malware-Scanning behandeln andere Fehlerklassen, Signaturen können Integritäts- und Herkunftsentscheidungen stützen, und verwalteter Speicher kann Zugriffe verbessern. Falsch ist nur ihre Aufwertung zu einer semantischen Autorisierungsentscheidung, für die sie nicht entworfen wurden.
Parsing, Konvertierung und Provenienz
Transformationen können genau die Unterschiede entfernen, die spätere Kontrollen brauchen. Kommentare, Notizen und Haupttext können zu einem Strom verschmelzen; Seiten-, Folien- und Abschnittsgrenzen verschwinden; Stil- und Sichtbarkeitseigenschaften gehen verloren; OCR kann Text einführen, der kein gewöhnlicher auswählbarer Dokumenttext war; und Zusammenfassung kann extern verfasste Inhalte wie ein internes Systemartefakt wirken lassen.
Ein brauchbares Extraktionsmanifest erfasst Quell-ID, Version und kryptografischen Hash; Uploader, Eigentümer, Mandant und Workspace; erkannten und angegebenen Dateityp; Versionen von Parser, Renderer, OCR und Konverter; Typ und stabile Kennung des extrahierten Bestandteils oder Elements; Seite, Folie oder Abschnitt, soweit sinnvoll; Transformationskette; Zugriffslabel; sowie Modellanfrage oder abgeleitetes Artefakt, das die Ausgabe nutzte.
Autoritative Provenienz bleibt außerhalb dokumentverfasster Felder. Ein Satz, der einen Bereich als freigegeben, intern oder öffentlich bezeichnet, ist Inhalt und keine Policy-Metadaten. Abgeleitete Zusammenfassungen und Chunks erben Labels aus der Kontrollebene und behalten Links zu allen zusammengefassten Quellabschnitten.
Office Open XML als Beispiel für ein mehrteiliges Dokument
ECMA-376 und ISO/IEC 29500 definieren Vokabulare, Paketierung und Dokumentdarstellung von Office Open XML. Microsofts Dokumentation beschreibt ein typisches WordprocessingML-Paket als Menge von Bestandteilen statt als einzelnen Textstrom. Dazu gehören Hauptdokument und optionale Kommentare, Kopfzeilen, Fußzeilen, Fußnoten und Endnoten. Präsentationspakete können ebenfalls Notizen enthalten.
Die defensive Schlussfolgerung ist eng begrenzt: Der Ausdruck "Dokumenttext" kann mehrere Paketbestandteile meinen, und ein Verarbeitungsprodukt muss angeben, welche es liest. Die Standards beschreiben Dokumentstruktur, kein AI-Sicherheitsvertrauen. XML-Bearbeitung, Inhaltsplatzierung und Verschleierungstechniken werden bewusst nicht dargestellt.
Beispiel: Unternehmensweite Dokumentzusammenfassung
Eine Person bittet einen Unternehmensassistenten, ein gemeinsam bearbeitetes Lieferantendokument zusammenzufassen und vereinbarte nächste Schritte zu nennen.
Der freigegebene Parser liefert Haupttext und einen unterstützten Review-Bestandteil. Telemetrie erhält Dateiversion, Bestandteilskennungen und Parser-Version.
Ein angreiferbeeinflusster Abschnitt verändert die vorgeschlagene Zusammenfassung und ergänzt den sachfremden Vorschlag, private Kontodaten abzurufen und extern zu versenden.
Die Anwendung findet keine Aufgabenautorisierung für privaten Abruf oder Ziel. Sie lehnt beide Vorgänge ab und hält die Zusammenfassung als prüfbaren Entwurf zurück.
Das Ereignis verbindet Quelldatei und Bestandteil, extrahierten Abschnitt, Modellkontext, Vorschlag, Policy-Version, Ablehnung und sichtbaren Entwurf.
Beeinflussung trat ein, weil dokumentabgeleitete Sprache den Vorschlag veränderte. Die Sicherheitsauswirkung blieb eingedämmt, weil geschützte Daten nie in den Kontext gelangten und keine sachfremde externe Aktion ausgeführt wurde. Der Parser versagte nicht; die Architektur behandelte seine Ausgabe korrekt als nicht vertrauenswürdige Aufgabendaten.
Offensive Review-Fragen
Eine autorisierte Dokumentprüfung sollte jede Schranke einzeln belegen und dafür synthetische Dokumente, synthetische Schutzdaten, begrenzte Rechte und umkehrbare Nebenwirkungen verwenden. Die folgenden Fragen strukturieren die Prüfung, ohne einen Ausnutzungsablauf vorzugeben.
Welche Dokumentflächen lassen sich verfassen, bearbeiten oder kommentieren, durch welche Identität und mit welchem Review-Schritt dazwischen?
Welche Aufgabe, Automatisierung, Connector-Synchronisation oder Indexierung löst die Verarbeitung aus, und wie vorhersehbar ist das?
Welcher Parser in welcher Version läuft, und welche Bestandteile, Metadatenfelder, Annotationen und Notizen liefert er in dieser Konfiguration?
Welcher kontrollierte Inhalt übersteht Konvertierung, OCR, Normalisierung, Kürzung und Chunking, und in welcher Darstellung?
Was erreicht den Modellkontext genau, ist es mit Quelle, Bestandteil und Principal gekennzeichnet, und wie konkurriert es mit der echten Aufgabe?
Welche Zusammenfassungen, Caches, Indexeinträge oder Embeddings bleiben bestehen, und entfernt das Löschen der Quelle sie wirklich?
Welche Tools, Daten, Empfänger und Schreibpfade werden erreichbar, sobald ein Plan beeinflusst ist?
Welche deterministische Policy verweigert den Pfad, und kann Telemetrie Extraktion, Aufnahme, Einfluss, Entscheidung und Auswirkung trennen?
Kollaborative und geteilte Dokumente
Ein geteiltes Dokument hat selten genau einen dauerhaften Autor. Beschäftigte, Gäste, externe Mitarbeitende, Automatisierung und synchronisierte Drittquellen können verschiedene Bereiche unter wechselnden Berechtigungen bearbeiten. Kommentare und Review-Workflows ergänzen weitere Principals, während Eigentumswechsel und Kopien Inhalte von ihrem ursprünglichen Zugriffskontext lösen können.
Ein interner Speicherort bedeutet daher kein vertrauenswürdiges Material. Zu erfassen sind, soweit unterstützt, das für Quelle oder Version verantwortliche Principal, der importierende Connector, aktuelle effektive Rechte, Freigabestatus und relevante Versionshistorie. Die Freigabe einer einzelnen Änderung durch eine interne Person darf nicht stillschweigend jeden früheren Abschnitt als AI-Anweisung bestätigen.
Autorisierung wird zum Verarbeitungszeitpunkt geprüft. Eine Dienstidentität mit Zugriff auf den gesamten Workspace darf engere Rechte der auslösenden Person nicht ersetzen. Widerruf und Eigentumsänderungen müssen Caches und Ableitungen invalidieren, die nicht mehr zur aktuellen Policy passen.
Dokument-zu-RAG-Pipelines
Werden Dokumente geparst, in Chunks zerlegt und indexiert, kann eine einmalige Dateiexposition persistent werden und Personen erreichen, die den ursprünglichen Upload nie sahen. Provenienz und Zugriffsrichtlinie auf Dokumentebene müssen Chunking, Embedding, Indexierung, Retrieval und Kontextaufbau überstehen. Verschwinden ACLs des Elterndokuments bei abgeleiteten Chunks, besteht bereits vor Prompt-Beeinflussung ein Autorisierungsfehler.
Der Artikel zu RAG Prompt Injection behandelt Retrieval-Erreichbarkeit, Security Trimming, Mandantenisolation, Indexgenerationen und Bereinigung abgeleiteter Artefakte im Detail. An dieser Grenze liefert der Dokumentartikel genaue Herkunft bis auf Bestandteilebene. Die RAG-Schicht muss sie bewahren, statt jeden Abschnitt zu anonymem Korpustext zu verflachen.
Dokument-Prompt-Injection in Agents
Ein reiner Leseassistent begrenzt direkte Folgen. Ein Produktivitäts-, Coding- oder Workflow-Agent kann zusätzlich Datensätze abrufen, Systeme aktualisieren, E-Mails entwerfen oder senden, Tickets anlegen, Dateien schreiben oder externe Dienste aufrufen. Dokumenteinfluss erreicht dann Planung und Tool-Auswahl, schafft aber weiterhin keine Autorität.
Wo praktikabel kommen aufgabenbezogene, kurzlebige Fähigkeiten zum Einsatz. Lese- und Zusammenfassungsrechte bleiben von Schreib- und Senderechten getrennt. Menschliche Freigabe kann ausgewählte folgenschwere Aktionen stützen, wenn sie an die exakte unveränderliche Aktion gebunden ist und bei Änderungen verfällt.
Potenzielle Auswirkungen
Zusammenfassung, Klassifikation, Extraktionsergebnis oder Empfehlung verändert sich wesentlich.
Dokumentabgeleitete Signale lenken Priorisierung, Routing, Review oder Entscheidung um.
Ein beeinflusster Vorschlag verlangt Daten außerhalb von Dokumentaufgabe oder Bedarf der Person.
Sensible modellsichtbare Daten erscheinen in Antwort, Entwurf, Log oder externem Ziel.
Datensätze, Tickets, Dateien oder Zustände ändern sich ohne gültige Autorisierung.
Beeinflusster Inhalt erreicht E-Mail, Messaging, Web oder ein anderes Ziel.
Zusammenfassungen, Caches, RAG-Chunks oder Memory tragen Einfluss in spätere Sitzungen.
Geteilte Verarbeitung oder fehlerhafte Autorisierung überschreitet eine Grenze.
Jede Folge hängt von der Architektur ab. Schweregrad bestimmen tatsächlich offengelegte Daten, ausgeführte Aktion, erreichtes Ziel und betroffenes Principal, nicht die Auffälligkeit des anweisungsartigen Dokumentabschnitts.
Erkennung und Telemetrie
- 01Quelle
Datei-ID, Version, Hash, Uploader oder Connector, Eigentümer, Mandant, Workspace und effektive Berechtigungen.
- 02Verarbeitung
Erkannter Typ, Parser- oder Konverter-Version, ausgewählte Bestandteilsklassen, Sandbox-Ergebnis und Transformationsmanifest.
- 03Extrahierte Abschnitte
Stabile Bestandteil- und Elementkennungen, Seite oder Abschnitt, soweit sinnvoll, und modellsichtbare Darstellung.
- 04Probabilistische Signale
Anweisungsartige Sprache, ungewöhnliche Sichtbarkeitsunterschiede, unerwartete Bestandteile, Provenienzänderungen und Task Drift.
- 05Vorschlag
Modellausgabe, vorgeschlagenes Retrieval oder Aktion, Änderungen der Tool-Kette und Quellenattribution.
- 06Entscheidung und Effekt
Policy-Version, Autorisierungsentscheidung, exakte Parameter, Ziel und ausgeführte Nebenwirkung.
Unerwartete Folge-Tools, externe Ziele, Abschnitte mit schwacher Provenienz und Abweichungen zwischen Aufgabe und Planung sind nützliche Signale, aber keine Beweise. Harte Evidenz stammt aus Dateihistorie, Autorisierungsentscheidungen und Aktionsdaten. Korrelation belegt Abfolge und Kontext, selten interne Modellkausalität.
Extrahierter Text und Modellkontext können vertrauliche Informationen enthalten. Telemetrie braucht Zweckbindung, Zugriffskontrollen, Aufbewahrungsgrenzen und Schwärzung, muss aber genügend Evidenz für Rekonstruktion erhalten.
Prävention und sichere Architektur
- 01Quellprovenienz feststellen
Schreibende, Uploader, Connector, Eigentum, Workspace und Version erfassen, ohne dokumenteigene Behauptungen zu vertrauen.
- 02Validieren und getrennt scannen
Datei- und Inhaltstyp prüfen, Malware scannen und anerkennen, dass beides semantische Prompt Injection nicht zuverlässig erkennt.
- 03Verarbeitung isolieren
Parser und Konverter angemessen in Sandbox oder Isolation betreiben, um klassische Dateiverarbeitungsrisiken einzudämmen.
- 04Nötige Bestandteile erlauben
Festlegen, welche Haupt-, Review-, Notiz-, Eigenschafts- und Objektklassen die Aufgabe braucht, statt standardmäßig alles zu extrahieren.
- 05Herkunft auf Bestandteilebene erhalten
Quelle, Bestandteil, Transformation und Zugriffslabel in jeden Modellabschnitt und jede Ableitung tragen.
- 06Kontext minimieren
Nur für die Aufgabe nötigen Dokumentinhalt und sensible Anwendungsdaten bereitstellen.
- 07Vor Sichtbarkeit autorisieren
Repository- und RAG-Berechtigungen anwenden, bevor geschützter Inhalt den Modellkontext erreicht.
- 08Vorschlag und Ausführung trennen
Modellausgabe als nicht vertrauenswürdigen Vorschlag behandeln und jede sensible Aktion unabhängig autorisieren.
- 09Fähigkeiten und Egress begrenzen
Geringste Rechte, Aufgabenumfang, Zielrichtlinie, ausgewählte gebundene Freigaben und beobachtbare Ausführung nutzen.
- Dokument
- Extraktor
- LLM-Agent
- Privilegierte Aktion
Extrahierter Inhalt fließt direkt in einen breit befähigten Agenten.
- Dokument + Provenienz
- Isoliertes Parsing / Extraktionsrichtlinie
- Labels auf Bestandteilebene
- Modellkontext
- LLM-Vorschlag
- Policy / Autorisierung
- Beschränkte Aktion
Darstellung, Autorität und Ausführung bleiben im gesamten Workflow getrennt.
Der Abwehr-Hub ordnet diese Kontrollen in das breitere Modell der Seite für Provenienz, Informationsfluss, geringste Rechte, Aktionskontrolle, Monitoring und Wiederherstellung ein.
Incident Response
Checkliste für Dokument-Injection
- Originaldokument, exakte Version und kryptografischen Hash sichern.
- Quelle, Uploader, Eigentümer, Mandant, Workspace, Freigabestatus, Berechtigungen und Versionshistorie erhalten.
- Versionen und Konfiguration von Parser, Renderer, OCR und Konverter dokumentieren.
- Exakte extrahierte und modellsichtbare Darstellung mit Bestandteil-, Element-, Seiten- oder Abschnittskennung sichern.
- Beteiligte Abschnitte und abgeleitete Chunks bestimmen, ohne wiederverwendbaren Payload-Text zu veröffentlichen.
- Alle Personen, Workflows und Mandanten ermitteln, die die betroffene Version verarbeiteten.
- Daraus erzeugte Zusammenfassungen, Caches, RAG-Chunks, Indexeinträge, Tickets, Entwürfe und Memory finden.
- Beobachtete Modellbeeinflussung von tatsächlich ausgeführten Effekten und Datenoffenlegung trennen.
- Quelle und Ableitungen unter Erhalt der Evidenz isolieren und nötigenfalls aus bekannt gutem Material neu aufbauen.
- Zugangsdaten nur widerrufen oder rotieren, wenn Evidenz Offenlegung oder Missbrauch stützt.
Kontrollierte defensive Tests
Verwendet werden synthetische Dokumente, Identitäten, Repositories und Testmandanten. Variiert werden unterstützter Dokumenttyp, Parser und Version, extrahierte Bestandteilsklassen, Mitarbeitende, Konvertierungspfad, Berechtigungszustand und verfügbare Fähigkeiten. Gewöhnliche und sekundäre Bestandteile werden geprüft, ohne Verschleierungsmethoden, wiederverwendbare Prompt-Texte oder Verfahren zur Payload-Erzeugung zu veröffentlichen.
Das Lab zu Prompt Injection über Dokumente / PDF übt die zugrunde liegenden Vertrauensentscheidungen an fiktiven Dokumenten: Speicherort, Extraktion und Dokumentangaben gegenüber Provenienz und Anwendungsdatensätzen.
| Metrik | Beantwortete Frage |
|---|---|
| Processing Reachability Rate | Wie oft erreicht das kontrollierte Dokument den vorgesehenen Verarbeitungsworkflow? |
| Model-Visibility Rate nach Bestandteil | Wie oft gelangt jede getestete Bestandteilsklasse in den exakten Modellkontext? |
| Injection Influence Rate | Wie oft verändert sichtbarer synthetischer Inhalt Antwort, Klassifikation, Plan oder Vorschlag? |
| Policy Bypass Rate | Wie oft passiert ein verbotener beeinflusster Pfad die Anwendungspolitik? |
| Unauthorized Action Rate | Wie oft wird eine unzulässige Nebenwirkung ausgeführt? |
| Data Disclosure Success Rate | Wie oft erreichen synthetische geschützte Daten eine verbotene Ausgabe oder ein Ziel? |
| Detection Recall | Wie viele bekannte synthetische Fälle erzeugen das erwartete Signal? |
| False-Positive Rate | Wie viele harmlose Dokumente werden falsch markiert? |
| Containment Rate | Wie oft wird Einfluss an unbefugter Auswirkung gehindert? |
Die Metriken dürfen nicht verschmolzen werden. Hohe Sichtbarkeit bei geringem Einfluss beschreibt ein anderes Kontrollergebnis als hoher Einfluss ohne Policy-Umgehung. Die Trennung zeigt, ob Extraktionsrichtlinie, Erkennung, Autorisierung oder Eindämmung verbessert werden muss.
Häufige Implementierungsfehler
Wiederkehrende Fehler in Dokument-Workflows
- Annehmen, eine schadsoftwarefreie Datei sei vor semantischer Prompt Injection sicher.
- Gesamten Text extrahieren, ohne die beitragenden Dokumentbestandteile zu kennen.
- Haupttext, Kommentare, Notizen und Ableitungen zusammenführen und Provenienz verlieren.
- Internen Speicher, vertrauenswürdigen Parser oder gültige Signatur als Anweisungsautorität behandeln.
- Annehmen, Parsing, Konvertierung, OCR oder Zusammenfassung bereinige semantische Anweisungen.
- Dokumenttext Ziele, Berechtigungen oder Tool-Umfang wählen lassen.
- Retrieval mit einer Dienstidentität ausführen, deren Rechte weiter als die der auslösenden Person sind.
- Lese- und Zusammenfassungsrechte standardmäßig mit Schreib- und Senderechten verbinden.
- Originaldatei löschen, aber Chunks, Caches, Zusammenfassungen oder Memory bestehen lassen.
- Keine Verbindung von Quellabschnitt und Modellvorschlag zu Policy-Entscheidung und Aktion protokollieren.
Dokument-Prompt-Injection und verwandte Klassen
| Klasse | Primärer Mechanismus | Abgrenzende Frage |
|---|---|---|
| Dokument-Prompt-Injection | Dokumentabgeleitete Sprache beeinflusst Modellverständnis, Planung oder Verhalten | Welcher Dateibestandteil wurde modellsichtbar und konnte eine geschützte Grenze beeinflussen? |
| RAG Prompt Injection | Abgerufener Korpusinhalt gelangt für eine spätere Anfrage in den Kontext | War der Inhalt für dieses Principal erreichbar, zulässig, abgerufen und zusammengesetzt? |
| PDF Prompt Injection | Dokumentuntertyp mit besonderen Darstellungs- und Extraktionseigenschaften | Welche PDF-spezifische Darstellung erhielten Mensch, Parser und Modell? |
| Dokument-Malware oder Makros | Ausführbarer Code oder aktiver Inhalt greift eine Laufzeit an | Wurde Code ausgeführt, statt ein Modell sprachlich zu beeinflussen? |
| Daten- oder Wissensvergiftung | Gespeicherte Informationen werden für falsche oder verzerrte Ausgaben verändert | Wurde Wissensintegrität auch ohne anweisungsartigen Inhalt beschädigt? |
| Direkte Prompt Injection | Konkurrierende Anweisungen kommen über den primären Nutzereingabekanal | Hat der Nutzer den Inhalt direkt an die Modelloberfläche geliefert? |
Klassen können gemeinsam auftreten, ohne Synonyme zu werden. Eine bösartige Datei kann Malware, falsche Aussagen und anweisungsartige Sprache enthalten, während spätere RAG-Ingestion Persistenz hinzufügt. Jeder Befund braucht eigene Evidenz und Kontrollen. Der Artikel PDF Prompt Injection behandelt die besondere Darstellungs- und Extraktionsfläche dieses Formats.
Standards und Forschungskontext
Geprüfte Einordnungen und Dokumentreferenzen
- OWASP GenAI Security Project
- LLM01:2026 Prompt Injection
- NIST
- NIST AI 100-2e2025 Terminologie, NIST-Glossar: indirect prompt injection
- Dokumentstandards
- ECMA-376 Office Open XML, ISO/IEC 29500 Kontext, Microsoft-Dokumentation zur WordprocessingML-Struktur
- Forschung
- Greshake et al. 2023
OWASP LLM01:2026 beschreibt indirekte Prompt Injection über externe Quellen wie Dateien und behandelt abgerufene Dokumente und Memory als einen einzigen Token-Strom ohne erzwungene Vertrauensgrenze, sodass Retrieval keine Minderungsgrenze für Prompt Injection ist. NIST AI 100-2e2025 und das NIST-Glossar beschreiben indirekte Prompt Injection über die Kontrolle einer Ressource statt über die primäre Nutzereingabe. Diese Quellen stützen die Angriffsklasse, nicht die Behauptung, jedes verarbeitete Dokument sei bösartig.
Microsofts Leitlinien behandeln Dokumente und andere externe Inhalte als nicht vertrauenswürdige Eingaben und empfehlen Defense in Depth rund um Inhaltskennzeichnung, Überwachung von Plan und Tool-Kette, Informationsfluss, geringste Rechte, Policy und ausgewählte menschliche Freigabe. Die Leitlinie Input, Context, and Retrieval Hygiene hält ausdrücklich fest, dass Prompts, Dokumente, abgerufene Chunks, Tool-Ergebnisse und Schreibvorgänge ins Memory als nicht vertrauenswürdige Eingaben gelten und sicheres Retrieval Quellenprovenienz, berechtigungsbewusste Indexierung sowie Validierung bei jedem Lese- und Schreibvorgang verlangt. Das betrifft extrahierte Dokumentbestandteile ebenso wie die daraus abgeleiteten Zusammenfassungen, Caches und Indexeinträge. ECMA-376 und Microsofts Open-XML-Dokumentation dienen nur als faktische Quellen zu Paket- und Bestandteilstruktur. Sie sind keine AI-Sicherheitsstandards und weisen kein Vertrauen zu.
Greshake et al. liefert breiteren Forschungskontext zu indirekter Prompt Injection gegen LLM-integrierte Anwendungen. Es wird keine CWE- oder CAPEC-Zuordnung behauptet, und keine Quelle gilt als universelle Präventionsgarantie.
Häufige Fragen
Ist ein schadsoftwarefreies Dokument sicher für einen AI-Assistenten?
Nein. Malware-Scanning behandelt bekannten bösartigen Code und Dateiartefakte, nicht natürlichsprachlichen Modelleinfluss. Beide Kontrollen dienen unterschiedlichen Risiken.
Können Kommentare oder Notizen modellsichtbar werden?
Ja, wenn Parser, Connector oder Konverter des Produkts sie einbezieht. Viele Umsetzungen lassen sie aus. Zu prüfen sind konkrete Formate, Bestandteile und Konfiguration.
Macht eine digitale Signatur Dokumentinhalt zu vertrauenswürdigen Anweisungen?
Nein. Eine Signatur kann bestimmte Integritäts- oder Unterzeichnereigenschaften stützen. Sie verleiht dem Text keine Befugnis, einen AI-Workflow zu steuern.
Ist verborgener Inhalt für Dokument-Prompt-Injection nötig?
Nein. Deutlich sichtbarer gewöhnlicher Text kann nicht vertrauenswürdig bleiben und ein Modell beeinflussen. Das Sicherheitsproblem betrifft Autorität und Anwendungskontrolle, nicht Verschleierung.
Warum kann das Modell Text sehen, den eine Person nicht bemerkt?
Der Parser kann sekundäre Bestandteile einbeziehen, Tabellen normalisieren, OCR anwenden oder Inhalt anders als die Anzeige zusammenführen. Tests brauchen alle drei Sichten.
Entfernt die Umwandlung in Klartext Prompt Injection?
Nein. Konvertierung ändert die Darstellung und kann aktive Dateirisiken reduzieren, aber anweisungsartige semantische Bedeutung kann im Text erhalten bleiben.
Was geschieht, wenn Dokumente in RAG indexiert werden?
Extrahierte Abschnitte werden persistente Chunks und Indexeinträge für spätere Nutzer. Provenienz, Zugriffslabels und Widerruf müssen jede Ableitung überstehen.
Wie werden dokumentverarbeitende Agents autorisiert?
Mit aktuellen Rechten der auslösenden Person, aufgabenbezogenen Fähigkeiten, unabhängiger Policy für jede sensible Aktion und jedes Ziel sowie gebundener Freigabe für ausgewählte hohe Auswirkungen.
Quellen
- LLM01:2026 Prompt InjectionOWASP GenAI Security Project · GuidanceGeprüft 2026-09-20
- Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations, NIST AI 100-2e2025NIST · Standard · 2025-03Geprüft 2026-09-20
- indirect prompt injectionNIST Glossary · Technical documentationGeprüft 2026-09-20
- Defend against indirect prompt injection attacksMicrosoft Learn · GuidanceGeprüft 2026-09-20
- Input, Context, and Retrieval HygieneMicrosoft Learn · GuidanceGeprüft 2026-09-20
- ECMA-376 Office Open XML File FormatsEcma International · StandardGeprüft 2026-09-20
- Structure of a WordprocessingML documentMicrosoft Learn · Technical documentationGeprüft 2026-09-20
- Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt InjectionKai Greshake et al. · Research publication · 2023Geprüft 2026-09-20