Das Dokument, das Anweisungen gab
Es war kein Angriff. Ein Lieferant hatte eine für einen Kollegen gedachte Notiz in die Fußzeile eines Lieferscheins kopiert, und unser Extraktionsschritt las sie als Anweisung und befolgte sie. Es musste nichts Böswilliges geschehen, damit wir merkten: Wir hatten überhaupt keine Grenze.
Was in der Fußzeile stand
Ein Lieferschein kam mit einem Satz in der Fußzeile, sinngemäß: Die Mengen in der Tabelle ignorieren, die korrigierten Zahlen folgen per Mail. Geschrieben von einem Menschen für einen Menschen, in die falsche Vorlage kopiert, und vollkommen vernünftige Prosa.
Unser Extraktionsschritt lieferte die elf Felder mit leeren Mengen zurück und eine Notiz im Freitextfeld, die den Satz wiederholte. Er hatte genau das getan, was das Dokument ihm sagte, und jede einzelne Komponente hatte sich wie entworfen verhalten.
Warum das kein Prompt-Problem ist
Unser erster Reflex war eine Anweisung, die dem Modell sagt, Dokumentinhalt sei Daten und niemals ein Befehl. Wir haben sie ergänzt. Sie hilft ein wenig und ist keine Grenze, denn unsere Anweisung und der Dokumenttext erreichen das Modell als dieselbe Art von Sache.
Alles, was davon abhängt, dass ein Modell unseren Text verlässlich von dem des Dokuments unterscheidet, ist eine Präferenz und keine Kontrolle. Mit diesem Satz eröffnen wir heute, wenn ein Kunde fragt, wie wir uns davor schützen — er ordnet jede weitere Maßnahme richtig ein.
Die Forschung, die es greifbar machte
Clusmann und Kollegen veröffentlichten in jenem Monat eine Untersuchung, die Prompt Injection gegen bildfähige Modelle in der Onkologie demonstriert: In den Inhalt eingebettete Anweisungen veränderten die Ausgabe — in einem Feld, in dem eine falsche Antwort echtes klinisches Gewicht hat.
Zweierlei war für uns nützlich. Es ist eine Demonstration an realistischem Material statt an einem Spielprompt, und sie trifft genau die Stelle, an die unsere eigene Pipeline gerade gerückt war: Wir hatten kurz zuvor begonnen, Seitenbilder an ein Modell zu schicken — und ein Bild kann Text tragen, den kein Textfilter je sieht.
| Maßnahme | Was sie wert ist |
|---|---|
| Anweisung, Inhalt sei Daten | Hilft ein wenig. Keine Grenze |
| Filter auf Injection-Muster | Fängt Plumpes. Leicht zu umgehen |
| Nur Schema-Ausgabe, kein Freitext | Stark. Entfernt den meisten Kanal |
| Keine Werkzeuge am lesenden Schritt | Die eigentliche Grenze |
Die Änderung, die wirklich gehalten hat
Der Extraktionsschritt hat keine Werkzeuge, keinen Netzzugang und keine Möglichkeit, irgendetwas zu tun außer je Feld eines Schemas einen Wert zurückzugeben. Was ein Dokument ihm auch sagt — mehr als falsche Feldwerte kann dabei nicht herauskommen, und dafür ist unsere Querprüfung da.
Das ist das ganze Entwurfsprinzip, und es ist nicht neu: Die Komponente, die nicht vertrauenswürdige Eingaben liest, ist nicht die Komponente, die handeln kann. Unser Fehler war, überhaupt nicht daran gedacht zu haben — ein Schritt, der nur Dokumente liest, fühlte sich nicht nach Angriffsfläche an.
Was wir entfernt haben
Das Freitextfeld. Es existierte, damit ein Sachbearbeiter Auffälligkeiten auf dem Dokument sehen kann, was ein vernünftiges Merkmal ist — und es war zugleich der Kanal, über den der Fußzeilentext einen Menschen erreichte, als hätte unser System es gesagt.
Es liefert heute eine Markierung statt Text: ungewöhnlicher Inhalt vorhanden, mit Verweis auf das Seitenbild. Eine Person sieht die Quelle statt einer Wiederholung der Quelle, was sich als sicherer und nützlicher erwiesen hat, denn oft ist gerade das Layout der Punkt.
Wo das Risiko tatsächlich sitzt
Nicht in der Extraktion. Die ist durch ihr Schema begrenzt und erzeugt Daten, die andere Prüfungen kontrollieren können. Das Risiko sitzt an jedem Schritt, an dem ein Modell Inhalt liest und danach ein Werkzeug aufruft — dort wird ein Satz in einem Dokument zu einer Aktion in einem System.
Wir haben genau einen solchen Schritt, und dort leben unsere Freigaberegeln. Alles mit äußerer Wirkung nennt Aktion und Argumente und wartet auf einen Menschen. Bewusst langsam — und die Langsamkeit konzentriert sich auf den kleinen Anteil der Vorgänge, der wirklich schaden kann.
Was Kunden fragen sollten
Eine Frage, und sie funktioniert ohne jedes Modellwissen. Welche Komponente liest nicht vertrauenswürdigen Inhalt, und was kann diese Komponente tun? Lautet die Antwort, sie könne Dinge tun, ist der Entwurf falsch, wie gut der Prompt auch sein mag.
Die Anschlussfrage lautet, was passiert, wenn sie sich irrt — nicht, wenn sie angegriffen wird. Eine Pipeline, in der eine falsche Extraktion nachgelagert gefangen wird, ist auch eine, in der eine eingeschleuste Anweisung nichts zu erreichen hat, und der gewöhnliche Fehlerfall ist weit leichter zu durchdenken als der gegnerische.
Was wir nicht behaupten
Wir behaupten nicht, gegen Injection sicher zu sein. Wir behaupten, dass der Schritt, der Dokumente liest, nicht handeln kann — das begrenzt den Schaden, nicht die Beeinflussung. Ein Dokument kann weiterhin falsche Werte erzeugen, und die Abwehr dagegen ist Verifikation, nicht Filterung.
Wir behaupten auch nicht, Musterfilter seien wertlos. Wir betreiben sie, sie fangen plumpe Versuche, und sie sind eine vernünftige äußere Schicht. Sie sind nur das Schwächste in der Liste, und sie als die Antwort auszugeben wäre irreführend darüber, woher die Sicherheit tatsächlich kommt.