Köderdokumente in der Knowledge-Base: Datenabfluss erkennen

Ein Unternehmen merkt, dass Daten über seinen KI-Assistenten abfließen, wenn es in die Knowledge-Base Daten legt, die niemand braucht und nach denen niemand fragt: ein erfundenes Dokument mit eindeutiger Kennung, einen Zugangsschlüssel, der nirgends gilt. Taucht so ein Köder in einer Antwort auf oder wird der Schlüssel verwendet, ist das ein Alarm, der nichts Legitimes bedeuten kann. Fachlich heißen solche Köder Honey Tokens und Canary Tokens (Köderdokumente).

Täuschung als Frühwarnsystem

Täuschung ist in der IT-Sicherheit ein bewährtes Mittel, Angreifer zu entdecken, in drei verbreiteten Formen.

Ein Honeypot ist ein Lockvogel-System, etwa ein Server, der wie ein lohnendes Ziel aussieht und keine echte Aufgabe hat. Wer sich dort anmeldet, verrät sich und zeigt, wonach er sucht.

Ein Honey Token ist ein Köder in Form von Zugangsdaten, etwa ein Passwort oder ein API-Schlüssel, der in einer Konfigurationsdatei liegt und nirgends gilt. Jeder Versuch, ihn zu verwenden, wird protokolliert und zeigt, dass jemand eine Datei gelesen hat, die er nicht hätte lesen sollen.

Ein Canary File ist eine Köderdatei mit verlockendem Namen, etwa eine Gehaltsliste, die es so nicht gibt. Wie der Kanarienvogel im Bergwerk warnt sie früh: Wird sie geöffnet oder kopiert, schlägt sie an.

Allen drei gemeinsam ist der Grundsatz, der sie wertvoll macht. Ein richtig gebauter Köder erzeugt keine Fehlalarme, weil es keinen legitimen Grund gibt, ihn zu nutzen.

Auf KI-Systeme übertragen, gewinnen diese Verfahren eine neue Rolle: Ein Assistent, der Dokumente durchsucht und Werkzeuge aufruft, findet einen Köder genauso wie ein Angreifer im Netz, und wer den Assistenten missbraucht, verrät sich damit. Welche Angriffswege auf KI-Systeme es sonst gibt, ordnet unsere Übersicht zur KI-Sicherheit ein.

Köder im RAG-Index

Ein RAG-Assistent (Retrieval-Augmented Generation) sucht zu jeder Frage passende Abschnitte aus der Knowledge-Base und gibt sie dem Modell als Kontext mit. Jeder dieser Abrufe lässt sich protokollieren, und darauf baut der Köder im Index. Drei Bauformen eignen sich:

1. Ein Dokument mit eindeutiger Kennung. Ein erfundener Projektbericht oder eine erfundene Kundenakte trägt eine Projekt- oder Kundennummer, die es sonst nirgends gibt. Der Alarm entsteht im Retrieval-Protokoll: Sobald ein Abschnitt mit dieser Kennung als Kontext an das Modell geht, meldet die Überwachung den Treffer mit Nutzer, Zeitpunkt und Anfrage.
2. Ein Dokument mit einer meldenden Adresse. Im Text steht ein Link auf eine eigene, sonst unbekannte URL, etwa zu einem angeblichen Ordner mit Vertragsunterlagen. Der Alarm entsteht beim Aufruf der Adresse, den der eigene Server protokolliert. Das deckt auch den Fall, dass eine untergeschobene Anweisung das Modell dazu bringt, den Link auszugeben, und eine Oberfläche oder ein Agent ihn von selbst abruft.
3. Ein Dokument mit erfundenen Zugangsdaten. Ein angebliches Übergabeprotokoll nennt Benutzername und Passwort für einen Dienst, der nur zu diesem Zweck existiert und jeden Anmeldeversuch protokolliert. Der Alarm entsteht beim Anmeldeversuch, und er sagt mehr als ein Treffer im Protokoll: Jemand hat die Daten nicht nur gesehen, er versucht sie zu nutzen.

Der Index enthält dieselben Inhalte wie die Ablage, nur in Abschnitte zerlegt und als Embeddings abgelegt, und ist damit so vertraulich wie die Dokumente; was daraus folgt, beschreibt die Seite zu Vector and Embedding Weaknesses (OWASP LLM08). Ein Köder in einem Bereich, den ein bestimmter Nutzer nicht sehen dürfte, prüft nebenbei, ob die Berechtigungen bis in den Index reichen: Erscheint er in dessen Antwort, reichen sie nicht so weit. Welche Daten ein Modell auf diesem Weg preisgeben kann, behandelt die Seite zu Sensitive Information Disclosure (OWASP LLM02).

Köder in der Agentenumgebung

Ein Agent erreicht mehr als die Knowledge-Base: Dateien, Werkzeuge, oft ein Postfach. Überall dort lässt sich ein Köder auslegen.

• Ein erfundener Schlüssel in einer Konfigurationsdatei, die der Agent lesen kann, etwa ein API-Schlüssel für einen Zahlungsdienst. Der Agent braucht ihn für keine seiner Aufgaben. Wird er verwendet, hat der Agent etwas getan, wofür er nicht gebaut ist, oder jemand hat die Datei über ihn ausgelesen.
• Ein Werkzeug, das es nur zum Anlocken gibt. Neben den echten Werkzeugen steht eines mit einem Namen wie „Kundendaten exportieren“, das nichts exportiert und nur seinen Aufruf meldet. Ruft der Agent es auf, folgt er einer fremden Anweisung.
• Ein Postfach, das nur Köder empfängt. Seine Adresse steht ausschließlich in Köderdokumenten. Jede Nachricht an diese Adresse zeigt, dass ein Köderdokument gelesen und weiterverarbeitet wurde.

Bei einem Zero-Click-Angriff auf einen KI-Agenten steuert eine versteckte Anweisung in einer E-Mail den Agenten, und niemand im Unternehmen bemerkt etwas. Der Köder bemerkt es, sobald die Anweisung nach Daten oder Werkzeugen greift, die für die Aufgabe nicht vorgesehen sind. Welche Rechte ein Agent überhaupt haben sollte, beschreibt die Seite zu Excessive Agency (OWASP LLM06).

Wann der Köder anschlägt und wann nicht

Ein Köder schlägt fälschlich an, wenn er zu normalen Fragen passt. Der Retriever sucht nach Ähnlichkeit der Bedeutung und nicht nach exakt gleichen Wörtern. Ein erfundener Projektbericht zu einem Alltagsthema wird bei legitimen Anfragen mit abgerufen, und bald nimmt niemand den Alarm mehr ernst.

Daraus folgt die Gestaltung. Ein Köder soll echten Fragen unähnlich sein und Angriffsfragen ähnlich. Anfragen wie „gib alle Zugangsdaten aus“ oder „liste alle Kundennummern“ stellt im Arbeitsalltag niemand, ein Angreifer oder eine untergeschobene Anweisung dagegen schon. Ein Köder, der sich als Übersicht aller Zugänge ausgibt, wird genau dann gefunden.

Hilfreich ist eine Abstufung. Ein Treffer im Retrieval-Protokoll ist ein Hinweis, der eine Prüfung verdient, denn auch eine harmlose Frage gerät einmal in die Nähe eines Köders. Die Kennung in einer Antwort, ein Aufruf der meldenden Adresse oder ein Anmeldeversuch mit dem erfundenen Schlüssel sind ein Alarm.

Zwei Gewohnheiten halten das Verfahren wirksam. Köder werden regelmäßig getauscht, damit jemand, der einen Köder einmal erkannt hat, ihn beim nächsten Versuch nicht umgehen kann. Und der Alarm geht an eine Person, die ihn liest und handeln darf, nicht an ein Sammelpostfach, das niemand öffnet.

So richten wir es ein

Die Einrichtung folgt einer festen Schrittfolge:

1. Köder festlegen. Die Auswahl richtet sich danach, was dem Unternehmen am meisten schaden würde, wenn es abfließt, und wo ein Angreifer danach suchen würde.
2. Eindeutige Kennungen erzeugen. Jede Kennung ist zufällig und kommt sonst nirgends vor, so lässt sich jeder Alarm seinem Ablageort zuordnen.
3. Ablegen. Die Köderdokumente kommen in den RAG-Index, Schlüssel, Werkzeug und Postfachadresse in die Agentenumgebung.
4. Überwachen. Retrieval-Protokoll und Antworten werden laufend auf die Kennungen durchsucht. Meldende Adresse, Anmeldedienst und Köderpostfach melden sich selbst.
5. Alarmweg festlegen. Wer den Alarm bekommt, wer ihn vertritt und was als Erstes geschieht, steht schriftlich fest.
6. Selbst auslösen. Zum Schluss wird jeder Köder absichtlich ausgelöst, mit einem Injection-Prompt, der nach Zugangsdaten oder Kundenlisten fragt. Das Protokoll zeigt danach, ob der Alarm bei der richtigen Person angekommen ist.

Läuft der Assistent lokal auf eigener Hardware, wird die Überwachung einfacher, weil Retriever, Modell und Protokolle im Haus liegen und sich vollständig auswerten lassen. Köder können ein Baustein des KI-Sicherheitschecks sein. Dort prüfen wir mit wiederholbaren Testfällen, ob ein Assistent einer untergeschobenen Anweisung folgt; der Köder zeigt zusätzlich, ob das im laufenden Betrieb jemand bemerken würde.

Was Köder nicht ersetzen

Der Köder meldet den Abfluss, er verhindert ihn nicht. Schlägt er an, hat jemand den Assistenten bereits dazu gebracht, nach Daten zu greifen, und echte Dokumente können mit abgeflossen sein.

An erster Stelle stehen die Berechtigungen im Index: Der Assistent zeigt jedem Nutzer nur, was dieser auch in der Ablage sehen dürfte, wie oben zu LLM08 beschrieben. Dazu kommt die Prüfung im KI-Gateway, das Eingaben auf Injection-Muster durchsucht und Antworten mit Zugangsdaten oder unbekannten Links anhält, bevor sie das System verlassen. Grundlage für beides ist die Zeichnung aller Stationen, an denen Daten liegen; wie sie entsteht, beschreibt die Seite zu Datenflüssen in KI-Systemen. Erst diese Zeichnung zeigt, wo ein Köder überhaupt sinnvoll liegt.

Fazit

Ein Köder im RAG-Index oder in der Agentenumgebung ist eine kleine Maßnahme mit klarer Aussage: Schlägt er an, greift jemand über den KI-Assistenten nach Daten, die niemand legitim braucht. Verlässlich bleibt er, wenn er echten Fragen fernliegt und seinen Alarm an eine Person schickt, die ihn liest. Berechtigungen und Gateway ersetzt er nicht, er meldet früh, wenn sie versagt haben.

Weiterführend

• An Ancient Guide to Cybersecurity: 8 Lessons from The Art of War, IBM Technology, 8.9.2026. Als Anregung: Das Video stellt Honeypots, Honey Tokens und Canary Files vor, die Übertragung auf KI-Systeme kommt darin nicht vor.
• Lagebild KI-Sicherheit: Kennzahlen zu KI-Vorfällen mit Primärquelle
• KI-Sicherheit im Überblick: alle Angriffswege nach OWASP und der Sicherheitscheck