Daten, Modell, System, Mensch — die vier Angriffsflächen jedes LLM
In meinen bisherigen Lernstationen habe ich einzelne Angriffe seziert: Prompt Injection, Trainingsdaten-Herkunft, das Absichern einer KI-Architektur. Dieser Raum hat etwas anderes geliefert — eine Landkarte. Er ordnet die gesamte LLM-Bedrohungslage in vier Familien, je nachdem, was der Angreifer eigentlich ins Visier nimmt: die Daten, das Modell, das umgebende System oder den Menschen davor. Diese vier Ebenen sind das beste Ordnungsraster, das mir bisher begegnet ist.
Warum eine Landkarte mehr wert ist als eine Angriffsliste
Wer LLM-Sicherheit als losen Stapel einzelner Tricks lernt, verliert schnell den Überblick — und übersieht im Audit ganze Bereiche. Eine Taxonomie nach Angriffsziel erzwingt Vollständigkeit: Bei jedem System gehe ich alle vier Ebenen durch und frage, ob sie geschützt sind. Genau das macht aus „ich kenne ein paar Angriffe" eine methodische Bewertung.
1. Datenbasierte Angriffe — das Modell als Gedächtnis
Ein LLM lernt aus riesigen Datenmengen und merkt sich dabei mehr, als uns lieb ist. Drei Angriffe zielen auf dieses Gedächtnis:
- Training Data Extraction. Mit geschickten Prompts lässt sich das Modell dazu bringen, auswendig gelernte Inhalte wörtlich auszuspucken — bis hin zu PII oder Geheimnissen, die im Trainingsmaterial steckten.
- Membership Inference. Der Angreifer hat bereits ein Datenbeispiel und will nur eine Ja/Nein-Antwort: War genau das Teil des Trainings? Schon diese Information kann Datenschutz verletzen (z. B. „war dieser Patientendatensatz im Trainingsset?").
- System Prompt Leakage (LLM07:2025). Das Modell wird überredet, seine versteckten System-Anweisungen offenzulegen — inklusive der Regeln und manchmal Schlüssel, die der Entwickler darin hinterlegt hat.
Das knüpft direkt an meinen Beitrag „Woher stammt dein KI-Modell" an: Wenn niemand die Trainingsdaten kennt, weiß auch niemand, was sich extrahieren lässt.
2. Modellbasierte Angriffe — das Modell als Beute
Hier ist nicht der Inhalt das Ziel, sondern das Modell selbst — sein geistiges Eigentum:
- Weight Extraction / Model Stealing. Über sehr viele gezielte API-Anfragen baut ein Angreifer ein Surrogat nach — ein Ersatzmodell, das das Verhalten des Originals nachahmt, ohne je dessen Gewichte gesehen zu haben. Teuer entwickeltes Know-how wird so abgeschöpft.
- Model Inversion. Aus den Ausgaben oder internen Repräsentationen eines Modells werden sensible Trainingsdaten oder Eigenschaften rekonstruiert — die Umkehrung des Lernvorgangs.
Diese Ebene ist besonders relevant für Unternehmen, die eigene Modelle als Produkt anbieten: Die API selbst wird zur Angriffsfläche auf das Firmenkapital.
3. Systembasierte Angriffe — die fehlende Grenze
Das ist die Ebene, die LLMs von klassischer Software unterscheidet. Ihr Kern: Ein LLM verarbeitet alle Eingaben als einen einzigen, zusammenhängenden Kontext — System-Anweisung, abgerufene Daten und Nutzereingabe verschmelzen im Context Window zu einem Token-Strom ohne eingebaute Sicherheitsgrenze. Vertrauenswürdiges und nicht Vertrauenswürdiges liegen ununterscheidbar nebeneinander. Daraus folgen drei Angriffe:
- Context Window Poisoning (Prompt Injection). Eingeschleuster Text — direkt in der Eingabe oder versteckt in abgerufenen Inhalten — überschreibt das beabsichtigte Verhalten. Mehr dazu in „Prompt Injection erklärt".
- Context Overflow / Unbounded Consumption (LLM10:2025). Das Context Window arbeitet wie ein FIFO-Puffer: Ist es voll, fallen die ältesten Tokens heraus — also ausgerechnet die System-Anweisungen und Schutzregeln am Anfang. Mit übergroßen Eingaben lässt sich das gezielt provozieren. Im Bezahlmodell wird daraus eine finanzielle Waffe: das Fluten teurer Anfragen ist ein Denial of Wallet.
- Memory Poisoning. Bei Chatbots mit Gesprächsverlauf schleust ein Angreifer über mehrere Runden falsche „Fakten" in die Historie, die spätere Antworten dauerhaft verfälschen — kein Einmal-Treffer, sondern eine schleichende Vergiftung des Gedächtnisses.
Warum diese fehlende Grenze überhaupt existiert, habe ich in „Die KI liest nicht deine Wörter" aufgedröselt; wie man das System darum herum absichert, in „Ein KI-System absichern heißt die Architektur absichern".
4. Nutzerbasierte Angriffe — der Mensch als Ziel
Die vierte Ebene wird gern übersehen, weil hier nicht das System angegriffen wird, sondern der Mensch davor — mit dem LLM als Verstärker:
- LLM-gestütztes Social Engineering. Modelle formulieren überzeugende, personalisierte Phishing-Texte in Sekunden und im Maßstab — die Erfolgsquote klassischer Betrugsmaschen steigt.
- Trust Exploitation / Misinformation (LLM09:2025). LLMs klingen kompetent, auch wenn sie falsch liegen. Nutzer übernehmen selbstbewusst formulierte, aber falsche oder manipulierte Aussagen — eine Vertrauensfalle.
Wie sich diese Ebenen in einem echten Vorfall verzahnen, habe ich im Fall West Tech durchgespielt — dort traf eine ausgeplauderte KI auf einen halluzinierten Befund.
Der „Secure LLM Mindset"
Die rote Linie durch alle vier Ebenen: Klassische Sicherheitsannahmen versagen. Bei normaler Software trennen wir vertrauenswürdigen Code von nicht vertrauenswürdiger Eingabe. Ein LLM kennt diese Trennung nicht — natürliche Sprache, probabilistische Verarbeitung und emergentes Verhalten erzeugen Angriffsflächen, die Firewall und WAF nicht sehen. Sicher mit LLMs zu arbeiten heißt deshalb, jede der vier Ebenen bewusst zu prüfen, statt auf gewohnte Schutzmechanismen zu vertrauen.
Mein Fazit
Was ich aus diesem Raum mitnehme, ist weniger ein neuer Angriff als ein Denkrahmen. Wenn ich künftig ein KI-System bewerte, gehe ich die vier Familien der Reihe nach durch — Daten, Modell, System, Mensch — und keine Ebene bleibt aus Versehen unbeleuchtet. Genau diese Vollständigkeit unterscheidet eine fundierte Risikoanalyse von einer Sammlung netter Tricks. Und sie ist die Grundlage dafür, wie ich KI-Sicherheit in meinen Audits angehe.