Lernen

Wie KI-Assistenten ausgetrickst werden — und was du tun kannst.

Keine Panikmache und keine Fachbegriff-Wand. Jeder Abschnitt kommt in zwei Tiefen — nimm die, die du willst, wechsle jederzeit. Nichts hier setzt voraus, dass du programmieren kannst.

Was lädt ein Assistent eigentlich?

Wenn du einen KI-Assistenten um etwas bittest, sieht er nicht nur deine Nachricht. Er sieht auch Anweisungen, die er vorher bekommen hat — darunter Dateien, die du installiert hast: Skills.

Ein Skill ist eine simple Textdatei. Da steht sowas drin wie „wenn der Nutzer ein PDF erwähnt, mach Folgendes." Du kannst sie im Editor aufmachen. Es gibt keinen Compiler, keine Signatur, keine App-Store-Prüfung. Du lädst sie herunter, legst sie in einen Ordner, und ab dann liest dein Assistent sie jedes Mal, wenn sie relevant sein könnte.

Das ist wirklich nützlich — so bringt man einem Assistenten den eigenen Arbeitsablauf bei. Es heißt aber auch: Wer diese Datei geschrieben hat, spricht mit deinem Assistenten, in deiner Sitzung, mit deinen Rechten.

Ein Skill ist eine Markdown-Datei mit YAML-Frontmatter, üblicherweise SKILL.md. Das Frontmatter trägt name, eine description, anhand derer die Laufzeit über Relevanz entscheidet, und oft eine allowed-tools-Liste. Der Body sind Prosa-Anweisungen, die in den Kontext des Modells injiziert werden.

Drei Eigenschaften machen daraus eine Supply Chain statt eines Konfigurationsformats:

Keine Integritätsschicht. Keine Signatur, keine Prüfsumme, keine Herausgeber-Identität. Die Datei wird vertraut, weil sie auf der Platte liegt.
Privileg auf Kontextebene. Injizierter Text ist nicht von deiner Anfrage getrennt. Er kommt als Anweisung an, nicht als Daten.
Stille Updates. Repository ziehen, Plugin synchronisieren — und die Datei, die morgen läuft, ist nicht die, die du heute gelesen hast.

allowed-tools beschränkt das Verb. Über das Objekt sagt es nichts — Read ist über einen Skill, der deine privaten Schlüssel liest, eine wahre und nutzlose Beschreibung.

Wie kann Text etwas verstecken?

Nicht jedes Zeichen in einer Textdatei hinterlässt eine Spur auf dem Bildschirm. Manche steuern Abstände oder Buchstabenformen und werden als gar nichts dargestellt — sie stehen aber trotzdem in der Datei, überleben Copy-and-Paste, und ein Programm, das die Datei liest, sieht sie einwandfrei.

Du kannst also einen völlig normal aussehenden Absatz schreiben und einen zweiten, unsichtbaren zwischen zwei Sätze schieben. Deine Augen sehen eine PDF-Hilfe. Der Assistent liest die PDF-Hilfe plus den versteckten Teil.

Es gibt Varianten davon: Zeichen aus anderen Alphabeten, die identisch aussehen (ein russisches с ist kein lateinisches c, aber man sieht es nicht), und Zeichen, die eine Zeile in einer anderen Reihenfolge anzeigen als sie tatsächlich läuft.

Unicode hat mehrere Bereiche ohne visuelle Spur, die normale Textverarbeitung überleben:

Zero-Width-Zeichen (U+200B–U+200D, U+FEFF) — als Bits benutzt, acht pro geschmuggeltem Zeichen.
Der Tags-Block (U+E0000–U+E007F) — ein vollständiges Schatten-ASCII-Alphabet mit festem Versatz, das als nichts dargestellt wird.
Variation Selectors (U+FE00–U+FE0F, U+E0100–U+E01EF) — je ein Byte, unsichtbar an das vorherige Zeichen gebunden, häufig ein Emoji.
Bidirektionale Overrides (U+202A–U+202E) — ändern die Anzeigereihenfolge, ohne zu ändern, was ausgeführt wird. Veröffentlicht als Trojan Source.
Confusables — Homoglyphen aus gemischten Schriften, die sowohl einen Leser als auch eine wörtliche Sperrliste aushebeln.

Die Gegenmaßnahme ist nicht Erkennung allein, sondern Rückgewinnung: den Träger zurück in Text dekodieren und dem Prüfenden den Satz zeigen. Ein Befund „1.000 unsichtbare Codepoints" ist eine Kuriosität; einer, der ausgibt, was sie buchstabieren, ist ein Argument.

Was kann tatsächlich schiefgehen?

Der versteckte Text ist eine Anweisung, und der Assistent behandelt Anweisungen als Anweisungen. Die realistisch schlechten Ausgänge sind ganz gewöhnliche:

Etwas wird gelesen, das nicht gelesen werden sollte. Passwortdateien, Zugangstoken, Browser-Sitzungen.
Etwas verlässt deine Maschine. Oft nicht als offensichtlicher Upload — ein Bild-Link reicht, denn ein Bild anzuzeigen heißt, eine URL abzurufen, und die Daten können in dieser URL mitreisen.
Etwas passiert still. Der versteckte Text kann den Assistenten bitten, nicht zu erwähnen, was er getan hat.

Nichts davon braucht einen raffinierten Exploit oder einen Fehler in der Software. Es braucht nur, dass du eine Datei installierst, die niemand geprüft hat.

Das ist indirekte Prompt Injection: Der Payload kommt über Inhalte an, die das Modell konsumiert, nicht über den Nutzer-Turn. Das Interessante ist nicht die Anweisung, sondern der Abflusskanal.

Markdown-Bild-Beacons. ![x](https://host/p?d=SECRET) wird vom Client beim Rendern abgerufen. Kein Tool-Aufruf, keine Rückfrage — die Daten sind schon draußen, bevor jemand die Antwort liest.
Fetch-and-Execute. Eine Pipeline, die einen Download direkt in eine Shell schiebt — die geprüfte URL und die ausgeführten Bytes sind verschiedene Objekte, und der Server bestimmt, wann sie sich unterscheiden.
DNS. Selten gefiltert, selten so genau protokolliert wie HTTP.
Persistenz. Eine geplante Aufgabe oder eine Zeile im Shell-Profil überlebt das Entfernen des Skills komplett.

Abwehrmaßnahmen, die nur Tool-Aufrufe prüfen, übersehen den ersten Fall vollständig — deshalb ist die Bild-Beacon-Regel als kritisch eingestuft.

Welchen Modellen und Anbietern kannst du trauen?

Du kannst einem Modell nicht in den Kopf schauen, und niemand kann dir ein Zertifikat ausstellen, dass eines ehrlich ist. Was du sehr wohl kontrollieren kannst, ist viel praktischer:

Wo es läuft. Ein Modell auf deiner eigenen Maschine kann deine Dateien nirgendwohin schicken, weil es kein eigenes Netz hat.
Woran es rankommt. Der meiste Schaden braucht ein Werkzeug — Dateien lesen, Befehle ausführen, URLs öffnen. Vergib das bewusst.
Ob du wechseln kannst. Software, die dich an einen Anbieter bindet, hat die Entscheidung für dich getroffen. Software, die eine Standardschnittstelle spricht, lässt dich umentscheiden.

Sei skeptisch bei jedem, der behauptet, ein Modell sei „geprüft sicher". Die ehrliche Aussage ist enger und nützlicher: Das hier kann es erreichen, und so änderst du das.

Modell-Provenienz ist ein wirklich offenes Problem. Gewichte lassen sich durch Lesen nicht sinnvoll auditieren, veröffentlichte Evaluationen sind selbst berichtet, und „safety-tuned" sagt etwas über Ablehnungsverhalten aus, nicht über Hintertüren. Behandle das Modell als nicht vertrauenswürdig und beschränke stattdessen die Grenze:

Egress ist die eigentliche Kontrolle. Lokale Inferenz entfernt den Exfiltrationskanal komplett. Wenn ein gehosteter Endpunkt sein muss: wissen welcher, und protokollieren.
Werkzeugfläche vor Modellwahl. Die vergebene Fähigkeit bestimmt den Wirkungsradius, nicht die Modellidentität. Zähl auf, was jedes Werkzeug anfassen kann.
Portable Schnittstelle. Ein OpenAI-kompatibler Endpunkt ist eine umkehrbare Festlegung; eine proprietäre Integration nicht.
Inhalts-Provenienz getrennt betrachten. Auch ein vollkommen ehrliches Modell befolgt getreu eine Anweisung, die in seinen Kontext geschmuggelt wurde. Modellvertrauen und Inhaltsvertrauen sind verschiedene Probleme — und diese Seite handelt vom zweiten.

Was solltest du konkret tun?

Fünf Gewohnheiten, sortiert danach, wie viel sie dir bringen:

Wissen, was du installiert hast. Die meisten haben nie nachgesehen. Das ist die erste Überraschung.
Alles von Fremden prüfen, bevor du es installierst — nicht durch Draufschielen, sondern mit etwas, das die Bytes liest.
Aufschreiben, was du freigegeben hast. Dann wird eine spätere Änderung sichtbar statt unsichtbar.
Ab und zu nachprüfen. Die Datei, die sich nach deiner Freigabe ändert, ist die, die es zu erwischen gilt.
Rechte eng vergeben. Wenn ein Skill nur lesen muss, braucht er keine Befehlsausführung.

Operativ bildet sich die Checkliste auf vier Befehle und einen CI-Job ab:

# was ist installiert, und trägt etwas davon Verstecktes
airlock scan --installed

# die Entscheidung als signiertes Lockfile festhalten
airlock keygen && airlock lock ~/.claude/skills

# durchsetzen — Exit 1 bei jeder Drift
airlock verify ~/.claude/skills

Der Verifikationsschritt ist der entscheidende, denn ein Scan ist eine Momentaufnahme und Skills aktualisieren sich still. Bytes festnageln, verify in die CI, und eine Änderung kommt nicht in den Hauptbranch, ohne dass jemand sie sieht.

Zwei Fehlermodi, die man verinnerlichen sollte: Ein pass heißt, dass keine Regel angeschlagen hat — nicht, dass die Datei sicher ist. Und ein heuristischer Befund heißt „schau hin", nicht „Urteil". Jedes Werkzeug, das diese beiden verwischt, erzieht dich dazu, es zu ignorieren.

Auf der eigenen Maschine ausprobieren

Drei Befehle, kein Konto, nichts wird hochgeladen. Es liest Bytes und beendet sich.

AIRLOCK holen Skill-Index durchsuchen

Etwas hier unklar?

Frag im Forum. Einsteigerfragen sind genau der Sinn davon — es gibt keine, die zu einfach wäre.

Zum Forum