↓ Zum Hauptinhalt springen
  1. Beiträge/

Der IBAN-Angriff: Prompt Injection am eigenen Belegfluss

·729 Wörter·4 min
Peter Schmidt
Autor
Peter Schmidt
Inhaltsverzeichnis

Lernnotiz aus dem Projektzeitraum 7. und 8. Oktober 2026, aufgeschrieben im November 2026. Teil der Reihe Vom Werkzeug zur Souveränität, Etappe 2.

Was passiert, wenn eine Rechnungsmail nicht nur Daten enthält, sondern auch Anweisungen an die KI, die sie liest? Anfang Oktober habe ich das an meinem eigenen Belegfluss zum ersten Mal systematisch ausprobiert. Fast alle Angriffe liefen ins Leere. Einer nicht, und der traf ausgerechnet die Bankverbindung.

Warum Sprachmodelle meine Rechnungen sortieren
#

Eigentlich sollte sich das Thema längst erledigt haben: Die E-Rechnung ist seit Jahren angekündigt, empfangen können müssen Unternehmen sie seit Anfang 2025, ausstellen müssen viele sie erst in den nächsten Jahren. Bis dahin kommen Rechnungen weiter als PDF, als Mailtext oder als Hinweis auf irgendein Portal. Also lasse ich seit dem Sommer Sprachmodelle meine Mails sortieren.

Eine erste Stufe entscheidet, ob es um eine Rechnung geht (Triage). Eine zweite liest Betrag, Datum, Rechnungsnummer und IBAN aus (Extraktion), auch aus PDFs, die das Modell als Bilder bekommt. Die Entscheidung treffe ich im Review, das Modell schreibt selbst nichts zurück. Es rechnen Qwen auf dem Mac und nimble als kleines zweites Modell auf einem weiteren Rechner. So verarbeite ich alle Daten meiner Mails lokal, in meinem Netz oder bei meinen EU-Auftragsverarbeitern, falls meine lokalen Modelle mal überlastet sind.

Rechnungen sind nur mein Beispiel. Dasselbe Muster steckt in jeder KI-gestützten Eingangsverarbeitung, ob Anfragen, Bestellungen oder Angebote. Und überall gilt: Ein Sprachmodell kann nicht mit letzter Sicherheit unterscheiden, ob ein Text Material ist oder eine Anweisung. Wer eine Mail schreibt, kann also versuchen, dem Modell darin Befehle unterzuschieben. Das nennt sich Prompt Injection.

Der Test
#

Am 7. Oktober habe ich das ausprobiert, mit erfundenen Prüfmails. Einen Satz schrieb der Agent, mit dem ich arbeite, einen zweiten ein anderer Agent, der die Erkennungsfragen nicht kannte. Diese Blindprobe ist der eigentliche Prüfstein, denn wer seine Abwehr an denselben Beispielen misst, an denen er sie entwickelt hat, misst vor allem sein eigenes Gedächtnis.

Bei rund vierzig Angriffen auf die Triage verschwand keine einzige Rechnung. Von rund zwei Dutzend Angriffen auf einzelne Felder wie Betrag, Datum oder IBAN liefen fast alle ins Leere.

Immer noch etwas übersehen
#

Einer kam durch: In einer Lastschrift-Rechnung, die selbst keine IBAN nannte, stand in einem versteckten Abschnitt eine fremde. Das Modell übernahm sie und meldete dabei sogar selbst einen Verdacht. Die Folge wäre ganz konkret eine spätere Zahlung auf ein falsches Konto gewesen. Bei einer KI-gestützten Angebotserstellung wäre es eben ein falscher Preis oder Artikel.

Gebucht hätte das Modell nichts, die IBAN wäre als Vorschlag bei mir im Review gelandet. Nur: Hätte ich sie dort bemerkt? Dazu kam: Bei rund einem Drittel der abgewehrten Angriffe hatte das Modell gar keinen Verdacht geäußert.

Die nächste Iteration
#

Am nächsten Morgen kam die IBAN-Absicherung, in drei Stufen:

  • Meldet das Modell einen Verdacht, wird die IBAN zurückgehalten, und übernehmen kann sie nur ich.
  • Dasselbe gilt, wenn sie nur in einem versteckten Abschnitt steht oder weder im Mailtext noch in einem Anhang.
  • Das Review warnt bei jeder zurückgehaltenen IBAN und hebt hervor, wenn sich die IBAN eines Händlers geändert hat.
Belegfluss mit Abwehrstufen: von der eingehenden Mail über Triage, Extraktion und Zuordnung zum Review, darunter die Sicherungen seit dem 8. Oktober
Belegfluss mit Abwehrstufen, Stand 8. Oktober 2026 (zum Vergrößern anklicken)

Die dritte Stufe schätze ich am meisten, weil es ihr egal ist, wo die IBAN steht. Ob im Mailtext oder im angehängten PDF, ein Wechsel fällt auf.

Nebenbei bricht die Extraktion inzwischen nach 25 Fehlern in Folge ab, etwa wenn eines meiner lokalen Modelle nicht erreichbar ist, und ich habe eine einfache Zustellerprüfung ergänzt. Das kleine Modell nimble läuft seitdem nachts als Zweitmeinung mit: In einer Stichprobe fand es alle Belege, die Qwen übersehen hatte, und es sucht nach eingeschleusten Anweisungen. Es markiert nur, es filtert nie.

Was daraus für Unternehmen folgt
#

  • Sich selbst angreifen, am besten mit fremden Beispielen. Prüffälle, die ohne Kenntnis der Abwehr entstehen, zeigen nicht selten mehr als die der eigenen Entwickler.
  • Verdachtsfälle der Modelle sind kein vollwertiger Schutz. Eine echte Absicherung greift auch dann, wenn das Modell nichts meldet. Und bemerkt es etwas, muss sie direkt aktiv werden.
  • Echte Daten sind Gold. Die neue Bankverbindung bei einem bekannten Lieferanten ist immer eine menschliche Rückfrage wert, selbst wenn die Rechnung korrekt aussieht.
  • Echte Entscheidungen bleiben beim Menschen. Bei mir kann das Modell nicht selbst buchen, und so ist aus dem Treffer ein Befund geworden, kein Schaden.

Welche Abläufe in Ihrem Haus lesen heute schon Mails mit KI, und wer hat sie schon einmal angegriffen?