Kapitel 10 — Sichere LLM-Architekturen entwerfen

Zehnter Beitrag im Kapitel-für-Kapitel-Walkthrough zu LLM Primer VII: KI-Sicherheit. Das Kapitel behandelt Architektur als primäre Sicherheitsdisziplin — denn die sicherste Konfiguration einer probabilistischen Komponente ist eine, deren Blast Radius durch Struktur begrenzt wird, nicht durch die Zurückhaltung der Komponente selbst.

Warum es dieses Kapitel gibt

Die Kapitel der Teile I–III haben die Bedrohungen und die modellseitigen Abwehren benannt. Kapitel 10 walkt die Architektur ringsum — die Isolationsgrenzen, Validierungsstufen, Policy-Engines, API-Verträge und Zero-Trust-Prinzipien, die dem System seine strukturellen Eigenschaften geben. Die Prämisse ist unverändert gegenüber früherem Sicherheits-Engineering: Kompromittierung annehmen, Schaden eindämmen, Kompromittierung lesbar machen. Neu ist, dass die einzudämmende Komponente ein natürlichsprachlich gesteuerter Orchestrator ist, dessen Anweisungen über jeden Eingabekanal kommen können. Die architektonischen Muster übertragen sich aus früheren Epochen; die Spezifika ihrer Anwendung auf LLMs sind die Arbeit dieses Kapitels.

10.1 Isolation begrenzt den Blast Radius

Eine Isolationsgrenze ist eine bewusste Naht, über die eine Komponente auf der einen Seite eine Komponente auf der anderen nicht direkt beeinflussen kann, ohne eine kontrollierte Schnittstelle zu durchlaufen. Der Sicherheitsgrund für Isolation ist, dass Kompromittierungsschaden durch das begrenzt ist, was die kompromittierte Komponente über ihre legitimen Schnittstellen erreichen konnte. Für LLM-Systeme ist die wichtigste Isolationsfrage die zwischen dem Modell und allem anderen, worauf das System Zugriff hat. Ein Modell, das in einem Prozess mit unbeschränktem Dateisystemzugriff, unbeschränktem Netzwerkzugriff und einem Shell-Ausführungs-Werkzeug ohne Allow-Liste läuft, hat einen großen Blast Radius. Ein Modell, dessen Prozess in einer Sandbox mit definiertem Syscall-Set läuft, dessen Netzwerkzugriff über einen Egress-Proxy mit Domänen-Allow-Listing geht, dessen Werkzeuge über Capability-Tokens aufgerufen werden, die der umgebende Code pro Anfrage ausstellt, hat einen viel kleineren. Das Muster erstreckt sich auf Code-Ausführung — Sandbox-Werkzeuge wie die, die OpenAI und Anthropic für ihre Code-Interpreter-Umgebungen nutzen, führen generierten Code in ephemeren gVisor- oder Firecracker-VMs aus — und aufs Browsen, wo Headless-Browser in isolierten Netzwerk-Namespaces ohne Zugriff auf interne Endpunkte laufen. Isolation ist eine Entwurfsentscheidung, die vor jedem konkreten Angriff getroffen wird, und sie ist die günstigste Sicherheitsinvestition pro Einheit Blast-Radius-Reduktion, die das Feld bietet.

10.2 Validierung ist geschichtet, und Policy ist deklarativ

Ein einzelner Validierungspunkt ist ein einzelner Ausfallpunkt. Produktive LLM-Endpunkte komponieren zwischen Client-Anfrage und Antwort typischerweise fünf Schichten. Authentifizierung prüft das Credential des Principals. Anfrage-Validierung prüft die Anfrage gegen das API-Schema — Typen, Wertebereiche, Längen, Zeichensätze. Policy-Evaluation fragt, ob der authentifizierte Principal, die validierte Anfrage und der aktuelle Systemzustand diese Handlung erlauben. Der Modellaufruf läuft mit dem System-Prompt, der validierten Nutzereingabe, der auf die Policy beschränkten Werkzeugliste und den Ausgabebeschränkungen. Output-Filterung prüft die Antwort auf Inhalte, die nicht zurückgegeben werden sollten — geleakte Secrets, verbotene Inhalte, unsichere Werkzeugaufrufe —, bevor sie gesendet wird. Policy-Logik wächst mit der Zeit und wird, wenn im Anwendungscode verstreut, zur Vereinigung vieler Bedingungen, die schwer zu inspizieren, zu testen und weiterzuentwickeln ist. Das Feld hat sich darauf konvergiert, Policy von Code zu trennen. Open Policy Agent (OPA), ein CNCF-Projekt, evaluiert Policies in Rego. AWS Cedar, 2023 veröffentlicht, ist eine fokussiertere Autorisierungssprache mit formalen Verifikationseigenschaften. Beide sind produktionsreif; die Wahl ist meist organisatorische Ausrichtung. Policies werden zu versionierten, prüfbaren Artefakten, und die effektive Sicherheits-Policy des Systems ist immer an einem Ort lesbar.

10.3 Zero Trust angewendet auf Modellaufrufe

Die API ist der Vertrag zwischen dem LLM-System und seinen Aufrufern. Sicheres API-Design ist die Disziplin, den Vertrag so zu formen, dass seine Invarianten Kontakt mit adversarialen Aufrufern überleben. Explizite Eingabeschemata — strikte Typen, Wertebereiche, allowlistete Enumerationen — kosten wenig und begrenzen das implizite Vertrauen, das die API in den Aufrufer legt. Strukturierte Fehler-Antworten, die keinen internen Zustand lecken, vermeiden die Aufklärung, die vage formulierte Fehler ermöglichen. Idempotenz-Schlüssel, Request-IDs und Versionierung geben dem System Observability über das Aufruferverhalten, ohne zusätzlichen Zustand zu erfordern. Das Zero-Trust-Modell, formuliert in Googles BeyondCorp-Paper 2014 und in NIST SP 800-207 2020 formalisiert, erweitert das Prinzip: kein Aufrufer ist qua Netzwerkstandort vertraut. Jede Anfrage authentifiziert, wird gegen explizite Policy autorisiert, gegen Gerät und Kontext bewertet und geloggt. Auf LLM-Systeme angewendet wird der Modellaufruf selbst zum Principal — eine Anfrage vom Modell an ein nachgelagertes Werkzeug authentifiziert als das Modell, trägt die Identität des Menschen, in dessen Namen das Modell operiert, und wird gegen eine Policy autorisiert, die beide Identitäten kennt. Capability-Tokens mit engem Scope und kurzer TTL sind, was das kompositorisch macht. Das Ergebnis ist, dass ein kompromittierter Prompt nicht zu voller Systemkompromittierung eskalieren kann, weil die eigenen Fähigkeiten des Modells durch Tokens begrenzt sind, die der umgebende Code für eine spezifische Anfrage ausgestellt hat.

Was Kapitel 10 vorbereitet

Struktur ohne Sichtbarkeit versagt unsichtbar. Kapitel 11 untersucht die Observability-Schicht, die architektonische Abwehr in ein Betrieb-fähiges System verwandelt — was zu loggen ist, wenn ein LLM in der Schleife steht, wie Telemetrie strukturiert werden muss, damit Echtzeit-Alerting, nachträgliche Untersuchung, Kapazitätsplanung, Compliance und kontinuierliche Evaluation aus denselben Datensätzen bedient werden. Die OpenTelemetry-GenAI-Semantik-Konventionen, die seit 2024 LLM-spezifische Spans und Attribute standardisieren, liefern das anbieterneutrale Fundament. Konkrete Implementierungen — Langfuse, Helicone, Arize Phoenix, Datadog LLM Observability — sitzen darauf mit unterschiedlichen Kompromissen. Kapitel 12 nimmt anschließend Identität und Zugriff auf — OAuth, mTLS, RBAC gegen ABAC, mandantenweise Isolation, Rate Limits und die Enterprise-Governance-Kontrollen, die das System in regulierten Umgebungen nutzbar machen.

Als Nächstes — Kapitel 11: Observability, Logging und Incident Response. Was mit den OpenTelemetry-GenAI-Konventionen zu loggen ist, wie Missbrauchsmuster erkannt werden und wie eine NIST-geformte Incident Response für ein System läuft, dessen Ausfälle probabilistisch sind.