Kapitel 1 — Warum KI-Sicherheit anders ist

Erster Beitrag im Kapitel-für-Kapitel-Walkthrough zu LLM Primer VII: KI-Sicherheit. Das Kapitel argumentiert, dass KI-Sicherheit nicht einfach klassische Sicherheit mit einem ML-Adjektiv ist — das Substrat hat sich verändert, und jedes folgende Kapitel folgt aus dieser Veränderung.

Warum es dieses Kapitel gibt

Drei Jahrzehnte lang ruhte Sicherheits-Engineering auf einem stabilen Fundament: Code und Daten sind verschieden, Schwachstellen sind Diskrepanzen zwischen spezifiziertem und tatsächlichem Verhalten, und Patches schließen sie. Große Sprachmodelle brechen dieses Fundament auf spezifische Weise. Das zu verteidigende Verhalten ist nicht in Quellcode kodiert, sondern in Milliarden gelernter Gewichte, ausgeführt auf Eingaben, die vertrauenswürdige Anweisungen und unvertrauenswürdige Inhalte im selben String vermischen. Die „Schwachstelle" ist oft kein Bug — es ist das Modell, das genau das tut, wofür es trainiert wurde, in einem Kontext, den die Entwicklerinnen nicht vorhergesehen haben. Es gibt keinen Patch für „das Modell war zu hilfsbereit". Es gibt nur Redesign, Nachtraining oder zusätzliche Einhausung. Dieses Kapitel benennt die strukturellen Unterschiede, die alles Folgende prägen.

In einem Satz: LLM-Sicherheit ist keine Code-Sicherheit mit neuer Angriffsliste; sie ist Verhaltenshüllen-Sicherheit angewendet auf ein probabilistisches System, dessen Verhalten in Gewichten verteilt liegt, die kein Mensch gelesen hat, und dessen „Code" und „Daten" im selben Token-Strom ankommen.

1.1 Das Substrat hat sich verändert

Klassische Anwendungssicherheit funktioniert, weil Verhalten in Code spezifiziert ist und Defekte lokalisierbar sind. SQL-Injection hat einen strukturellen Fix — parametrisierte Abfragen — weil eine syntaktische Unterscheidung zwischen Abfrage und Parameter existiert. Ein Sprachmodell hat keine solche Spezifikation. Es hat ein Trainingsziel und eine Verteilung von Gewichten, und sein Verhalten auf einer konkreten Eingabe ist emergent. Wenn ein Modell eine Formulierung verweigert und einer anderen entspricht, gibt es keine Zeile, die man ändern könnte. Die Sicherheitsfrage verschiebt sich von „steckt ein Fehler in diesem Codepfad" zu „wozu ist dieses System fähig, und unter welchen Bedingungen wird diese Fähigkeit gefährlich?" Klassische Sicherheit setzte außerdem Determinismus als Grundlinie voraus; hier ist die Grundlinie probabilistisch. Ein Sicherheitsfilter, der bei tausend Testfällen erfolgreich ist, kann beim tausendundersten scheitern, weil das Sampling einen anderen Pfad zog. Die Verteidigerin denkt in Verteilungen und Konfidenzintervallen, nicht in Beweisen der Unerreichbarkeit. Die OWASP Top 10 für LLM-Anwendungen, 2025 überarbeitet, sind ein Versuch, diese neue Schicht zu benennen — mit Prompt-Injection als LLM01 und ungebremstem Konsum als LLM10 — aber sie sind ein Stockwerk über dem bestehenden Web-Anwendungs-Stockwerk, kein Ersatz dafür.

1.2 Die Angriffsfläche weitet sich

Eine LLM-integrierte Anwendung öffnet Oberflächen, die es vorher nicht gab. Der Prompt selbst ist eine Verkettung aus Entwickleranweisungen, abgerufenem Kontext, Nutzereingabe und Werkzeugausgaben — alles als Tokens, die das Modell ohne native Vertrauensgrenzen liest. Kann der Nutzer irgendeinen Teil beeinflussen, teilt er sich den Kanal mit der Entwicklerin. Der Retrieval-Pfad ist die zweite neue Oberfläche: jedes indexierte Dokument wird zu einer indirekten Eingabe, und wer beeinflussen kann, was in den Index gelangt, kann beeinflussen, was das Modell sieht. Greshake und Kolleg:innen benannten dies 2023 als indirekte Prompt-Injection und zeigten, dass der Kanal real und schwer zu schließen war. Die Werkzeug-Grenze ist die dritte: jedes Werkzeug, das dem Modell gewährt wird, ist ein Privileg, dessen Folgen den Antworttext verlassen und reale Systeme erreichen. Die Trainings-Pipeline ist die vierte, denn jede Daten, mit der das Modell aktualisiert wird, wird Teil der Vertrauensgrenze. Das Modellartefakt ist die fünfte — große Binärdateien, deren Deserialisierung, wie CVE-2024-3568 gezeigt hat, beim Laden Code ausführen kann. Die Output-Behandlung ist die sechste, denn vom Modell generierter Inhalt, weitergereicht an nachgelagerte Komponenten, ist unvertrauenswürdige Eingabe unter anderem Namen. MITRE ATLAS katalogisiert die Taktiken und Techniken gegen diese erweiterte Fläche.

1.3 Modelle werden zu Infrastruktur

Zwischen 2012 und 2022 waren Modelle Features innerhalb von Anwendungen. Ein Empfehlungssystem, das versagte, lieferte schlechtere Empfehlungen. Große Sprachmodelle, besonders mit Werkzeugnutzung, haben dies verändert. Das Modell wird zunehmend zur Orchestrierungsschicht — es liest Dokumente, entscheidet, welches Werkzeug zu rufen ist, entwirft die Nachricht, generiert den Code, den eine andere Komponente ausführt. Es ist oft die mächtigste Komponente im System und zugleich die formbarste, angetrieben von natürlichsprachlichen Eingaben, die jeder verfassen kann. Eine klassische Datenbank hat Abfragesprachen und Zugriffskontrollen; ein LLM als Orchestrator hat keine dieser intrinsischen Beschränkungen, nur die, die die umgebende Anwendung hinzugefügt hat. Das ist mit „Infrastruktur" hier gemeint: tragende Komponenten, deren Kompromittierung sich fortpflanzt. Infrastruktur bekommt definierte SLOs, umfassendes Logging, Change Control und Incident Response. Die meisten LLM-Deployments hatten bis 2024 und 2025 diese Reife noch nicht erreicht. Der Infrastrukturrahmen reicht auch bis in die Beschaffung: wenn eine Organisation einen gemanagten LLM-Dienst in ihren Stack einbettet, werden die Modell-Update-Disziplin des Anbieters, seine Evaluations-Gates und Offenlegungspraktiken Teil des Risikoprofils der Käuferin.

Wert, das festzuhalten: Sicherheit nachträglich auf Systeme aufzupfropfen, die nicht dafür entworfen wurden, hinterlässt Nähte, die kein Patch vollständig schließt — E-Mail-Authentifizierung, Transportverschlüsselung und Prozessisolation sind alle diesen Weg gegangen. LLM-Systeme können entweder mit Sicherheit als erstklassigem Anliegen entworfen werden oder die Nähte später entdecken, öffentlich und teuer.

Was Kapitel 1 vorbereitet

Der Rest des Buches ist die Antwort auf die hier benannten strukturellen Verschiebungen. Kapitel 2 führt Bedrohungsmodellierung an LLM-Systeme angepasst ein — die STRIDE- und PASTA-Frameworks gedreht auf Assets, Angreifer und Angriffsflächen, die auf konventionellen Diagrammen nicht auftauchen. Kapitel 3 arbeitet die Datendimension über ihren vollen Lebenszyklus durch. Die Kapitel 4–6 walken das Prompt-und-Interaktions-Innere: Injection, Filterung und RAG. Die Kapitel 7–9 walken die Modellschicht. Die Kapitel 10–12 walken die Systemarchitektur ringsherum. Die Kapitel 13–15 ergänzen die regulatorische, verantwortungs-KI- und organisatorische Peripherie. Kapitel 16 walkt Fine-Tuning als eigene Sicherheitsoberfläche, und Kapitel 17 blickt auf die Bedrohungen, die sich noch bilden. Der ganze Bogen ruht auf der Prämisse, die dieses Kapitel etabliert hat: das Substrat hat sich verändert, und die Disziplin muss mit.

Als Nächstes — Kapitel 2: Bedrohungsmodellierung für LLM-Systeme. Shostacks vier Fragen, STRIDE und PASTA gegen LLM-Assets und MITRE ATLAS als Taktikkatalog für die Angreifer, die diese neue Fläche anzieht.

Möchtest du das ganze Bild? Das Buchkapitel enthält das vollständige Mapping der OWASP LLM Top 10, die erweiterte Diskussion von NIST AI 100-1 und AI 600-1 in ihrer Anwendung auf die Produktionsposition und die „In Plain English"-Sidebars, die dieser Artikel nur zusammenfasst. LLM Primer VII auf Amazon →