Warum KI-Sicherheit ein Architekturproblem ist

Seit einem Jahr beobachte ich, wie Sicherheitsteams über KI diskutieren, als ließe sie sich nahtlos in eine von zwei Kategorien einordnen. Entweder handelt es sich um „nur eine weitere Anwendung“, die wir mit Standardmaßnahmen der Anwendungssicherheit bewältigen können, oder um eine radikal neue Risikokategorie, die eine völlig neue Sicherheitstheorie erfordert. Da ich sowohl als Penetrationstester als auch als Softwareentwickler gearbeitet habe, bin ich der Meinung, dass beide Standpunkte die tatsächlichen Zusammenhänge verfehlen. Es ist nicht so, dass KI die Sicherheit untergräbt. KI untergräbt vielmehr eine grundlegende Annahme, auf die sich die meisten unserer Sicherheitspraktiken stillschweigend stützen, nämlich den Determinismus.

Herkömmliche Softwaresysteme sind deterministisch. Bei gleicher Eingabe und gleichem Zustand erhält man dieselbe Ausgabe. Diese Eigenschaft macht das Debugging erst möglich, verleiht Unit-Tests ihre Bedeutung und sorgt für die Zuverlässigkeit von Exploits. Wenn ich früher bei einem Penetrationstest eine Schwachstelle entdeckte, überprüfte ich als Erstes die Wiederholbarkeit. Wenn der Exploit nur in einem von zehn Fällen funktionierte, handelte es sich nicht um einen eindeutigen Befund. Der Determinismus ist es, der einen Fehler zu etwas Verwertbarem macht.

Sicherheitskontrollen beruhen auf eben dieser Stabilität. Zugriffskontrollen sind deterministisch. Die Eingabevalidierung ist deterministisch. Eine Policy-Engine wertet einen Regelsatz aus und trifft jedes Mal dieselbe Entscheidung. Selbst wenn Systeme komplex sind, führen sie dennoch eine festgelegte Logik aus.

Große Sprachmodelle verhalten sich nicht so. Sie approximieren Wahrscheinlichkeitsverteilungen über Tokens unter Berücksichtigung des Kontexts. Im Klartext: Sie leiten wahrscheinliche Fortsetzungen ab, anstatt explizite Logik auszuführen. Selbst wenn man das „Temperament“ festlegt und versucht, sie dazu zu bringen, sich „anständig zu benehmen“, arbeitet man immer noch mit einem probabilistischen Modell, das Kontext und Absicht anhand statistischer Muster interpretiert.

Dieser Unterschied klingt rein theoretisch, bis man versucht, ein darauf aufbauendes System abzusichern.

Wenn Sie ein KI-Produkt bereitstellen, stellen Sie gleichzeitig zwei Systeme bereit. Das erste ist die Anwendungsschicht: APIs, Authentifizierung, Datenbanken, Abruf-Pipelines, Tool-Wrapper, Protokollierung, Ratenbegrenzung und die gesamte übliche Infrastruktur. Dieser Teil ist nach wie vor deterministisch. Er erfordert weiterhin gehärtete Schnittstellen, strenge Schemavalidierung, fähigkeitsbasierte Zugriffskontrolle, Sandboxing und eine ordnungsgemäße Trennung von Berechtigungen. Wenn Ihr Modell beliebige Shell-Befehle auslösen kann, weil Sie dessen Ausgabe direkt an einen Unterprozess weitergeleitet haben, ist das keine „KI-Sicherheitslücke“. Das ist schlechte Technik.

Als ehemaliger Penetrationstester kann ich Ihnen sagen, dass die meisten KI-Implementierungen in der Praxis auf dieser Ebene noch immer anfällig sind. Tool-Wrapper verlassen sich zu sehr auf das Modell. Die Validierung der Ausgabe ist lückenhaft. Retrieval-Pipelines nehmen nicht vertrauenswürdige Daten ohne klare Grenzen auf. Das sind bekannte Probleme. Sie lassen sich durch diszipliniertes Engineering lösen.

Aber das ist nur die halbe Wahrheit.

Das zweite System ist die Intelligenzebene: die Interpretation der Absicht durch das Modell – seine Wahl der Werkzeuge, seine Planungsschritte und sein sich entwickelnder Kontext. Diese Ebene ist nicht in derselben Weise deterministisch wie die umgebende Anwendung. Sie führt keinen festgelegten Entscheidungsbaum aus. Sie wertet den Kontext aus und wählt Aktionen auf der Grundlage von Mustern aus, die während des Trainings erlernt wurden. Genau dort liegt die neue Angriffsfläche.

Prompt-Injection ist ein gutes Beispiel dafür. Oft wird dies so beschrieben, als handele es sich um eine neue Form der Injection-Sicherheitslücke, doch dabei wird kein Parser ausgenutzt. Vielmehr wird die Interpretation ausgenutzt. Man bricht nicht die Syntax, sondern beeinflusst, wie das Modell Anweisungen gewichtet. Man versucht, das Modell davon zu überzeugen, dass böswillige Anweisungen Vorrang vor den Systembeschränkungen haben.

Aus der Perspektive eines Angreifers unterscheidet sich dies deutlich von einer SQL-Injection. Bei einer SQL-Injection nutze ich eine vorhersehbare Grammatik und eine vorhersehbare Ausführungsumgebung aus. Bei einer Prompt-Injection untersuche ich, wie das Modell widersprüchliche Autoritäts- und Kontexterfordernisse auflöst. Ich suche nach einer Zielabweichung. Ich teste, ob das Modell „Hilfsbereitschaft“ gegenüber Richtlinien priorisiert. Ich prüfe, ob ich es durch eine Umformulierung der Aufgabe dazu bringen kann, ein Tool missbräuchlich einzusetzen. Die Schwachstelle ist kein fehlendes Escape-Zeichen. Es ist eine Verschiebung in der Argumentation.

Genau das macht die KI-Sicherheit so schwierig. Wir sind es gewohnt, nachzuweisen, dass eine Kontrollmaßnahme entweder funktioniert oder nicht. Bei der KI basieren Kontrollmaßnahmen auf einem probabilistischen Kern. Man kann den Nichtdeterminismus nicht beseitigen. Man kann ihn lediglich begrenzen.

An dieser Stelle kommt der architektonischen Disziplin eine entscheidende Rolle zu. Die Anwendungsschicht muss davon ausgehen, dass das Modell nicht vertrauenswürdig ist. Jeder Tool-Aufruf sollte anhand eines strengen Schemas validiert werden. Jede Aktion sollte unabhängig von der Empfehlung des Modells autorisiert werden. Das Modell sollte keine implizite Autorität besitzen, nur weil es eine strukturierte Antwort generiert hat. Wenn es auf eine Datenbank zugreifen möchte, sollte diese Anfrage dieselbe Kontrollschicht durchlaufen wie bei jedem anderen Dienst auch.

Gleichzeitig müssen Sie sich bewusst machen, dass Sie probabilistisches Denken nicht so „flicken“ können, wie man Code flickt. Sie können es jedoch gestalten. Man kann seinen Handlungsspielraum einschränken. Man kann Planung und Ausführung voneinander trennen, sodass keine einzelne Modellinstanz die vollständige Kontrolle über den gesamten Prozess hat. Man kann Überwachungsmodelle oder regelbasierte Validatoren hinzufügen, die risikoreiche Entscheidungen überprüfen. Man kann das Verhalten im Zeitverlauf überwachen und nach anomalen Tool-Ablaufsequenzen oder ungewöhnlichen Eskalationsmustern suchen. Aber man kann es nicht zu perfekter Vorhersehbarkeit zwingen, ohne genau die Fähigkeit zu zerstören, die man eigentlich nutzen möchte.

Deshalb halte ich die Einordnung für so wichtig. Wenn man KI lediglich als einen weiteren Microservice betrachtet, übersieht man kognitive Angriffsvektoren wie Prompt-Injection und Speichermanipulation. Wenn man das Modell als unkontrollierbare Black Box betrachtet, vernachlässigt man die sehr realen deterministischen Kontrollmechanismen, mit denen es eingedämmt werden kann und sollte.

Das richtige mentale Modell ist einfacher: Sichern Sie das deterministische System konsequent ab. Behandeln Sie die Intelligenz als probabilistisch und entwerfen Sie entsprechende Sicherheitsmaßnahmen. In der Praxis bedeutet das, niemals zuzulassen, dass die Rohdaten des Modells direkt Operationen mit hohen Berechtigungen auslösen. Es bedeutet, fähigkeitsbasierte Tool-Schnittstellen zu entwickeln, anstatt dem Modell umfassenden Zugriff zu gewähren. Es bedeutet, die Artefakte der Schlussfolgerungen und Tool-Aufrufe zu protokollieren, damit Sie Entscheidungen im Nachhinein überprüfen können. Und es bedeutet, davon auszugehen, dass Benutzereingaben nicht nur auf Zeichenfolgenebene, sondern auch auf der Ebene der Absicht böswillig sind.

Der größte Fehler, den ich derzeit beobachte, ist, dass Teams diese beiden Bereiche zu einem einzigen zusammenfassen. Sie sagen dann: „Wir haben das Modell gesichert“, als wäre das eine schlüssige Aussage. Man sichert ein Modell nicht isoliert. Man sichert das System, in das es eingebettet ist. Das Modell ist nur eine Komponente – und zwar die am wenigsten deterministische Komponente im Stack.

Aus Sicht der Führung hat dies Auswirkungen auf die Verantwortlichkeiten. Anwendungssicherheitsteams verstehen die deterministische Durchsetzung. Teams für maschinelles Lernen verstehen das Modellverhalten und die Fehlermodi. KI-Sicherheit spielt sich an der Schnittstelle ab. Wenn diese Gruppen nicht gezielt zusammenarbeiten, entstehen Lücken genau dort, wo das deterministische System die Kontrolle an das probabilistische System übergibt.

Nach jahrelanger Erfahrung damit, Systeme zu zerstören und wieder aufzubauen, glaube ich nicht, dass KI bedeutet, die Grundlagen der Sicherheit aufzugeben. Vielmehr muss man sich daran erinnern, warum diese Grundlagen überhaupt funktioniert haben. Sie haben funktioniert, weil das Verhalten vorhersehbar war. Wo das Verhalten nicht mehr vorhersehbar ist, gleicht man dies durch Eindämmung, Überwachung und die Trennung von Befugnissen aus.

Wir sichern keine Magie ab. Wir sichern eine probabilistische Engine ab, die in eine deterministische Infrastruktur eingebettet ist. Wenn wir die Infrastruktur richtig gestalten, lässt sich der Nichtdeterminismus in den Griff bekommen. Tun wir dies nicht, räumen wir den statistischen Inferenz-Engines am Ende mehr Autorität ein, als wir jemals einem menschlichen Ingenieur einräumen würden.

Und das ist kein KI-Problem. Das ist ein architektonischer Fehler.