Zero Trust für KI-Systeme: Warum die gleichen Prinzipien gelten – und wo sie an ihre Grenzen stoßen

Zero trust ist eines der ausgereiftesten Frameworks in der Unternehmenssicherheit. Die Prinzipien – niemals vertrauen, immer verifizieren, von einem Sicherheitsvorfall ausgehen, geringste Privilegien durchsetzen – sind bekannt, werden gut umgesetzt und sind fest in der Denkweise von Sicherheitsteams rund um Zugriffskontrolle verankert.

Das Problem: Zero trust wurde für ein bestimmtes Akteursmodell entwickelt – menschliche Anwender mit stabilen Identitäten, vorhersehbaren Verhaltensmustern und klar definierten Sitzungsgrenzen. KI-Systeme erfüllen keine dieser Eigenschaften. Sie agieren im Auftrag von Anwendern, ohne selbst Anwender zu sein. Ihr Verhalten ist semantisch komplex und operativ undurchsichtig. Sie können Tausende von Datenoperationen ausführen, während ein Mensch nur eine erledigt.

Dieser Beitrag richtet sich an CISOs und Security-Architekten, die Zero-Trust-Architekturen auf KI-Akteure ausweiten müssen – und verstehen wollen, wo ihre bestehenden Frameworks greifen und wo nicht.

Executive Summary

Hauptaussage: Die Zero-Trust-Prinzipien, die den menschlichen Zugriff auf Unternehmensdaten steuern, gelten ebenso für KI-Systeme – aber die Mechanismen, die diese Prinzipien für menschliche Akteure umsetzen, lassen sich nicht direkt übertragen. KI-Akteure benötigen speziell entwickelte Kontrollen, die ihre einzigartigen Identitäts-, Verhaltens- und Betriebsmerkmale adressieren.

Warum das relevant ist: Sicherheitsteams, die Zero-Trust-Frameworks für menschliche Akteure ohne Anpassung auf KI-Systeme anwenden, schaffen eine Governance-Lücke, die sie nicht erkennen. Die Kontrollen wirken auf dem Papier korrekt – Authentifizierung existiert, Zugriffsrichtlinien sind definiert, Logging ist konfiguriert – aber sie werden nicht so durchgesetzt, wie es die Betriebsmerkmale von KI erfordern. Das Ergebnis ist eine Zero-Trust-Haltung, die technisch vorhanden, aber praktisch unzureichend ist.

5 Wichtige Erkenntnisse

1. Zero-Trust-Prinzipien gelten für KI-Systeme unverändert – niemals vertrauen, immer verifizieren, von einem Sicherheitsvorfall ausgehen, geringste Privilegien durchsetzen. Was angepasst werden muss, ist die Umsetzung: Die für menschliche Akteure entwickelten Kontrollen adressieren weder das Identitätsmodell noch die Verhaltensmerkmale oder den operativen Maßstab von KI.
2. KI-Identität unterscheidet sich grundlegend von menschlicher Identität. Ein KI-System hat keinen stabilen Identitätsanker – es agiert im Auftrag von Anwendern, ist anfällig für Prompt Injection, die die scheinbare Absicht verändern kann, und läuft meist unter Servicekonten, die verschleiern, wer tatsächlich die Aktionen steuert.
3. Sitzungsbasierte Authentifizierung – der Standardansatz bei den meisten KI-Integrationen – widerspricht Zero-Trusts Anforderung an kontinuierliche Verifizierung. Autorisierung pro Anfrage, durchgesetzt über RBAC und ABAC auf Datenebene, ist das einzige Implementierungsmuster, das das Prinzip „niemals vertrauen“ für KI-Akteure tatsächlich erfüllt.
4. Der Schadensumfang eines kompromittierten KI-Systems ist kategorisch größer als bei einem kompromittierten Benutzerkonto. Ein KI-System mit breitem Datenzugriff und ohne Rate Limiting kann Daten in einem Ausmaß und Tempo exfiltrieren, das Incident Response reaktiv statt präventiv macht. Eine Assume-Breach-Architektur für KI erfordert Rate Limiting und Scope Controls, die es im menschlichen Zero-Trust-Modell nicht gibt.
5. Audit-Logs für KI-Operationen benötigen eine doppelte Zuordnung – die Identität des KI-Systems und des menschlichen Anwenders, in dessen Auftrag es agiert – um Compliance-Anforderungen zu erfüllen. Logs, die nur die Aktionen des KI-Systems erfassen, sind forensisch und regulatorisch unvollständig.

Warum Zero Trust das richtige Framework ist – und warum es erweitert werden muss

Zero trust entstand als Antwort auf das Scheitern der Perimeter-Sicherheit: die Erkenntnis, dass ein Akteur im Netzwerk zu viel implizites Vertrauen erhält. Die Lösung war, jede Zugriffsanfrage als potenziell feindlich zu behandeln – unabhängig vom Standort im Netzwerk – und Identität zu verifizieren, geringste Privilegien durchzusetzen und jede Operation kontinuierlich zu protokollieren. Diese Prinzipien sind auch für KI-Akteure richtig. Ein KI-System, das sich gegenüber einem Daten-Repository authentifiziert hat, sollte kein implizites Vertrauen für die gesamte Sitzung erhalten. Jede Anfrage muss gegen Richtlinien geprüft werden. Alle Operationen müssen protokolliert werden. Der Zugriff muss auf die Berechtigungen des steuernden Menschen begrenzt sein.

Die notwendige Erweiterung betrifft nicht die Prinzipien, sondern die Annahmen bei der Umsetzung. Zero-Trust-Frameworks gehen davon aus, dass der Akteur eine stabile, verifizierbare Identität besitzt – ein Benutzerkonto, ein Zertifikat, ein Hardware-Token. Sie setzen voraus, dass Sitzungsgrenzen sinnvoll auf Autorisierungsgrenzen abbilden. Sie nehmen an, dass „normales Verhalten“ erkennbar und Abweichungen davon detektierbar sind. KI-Systeme verletzen alle drei Annahmen, und die darauf aufbauenden Kontrollen müssen für ein grundlegend anderes Akteursmodell neu konzipiert werden.

Das Identitätsproblem: KI-Systeme haben keine stabilen Identitäten

Zero trust für menschliche Akteure basiert auf Identitätsprüfung: den Anwender authentifizieren, seine Identität feststellen und diese Identität als Grundlage für Autorisierungsentscheidungen nutzen. Das funktioniert, weil menschliche Identitäten stabil sind – ein Benutzerkonto ist einer bestimmten Person mit bestimmten Rollen und Zugriffsrechten zugeordnet, verifiziert durch MFA und IAM-Systeme. KI-Systeme haben keinen vergleichbaren Identitätsanker.

Die „Identität“ eines KI-Systems ist in den meisten Unternehmensanwendungen ein Servicekonto – eine geteilte Anmeldeinformation, die die KI-Plattform repräsentiert, nicht den konkreten Anwender, der die Aktion auslöst. Das schafft zwei Governance-Probleme. Erstens verschleiert das Servicekonto, wer tatsächlich für den Datenzugriff verantwortlich ist: Wenn eine KI ein Dokument abruft, zeigt das Audit-Protokoll das Servicekonto, nicht den Mitarbeitenden, der die Anfrage gestellt hat. Zweitens besitzt das Servicekonto meist Berechtigungen, die über das hinausgehen, was Einzelanwender erhalten würden – weil es so konfiguriert ist, dass die KI jedem Anwender dienen kann, benötigt es Zugriff auf alles, was ein Anwender potenziell braucht.

Das tiefere Identitätsproblem ist Prompt Injection. Das Verhalten eines KI-Systems wird durch seine Eingaben bestimmt – und diese Eingaben können manipuliert werden. Ein Prompt-Injection-Angriff bettet Anweisungen in die Daten ein, die die KI verarbeitet, und lenkt ihr Verhalten so, dass Governance-Kontrollen umgangen, Anmeldeinformationen extrahiert oder Daten außerhalb des vorgesehenen Umfangs abgerufen werden. Anders als bei einem menschlichen Anwender, dessen Identität unabhängig von gelesenen Inhalten stabil bleibt, kann sich die effektive „Identität“ eines KI-Systems – also was es als Nächstes tut – durch Inhalte im Kontextfenster ändern. Klassische Identitätsprüfung hat hierfür keinen Mechanismus. Zero trust Datenschutz für KI erfordert, dass Anmeldeinformationen vollständig außerhalb des KI-Kontexts gespeichert werden, etwa im OS Keychain, wo sie durch Prompt-Manipulation nicht erreichbar sind.

Das Sitzungsgrenzen-Problem: Wann bedeutet „kontinuierlich“ wirklich pro Anfrage?

Zero-Trusts Anforderung an kontinuierliche Verifizierung wird typischerweise durch Sitzungsmanagement umgesetzt: Re-Authentifizierung nach Inaktivität, risikobasierte Step-up-Authentifizierung und Anomalieerkennung während einer Sitzung. Für menschliche Akteure ist das sinnvoll – eine Sitzung steht für einen begrenzten Zeitraum gezielter Aktivität, und Re-Authentifizierung an Sitzungsgrenzen bietet eine sinnvolle Kontrolle.

KI-Sitzungen funktionieren anders. Ein KI-Agent, der im Auftrag eines Anwenders agiert, kann stundenlang eine persistente Verbindung zu Unternehmensdaten halten und Tausende Einzeloperationen in einer Sitzung ausführen. Sitzungsbasierte Authentifizierung bedeutet, dass die KI einmal zu Beginn verifiziert wurde – aber jede nachfolgende Operation innerhalb der Sitzung übernimmt diese initiale Autorisierung ohne eigene Verifizierung. Für einen menschlichen Anwender, der ein Dateisystem durchsucht, ist das tolerierbar. Für ein KI-System, das Tausende Abrufe pro Minute ausführen kann, ist Sitzungsautorisierung keine kontinuierliche Verifizierung – sondern ein einzelner Checkpoint, gefolgt von unüberwachtem Zugriff mit Maschinengeschwindigkeit.

Echte kontinuierliche Verifizierung für KI erfordert Autorisierung pro Anfrage: Jede einzelne Operation – jeder Dateizugriff, jede Abrufanfrage, jede Ordnernavigation – wird zum Zeitpunkt der Anfrage gegen RBAC- und ABAC-Richtlinien geprüft. Das ist nicht nur eine Best Practice – es ist die einzige Umsetzung von „niemals vertrauen, immer verifizieren“, die dem operativen Tempo von KI-Systemen gerecht wird. Sitzungsautorisierung ist eine einmalige Verifizierung, gefolgt von ausgedehntem Vertrauen. Das ist kein Zero trust; das ist ein Perimeter-Modell mit kürzerem Perimeter.

Zero-Trust-Prinzipien: Menschliche Akteure vs. KI-Akteure

Das Blast-Radius-Problem: Warum Assume-Breach für KI etwas anderes bedeutet

Assume-Breach-Architekturen für menschliche Akteure konzentrieren sich auf die Begrenzung lateraler Bewegungen: Netzwerksegmentierung, geringste Privilegien und Anomalieerkennung, um einen kompromittierten Anwender vor weiteren Zugriffen zu stoppen. Der Schadensumfang eines kompromittierten menschlichen Kontos ist zwar ernst, aber durch das menschliche Arbeitstempo begrenzt – ein Mensch kann nur begrenzt schnell auf Daten zugreifen.

Ein kompromittiertes KI-System agiert in einer völlig anderen Größenordnung. Ein KI-Agent mit breitem Repository-Zugriff und ohne Rate Limiting kann Hunderttausende Dokumente abrufen, während ein Security Analyst gerade erst eine SIEM-Benachrichtigung sieht. Die Assume-Breach-Kontrollen, die für menschliche Akteure funktionieren – Anomalieerkennung, Sitzungsbeendigung, Netzwerksegmentierung – sind beim KI-Tempo meist nur reaktiv. Bis eine Anomalie erkannt und die Sitzung beendet ist, sind die Daten längst exfiltriert.

Assume-Breach für KI erfordert proaktive Begrenzung des Schadensumfangs, die im menschlichen Zero-Trust-Framework nicht existiert. Rate Limiting für KI-Datenanfragen – durchgesetzt auf Datenebene, nicht auf Anwendungsebene – begrenzt das Datenvolumen, das ein KI-System unabhängig von seinen Anweisungen abrufen kann. Pfad- und Scope-Kontrollen verhindern, dass die KI außerhalb des vorgesehenen Datenbereichs navigiert. Diese Kontrollen erkennen Kompromittierungen nicht erst im Nachhinein; sie begrenzen den Schaden, bevor er entsteht. Das ist eine grundlegend andere Kontrollphilosophie als bei menschlichen Assume-Breach-Ansätzen und erfordert speziell entwickelte Architektur statt Anpassung bestehender Sicherheitskontrollen.

Das Audit-Problem: Wer ist verantwortlich, wenn eine KI auf Daten zugreift?

Zero-Trust-Audit-Anforderungen für menschliche Akteure sind etabliert: Identität des Anwenders, aufgerufene Ressource, Zeitstempel und Aktion protokollieren. Das ergibt einen Audit-Trail, der HIPAA-Compliance, DSGVO-Compliance, SOX- und FedRAMP-Anforderungen erfüllt, weil das Protokoll die Verantwortlichkeit klärt: Eine bestimmte Person hat auf eine bestimmte Ressource zugegriffen und ist dafür verantwortlich.

KI-Zugriffsprotokolle in den meisten Unternehmensimplementierungen erfassen nur die KI-Systemidentität – das Servicekonto – und sonst nichts. Wenn eine KI ein sensibles Dokument abruft, zeigt das Log nur, dass das Servicekonto der KI-Plattform auf die Datei zugegriffen hat. Es wird nicht erfasst, welcher Mitarbeitende die Anfrage ausgelöst hat, was gefragt wurde oder was mit dem Ergebnis geschah. Das ist keine kleine Lücke. Für HIPAA, das verlangt, dass der Verantwortliche für den Zugriff auf geschützte Gesundheitsdaten identifiziert wird, reicht ein Servicekonto-Eintrag nicht aus. Für die DSGVO, die einen Nachweis der Rechtsgrundlage für jeden Datenzugriff verlangt, kann ein Log ohne menschlichen Anfragenden diese Grundlage nicht liefern.

KI-Audit-Logs benötigen eine doppelte Zuordnung: die KI-Systemidentität und den authentifizierten menschlichen Anwender, in dessen Auftrag die KI agiert – kombiniert in einem Logeintrag für jede Operation. Das ist technisch nicht komplex – die KI muss die Anwenderidentität bei der Anfrage an die Datenebene übergeben, und die Datenebene zeichnet beide Identitäten gemeinsam auf. Aber es erfordert gezieltes Architekturdesign. Die meisten KI-Integrationen implementieren das nicht, und die meisten Zero-Trust-Audit-Frameworks verlangen es nicht explizit.

Kiteworks Zero-Trust-Kontrollen für KI: Umsetzung und Wirkung

Wie Kiteworks Zero Trust auf jede KI-Anfrage ausweitet

Die Sicherheitsteams, die KI-Einführung am erfolgreichsten meistern, sind nicht diejenigen, die KI verbieten – sondern jene, die ihre bestehende Sicherheitsarchitektur so erweitern, dass KI-Akteure mit derselben Strenge behandelt werden wie menschliche Akteure. Diese Erweiterung erfordert speziell entwickelte Kontrollen, denn die Annahmen für menschliche Akteure im bestehenden Zero-Trust-Framework gelten für KI-Systeme nicht. Das Identitätsmodell ist anders. Das Sitzungsmodell ist anders. Der Schadensumfang ist anders. Die Audit-Anforderungen sind anders.

Ein Sicherheitsteam, das diese Unterschiede versteht und gezielt adressiert, kann KI-Einführung mit Zuversicht ermöglichen. Wer hingegen menschliche Kontrollen auf KI-Akteure anwendet und es dabei belässt, hat eine Zero-Trust-Haltung, die technisch vorhanden, aber praktisch unzureichend ist.

Kiteworks implementiert Zero trust für KI-Akteure auf jeder Ebene, auf der das Modell für menschliche Akteure versagt. Credential Isolation: OAuth 2.0 Tokens werden im OS Keychain gespeichert, außerhalb des Kontextfensters des KI-Modells, unter keinen Umständen durch Prompt Injection erreichbar. Autorisierung pro Anfrage: Die Kiteworks Data Policy Engine prüft RBAC- und ABAC-Richtlinien für jede einzelne KI-Operation – nicht beim Sitzungsaufbau, sondern zum Zeitpunkt jeder Anfrage. Die KI übernimmt die Berechtigungen des anfragenden Anwenders und kann diese für keine Aktion überschreiten, unabhängig vom Sitzungsstatus.

Doppelte Audit-Zuordnung protokolliert sowohl die KI-Systemidentität als auch den authentifizierten Anwender für jede Operation, speist das Kiteworks Audit-Protokoll und integriert sich in Echtzeit mit SIEM – ohne Batch-Verarbeitung, ohne Verzögerung, ohne Erkennungslücke. Rate Limiting und Pfadkontrollen setzen Assume-Breach-Architektur auf Datenebene durch: Ein kompromittiertes oder fehlkonfiguriertes KI-System kann keine Daten im großen Stil exfiltrieren, weil die Kontrollen in der Private Data Network-Architektur verankert sind – unabhängig davon, wie sich das KI-System verhält.

Und weil diese Kontrollen das gleiche Zero-Trust-Datenaustausch-Framework erweitern, das sichere Filesharing, Managed File Transfer und sichere E-Mail im gesamten Unternehmen steuert, muss kein separates KI-Sicherheitsprogramm aufgebaut und gepflegt werden. Die vorhandene Zero-Trust-Architektur wird einfach auf KI ausgeweitet – nicht neu geschaffen.

Für CISOs und Security-Architekten, die Zero trust für KI-Akteure mit derselben Strenge wie für menschliche Akteure umsetzen wollen, stellt Kiteworks die dafür notwendigen, speziell entwickelten Kontrollen bereit. Um die Umsetzung im Detail zu sehen, vereinbaren Sie noch heute eine individuelle Demo.

Weitere Ressourcen

• Blogbeitrag
  Zero-Trust-Strategien für erschwinglichen KI-Datenschutz
• Blogbeitrag
  Wie 77 % der Unternehmen bei KI-Datensicherheit scheitern
• eBook
  AI Governance Gap: Warum 91 % kleiner Unternehmen 2025 russisches Roulette mit Datensicherheit spielen
• Blogbeitrag
  Für Ihre Daten gibt es kein „–dangerously-skip-permissions“
• Blogbeitrag
  Aufsichtsbehörden wollen keinen KI-Policy-Nachweis mehr – sie verlangen Belege für die Wirksamkeit.