Sicherheitsprinzipien für LLM-Systeme im Zero-Trust-Ansatz

Künstliche Intelligenz mit großen Sprachmodellen (LLMs) ist längst in der Praxis angekommen. Ob in Chatbots, als Assistenten in Unternehmen oder eingebettet in Fachanwendungen – die Einsatzmöglichkeiten scheinen grenzenlos. Doch je mehr Verantwortung diesen Systemen übertragen wird, desto größer werden auch die Risiken.

Im August 2025 haben deshalb das Bundesamt für Sicherheit in der Informationstechnik (BSI) und die französische Agence nationale de la sécurité des systèmes d’information (ANSSI) ein gemeinsames Grundlagenpapier veröffentlicht: „Design Principles for LLM-based Systems with Zero Trust“.

Die Botschaft ist eindeutig:
LLMs dürfen nicht völlig autonom handeln – für kritische Entscheidungen bleibt der Mensch die unverzichtbare Kontrollinstanz.

Warum Zero Trust bei LLMs entscheidend ist

LLMs verarbeiten heute längst nicht nur Text, sondern auch Bilder, Dokumente oder sogar Code. Sie können Informationen kombinieren, Entscheidungen vorbereiten und als Agents eigenständig Aktionen in anderen Systemen auslösen – vom E-Mail-Versand bis zum Datenbankzugriff. Genau hier entstehen neue Gefährdungslagen:

• Evasion Attacks: Angreifer tarnen Eingaben so, dass Sicherheitsmechanismen umgangen werden. Das Modell interpretiert den Input falsch und liefert Ergebnisse, die eigentlich blockiert werden müssten.

• Poisoning Attacks: Schon kleine Manipulationen in Trainings- oder Referenzdaten können das Verhalten des Modells nachhaltig verändern – bis hin zu schädlichen oder gezielt falschen Ausgaben.
• Poisoning Attacks: Schon kleine Manipulationen in Trainings- oder Referenzdaten können das Verhalten des Modells nachhaltig verändern – bis hin zu schädlichen oder gezielt falschen Ausgaben.
• Indirekte Prompt Injections: Unsichtbare Befehle, eingebettet in Texte, Bilder oder Links, können LLMs dazu bringen, Anweisungen auszuführen, die gar nicht vom eigentlichen Nutzer stammen.

Das BSI/ANSSI-Dokument zeigt deshalb klar: LLMs sind besonders anfällig für Manipulationen, wenn ihnen implizit vertraut wird. Der Zero-Trust-Ansatz schafft hier den notwendigen Rahmen:

• Jede Interaktion wird überprüft – egal, ob sie von einem Nutzer, einem Agenten oder einem externen System kommt.

• Keine Komponente wird implizit vertraut – Vertrauen wird nicht vorausgesetzt, sondern muss jedes Mal neu hergestellt werden.
• Rechte werden so granular wie möglich vergeben – nach dem Prinzip „Least Privilege“ bekommt jede Komponente nur genau die Zugriffe, die sie für ihre Aufgabe braucht – nicht mehr.

Die zentrale Botschaft: Zero Trust ist die einzige tragfähige Sicherheitsphilosophie für LLMs, weil diese Systeme nicht zwischen „gutartig“ und „bösartig“ unterscheiden können. Kontrolle, Begrenzung und Überprüfung müssen die Lücken schließen, die in der Technik selbst angelegt sind.

Die sechs Designprinzipien im Detail

1. Authentifizierung & Autorisierung

• Jeder Zugriff – ob durch Menschen, KI-Agents oder Systemkomponenten – muss eindeutig geprüft werden.

• Least Privilege: Jede Instanz erhält nur die absolut notwendigen Rechte.
• Multi-Faktor-Authentifizierung erhöht die Hürde für unbefugten Zugriff.
• Wichtige Einschränkung: LLMs selbst dürfen nicht für Authentifizierungs- oder Autorisierungszwecke genutzt werden. Sie sind nicht dafür gebaut und könnten Sicherheitsmechanismen leicht umgehen.

Typische Risiken aus der Praxis:

• Ein Nutzer erhält temporär Administratorrechte – diese werden aber nicht widerrufen und bleiben über mehrere Sessions bestehen.

• Plug-ins oder Erweiterungen erhalten Zugriff auf Konversationshistorien und können sensible Daten exfiltrieren.
• Privilegien werden versehentlich dauerhaft vergeben, sodass unbefugte Änderungen an Systemkonfigurationen oder Daten möglich sind.

2. Input- & Output-Kontrolle

• Alle Eingaben und Ausgaben eines LLM-Systems müssen validiert, geprüft und ggf. blockiert werden.

• Besonders wichtig ist der Schutz vor Prompt Injections – also versteckten Befehlen im Eingabetext – und vor automatischem Laden externer Inhalte.
• Externe Inhalte (z. B. Bilder in Markdown) dürfen nie ohne Prüfung abgerufen oder verarbeitet werden.

Beispiel aus dem Dokument:
Ein Angreifer bettet unsichtbare Anweisungen in ein Bild ein („Ignore all previous instructions…“). Wird dieses Bild per OCR verarbeitet, liest das Modell die versteckte Instruktion aus – und führt sie aus, ohne dass der Nutzer sie sieht.

3. Sandboxing

• Sessions und Nutzer müssen strikt voneinander isoliert sein – weder Dateien noch Kontexte dürfen „mitwandern“.

• Emergency Shutdowns müssen möglich sein, um ein kompromittiertes System sofort stoppen zu können.
• Systeme mit sensiblen Daten sollten im Zweifel ohne Internetzugang betrieben werden.
• KI-Speicher (Memory) muss klar geregelt sein: Was darf über Sessions hinweg erhalten bleiben, was nicht?

Risiko:
Ein Angreifer bringt Schadcode in den Speicher („Memory“) eines LLMs. Ohne Isolation bleibt dieser Angriff über mehrere Sitzungen bestehen und kann dauerhaft missbraucht werden.

4. Monitoring, Reporting & Controlling

• Lückenloses Logging aller Anfragen, Antworten und Systeminteraktionen ist Pflicht.

• Anomalie-Erkennung (z. B. ungewöhnliche Token-Mengen, sich selbst aufrufende Prozesse) hilft, Angriffe oder Missbrauch früh zu erkennen.
• Automatisierte Reaktionen können Vorfälle sofort eindämmen – etwa das Blockieren verdächtiger Anfragen.
• Token-Limits pro Nutzer oder System schützen vor Missbrauch, Überlastung oder Kostenexplosionen.

5. Threat Intelligence

• LLM-Systeme müssen aktiv von aktuellen Angriffsmethoden lernen – etwa neuen Prompt-Injection-Techniken.

• Der Austausch mit der Security-Community ist entscheidend, um zeitnah reagieren zu können.
• Regelmäßige Red-Teaming-Tests sind ein Muss, um Verteidigungsmaßnahmen realistisch zu prüfen.
• Dynamische Analyse hilft, Angriffsindikatoren (IOCs) früh zu erkennen.

Risiko:
Unternehmen, die keine Threat-Intelligence-Quellen nutzen, laufen Gefahr, Angriffsmethoden zu übersehen – die Abwehr bleibt immer einen Schritt zu spät.

6. Awareness

• Technische Maßnahmen reichen nicht aus. Menschen bleiben die entscheidende Verteidigungslinie.

• Entwickler, Admins und Nutzer müssen verstehen, wie LLMs funktionieren – und wo ihre Schwachstellen liegen.
• Rechtliche Grundlagen wie die DSGVO oder der EU AI Act müssen bekannt sein.
• Kommunikation muss klarstellen: „Do not trust AI systems unconditionally.“
• Awareness-Programme, Red-Teaming-Übungen und Schulungen sind integraler Bestandteil der Sicherheitsarchitektur.

Diese sechs Prinzipien bilden zusammen ein umfassendes Sicherheitsfundament für LLM-Systeme: Sie adressieren sowohl technische Schwachstellen als auch organisatorische und menschliche Faktoren – und machen deutlich, dass Zero Trust bei KI kein Zusatz, sondern eine Grundvoraussetzung ist.

Mein Fazit

Das Dokument macht deutlich: Der Einsatz von KI-Agents ist aktuell alles andere als „sicher“ oder „erprobt“.
Die Beispiele für Angriffe – von Prompt Injections über Datenexfiltration bis hin zu fehlerhafter Rechtevergabe – zeigen, wie schnell aus einem praktischen Helfer ein erhebliches Risiko werden kann.

Gleichzeitig gilt: LLMs können enorme Vorteile bringen. Sie beschleunigen Prozesse, unterstützen Analysen, verbessern Services. Aber dieser Nutzen entfaltet sich nur dann, wenn er von einer tragfähigen Sicherheitsarchitektur getragen wird:

• Zero Trust als Grundprinzip – kein Vertrauen ohne Prüfung, keine Rechte ohne Kontrolle.

• Klare Systemgrenzen – Isolation, Monitoring und restriktive Autorisierung.
• Menschliche Aufsicht – nicht als Misstrauensvotum gegen die Technik, sondern als notwendiges Korrektiv.

Für Unternehmen bedeutet das: Blindes Experimentieren ist keine Option. Wer LLMs integriert, muss dieselben Maßstäbe ansetzen wie bei jeder kritischen IT-Infrastruktur: Risikoanalyse, Architekturdesign, Einhaltung von Standards (BSI, ISO, NIST, NIS2) und Sensibilisierung der Beteiligten.

Am Ende steht keine Abkehr von KI, sondern ein klares Leitbild:
Nur mit Analyse, Architektur und Sicherheit können LLMs verantwortungsvoll genutzt werden – und ihren Mehrwert entfalten, ohne zum Risiko zu werden.

───────────────────────────────────────────────────────

Quellenangaben:
1. Design Principles for LLM-based Systems with Zero Trust