Zero Trust für KI-Systeme und KI-Agenten

Zero-Trust-Grundprinzipien

Die NIST-Publikation SP 800-207 beschreibt Zero Trust als Architektur mit drei Kernideen: Jeder Zugriff wird explizit geprüft, Rechte werden so knapp wie möglich und so kurz wie nötig vergeben, und es wird davon ausgegangen, dass ein Angreifer bereits im Netz sein kann. Technisch entscheidet ein Policy Decision Point über jede Anfrage, ein Policy Enforcement Point setzt die Entscheidung durch.

Warum KI-Systeme ein Sonderfall sind

Klassische Anwendungen folgen festem Code. KI-Anwendungen, insbesondere Sprachmodelle mit Werkzeugzugriff, entscheiden zur Laufzeit, welche Daten sie abfragen und welche Aktionen sie auslösen – gesteuert durch Eingaben, die teilweise von außen kommen. Daraus ergeben sich typische Risiken:

• Prompt Injection: Eine präparierte E-Mail, Webseite oder ein Dokument bringt einen KI-Agenten dazu, Daten weiterzuleiten oder ungewollte Aktionen auszuführen. Das Modell selbst lässt sich nicht zuverlässig dagegen härten – deshalb müssen die Berechtigungen den Schaden begrenzen.
• Übermäßige Handlungsbefugnis: Die OWASP Top 10 for LLM Applications führen „Excessive Agency“ als eigenes Risiko: Agenten erhalten mehr Rechte, Werkzeuge oder Autonomie, als ihre Aufgabe erfordert.
• Überprivilegierte Service-Accounts: Ein KI-Assistent für das Intranet läuft oft unter einem technischen Konto mit Lesezugriff auf alle Dokumente. Dann sieht jeder Nutzer über den Assistenten Inhalte, auf die er selbst keinen Zugriff hätte.
• Modellgewichte als Kronjuwelen: Selbst trainierte oder feinabgestimmte Modelle sind wertvolles geistiges Eigentum und können Trainingsdaten preisgeben. Liegen sie ungeschützt auf einem Dateiserver oder in einem offenen Storage-Bucket, lassen sie sich kopieren oder manipulieren.

Zero Trust konkret für KI umsetzen

Eigene Identitäten für jede KI-Komponente

Jeder Agent und jede KI-Anwendung erhält eine eigene, eindeutig zuordenbare Identität statt eines geteilten API-Schlüssels. Zugangsdaten sollten kurzlebig sein und automatisch erneuert werden, etwa über Workload-Identitäten der Cloud-Plattform oder Token mit kurzer Gültigkeit. Statische Schlüssel im Quellcode oder in Konfigurationsdateien sind zu vermeiden.

Im Namen des Nutzers handeln

Greift ein KI-Assistent auf Unternehmensdaten zu, etwa bei Retrieval-Augmented Generation (RAG), sollte die Abfrage mit den Berechtigungen des anfragenden Nutzers erfolgen. Die Rechteprüfung muss zum Zeitpunkt der Abfrage stattfinden, nicht nur beim Einlesen der Dokumente in den Index. So kann der Assistent nur liefern, was der Nutzer ohnehin sehen darf.

Werkzeugzugriffe einzeln autorisieren

Jeder Werkzeugaufruf eines Agenten – E-Mail senden, Datensatz ändern, Zahlung anstoßen – wird über eine Richtlinienprüfung außerhalb des Modells geleitet. Lesende Aktionen lassen sich großzügiger freigeben als schreibende. Folgenreiche Aktionen erfordern eine Bestätigung durch einen Menschen. Das gilt auch für standardisierte Anbindungen wie das Model Context Protocol (MCP): Jeder angebundene Server ist eine Vertrauensgrenze.

Netzwerk und Datenabfluss kontrollieren

KI-Workloads sollten nur mit den Systemen kommunizieren dürfen, die sie tatsächlich brauchen. Ausgehende Verbindungen werden auf freigegebene Ziele beschränkt, damit ein manipulierter Agent keine Daten an beliebige Adressen senden kann.

Modelle und Pipelines schützen

Modellgewichte werden verschlüsselt gespeichert, der Zugriff auf Modell-Registry und Trainingsumgebung ist auf wenige, stark authentisierte Rollen begrenzt. Modelle werden signiert und vor dem Einsatz geprüft, damit nur freigegebene Versionen in Produktion gelangen.

Kontinuierlich überwachen

Prompts, Werkzeugaufrufe, Datenzugriffe und Ablehnungen werden protokolliert und im SIEM ausgewertet. Ungewöhnliche Muster – ein Agent, der plötzlich große Datenmengen abfragt oder neue Ziele kontaktiert – lösen Alarme aus.

Vorgehen in der Praxis

1. Alle KI-Anwendungen, Agenten und ihre technischen Konten inventarisieren.
2. Für jedes Konto dokumentieren, auf welche Daten und Werkzeuge es zugreift, und überflüssige Rechte entziehen.
3. RAG-Anwendungen auf nutzerbezogene Berechtigungsprüfung umstellen.
4. Schreibende und externe Aktionen hinter Freigaben oder menschliche Bestätigung legen.
5. Modellgewichte und Trainingsdaten klassifizieren und entsprechend schützen.
6. Protokollierung aktivieren und Anwendungsfälle für die Überwachung definieren.

Regulatorischer Bezug

Zugriffskontrolle, Identitätsmanagement und Multi-Faktor-Authentisierung sind Mindestmaßnahmen nach NIS2 (Art. 21) und im deutschen BSIG. ISO/IEC 27001:2022 enthält entsprechende Controls für Zugriffssteuerung und privilegierte Rechte. Der EU AI Act verlangt für Hochrisiko-KI unter anderem Robustheit, Cybersicherheit und menschliche Aufsicht – Zero-Trust-Maßnahmen unterstützen diese Anforderungen direkt.

Fazit

Da sich Sprachmodelle nicht zuverlässig gegen Manipulation absichern lassen, muss die Sicherheit aus der Umgebung kommen: aus eng begrenzten Identitäten, geprüften Werkzeugaufrufen und lückenloser Überwachung. SecTepe unterstützt bei der Bewertung von KI-Berechtigungskonzepten und bei Penetrationstests von KI-Anwendungen.

Häufige Fragen

Brauche ich für KI eine eigene Zero-Trust-Architektur?

Nein. KI-Komponenten werden in die bestehende Identitäts- und Zugriffsverwaltung integriert, allerdings mit strengeren Regeln für Werkzeugzugriffe und Datenabfluss.

Reicht ein guter System-Prompt als Schutz?

Nein. Anweisungen im System-Prompt lassen sich umgehen. Wirksame Grenzen werden außerhalb des Modells durchgesetzt.