Zero Trust hat ein KI-Agenten-Problem – kaum jemand sieht es

Wer in den letzten Jahren auf Sicherheitskonferenzen unterwegs war, kennt das Muster: Ein Thema dominiert, bis das nächste kommt. Zero Trust war so ein Thema. Es hat, konsequent umgesetzt, tatsächlich funktioniert. Das Prinzip ist simpel und wirkungsvoll: Die richtigen Personen erhalten zur richtigen Zeit aus den richtigen Gründen Zugang zu den richtigen Ressourcen. Wo dieses Prinzip greift, sinkt das Risiko messbar.

Umso irritierender war das Bild auf der RSA Conference 2026. Statt Zero Trust dominierten Slogans wie „Trust our AI“ und „Trust our agents“ die Messehallen. Als hätten drei Jahre harter Arbeit an Vertrauensarchitekturen keine Spuren hinterlassen. Dabei wäre die Konsequenz eigentlich naheliegend: Wenn Zero Trust für menschliche Nutzer funktioniert, muss es auch für autonome Agenten gelten. Das Problem ist nur: Das ist derzeit nicht der Fall, zumindest strukturell nicht.

Die stille Grundannahme und warum sie nicht mehr trägt

Die meisten Zero-Trust-Architekturen wurden mit einer konsistenten Grundannahme gebaut: Jede Zugriffsanfrage geht von einem Menschen aus. Ein Benutzer authentifiziert sich, ein Gerät wird auf seinen Sicherheitsstatus geprüft, eine Richtlinie bewertet den Kontext und gewährt oder verweigert Zugang. Dieses Modell hat über mehr als ein Jahrzehnt Cloud-Adoption und Remote Work standgehalten.

Das Problem: Es entspricht nicht mehr dem Modell, das Unternehmen heute tatsächlich betreiben. KI-Agenten operieren außerhalb dieses Rahmens. Sie authentifizieren sich einmal und laufen dann autonom: rufen APIs auf, lesen Daten, aktivieren Tools, kommunizieren mit anderen Agenten oder Systemen, ohne dass ein Mensch eingreift. Die Credentials, die sie nutzen, sind gültig. Die Sessions, die sie öffnen, sind autorisiert. Aber die Aktivitäten, die folgen, können alles sein: von Routineautomatisierung bis zur vollständigen Datenexfiltration, ausgelöst durch einen manipulierten Prompt, für den keine Richtlinie gebaut wurde.

Die Dimension dieses Problems wächst schnell. Laut IDC beliefen sich die KI-Ausgaben von Unternehmen 2025 auf 241,8 Milliarden US-Dollar und sollen bis 2029 auf über 867 Milliarden US-Dollar steigen. Der überwiegende Teil dieser Investitionen fließt in agentische Workflows. IT-Sicherheitsteams müssen ihre Zero-Trust-Kontrollen entsprechend ausweiten.

Der blinde Fleck: Agenten ohne belastbare Identität 

Zero Trust beginnt mit Identität. Für menschliche Nutzer ist das gelöst: Gerät, Standort, Verhaltensprofil und Risk Score, wobei alles in eine dynamische Vertrauensentscheidung mit einfließt . Bei KI-Agenten fehlt diese Grundlage in den meisten Unternehmen vollständig.

Das liegt nicht nur an fehlenden Standards. Viele Agenten, die Unternehmen heute einsetzen oder aus dem Internet beziehen, sind technisch schlicht nicht in der Lage, Zertifikate zu halten oder sich über standardisierte Verfahren zu authentifizieren. Hinzu kommt ein operatives Problem: Entwicklerinnen und Entwickler erstellen, speichern und teilen häufig Zugriffstoken über mehrere Agenten hinweg. Diese Praxis erleichtert Angreifern die Arbeit erheblich.

Die eigentliche Bedrohung kommt dabei nicht beim Authentifizierungspunkt an.Sie tritt mitten in der Session auf, eingebettet in Daten, die der Agent verarbeitet. Prompt Injection ist das klassische Beispiel: Ein Angreifer platziert bösartige Anweisungen in einem Dokument, einer E-Mail oder einer Webseite, die der Agent im Rahmen seines Workflows liest. Der Agent interpretiert diese Anweisungen als legitime Ziele und arbeitet auf sie hin, inklusive Datenexfiltration, unautorisierten API-Calls oder der Modifikation von Datensätzen. Die Session war autorisiert. Die Credentials waren gültig. Keine Richtlinie hat angeschlagen.

IBM Research hat ermittelt, dass Jailbreak-Versuche in rund 20 Prozent der Fälle erfolgreich sind. Angreifer benötigen dafür mitunter nur 42 Sekunden und fünf Interaktionen, um Sicherheits-Guardrails zu umgehen. Wenn Agenten hunderte Calls pro Minute ausführen, ist diese Erfolgsrate keine theoretische Größe mehr.

Moderne Ansätze setzen hier auf kurzlebige Credentials, die die Identität des Agenten mit der des menschlichen Auslösers verbinden. Diese sogenannte „Blended Identity“ (verschränkte Identität) ist der Schlüssel zu sinnvollen Zugriffsrichtlinien: nicht nur „Ist dieser Agent berechtigt?“, sondern „Ist dieser spezifische Nutzer, der diesen spezifischen Agenten einsetzt, berechtigt, genau jetzt auf genau diese Ressource zuzugreifen?“

MCP: Datenverkehr, den kaum jemand sieht

Model Context Protocol (MCP) entwickelt sich zum Standard für die Anbindung von KI-Agenten an externe Tools und Datenquellen. Es ist gewissermaßen die API-Schicht für agentische KI. Ein Agent mit MCP-Zugang kann Datenbanken, Code-Repositories, Kommunikationsplattformen und weitere interne Systeme erreichen. Was wie eine technische Komfortlösung klingt, ist sicherheitstechnisch ein blinder Fleck.

Der MCP-Traffic ist in den meisten Unternehmen für die IT vollständig unsichtbar. Herkömmliche Proxies und Security Gateways sind nicht dafür gebaut, MCP-Verbindungen zu inspizieren oder auf Anomalien zu prüfen. Unternehmen, die diesen Traffic nicht systematisch erfassen, können weder Richtlinien durchsetzen noch verdächtiges Verhalten erkennen.

Sichtbarkeit bedeutet in diesem Kontext mehr als Discovery. Es geht darum zu verstehen, was Agenten tun, ob dieses Verhalten normal ist und wann es verdächtig wird. Nur wer eine Baseline des normalen Agentenverhaltens etabliert hat, kann Abweichungen erkennen, die auf Kompromittierung oder Fehlfunktion hinweisen.

Von Least Privilege zu Least Agency

Sobald eine belastbare Identitätsgrundlage existiert, lässt sich das Zero-Trust-Prinzip des minimalen Zugriffs auf Agenten übertragen. OWASP nennt das Konzept treffend „Least Agency“: Agenten sollen nur das dürfen, was sie für ihre konkrete Aufgabe tatsächlich benötigen, mehr nicht.

In der Praxis bedeutet das: Zugriffsrichtlinien müssen Agenten-Identitäten mit Rollen verknüpfen und den erlaubten Kontext präzise definieren, und zwar nach Zeit, Standort, Datensensitivität, Risiko-Score und Anwendungsinstanz. Entscheidend ist dabei, dass diese Prüfung inline erfolgt, also im laufenden Datenstrom. Ein Agent, der versucht, außerhalb seiner definierten Grenzen zu agieren, wird blockiert und nicht erst im Nachhinein protokolliert. Diese Unterscheidung ist fundamental: Eine Kontrolle, die nur aufzeichnet, was bereits geschehen ist, erzeugt Dokumentation, aber keine Sicherheit.

Die entscheidende Frage: Warum handelt der Agent so? 

Ein oft übersehener Aspekt von Zero Trust ist die Frage nach dem Zweck einer Aktion. Bei menschlichen Nutzern lässt sich der Kontext einer Anfrage zumindest teilweise aus Verhaltensprofilen ableiten. Bei Agenten ist das schwieriger. Sie können nicht zwischen legitimen Anweisungen und manipulierten Befehlen unterscheiden und führen aus, was ihnen gesagt wird.

Hier kommen Guardrails ins Spiel: eine Laufzeit-Schutzschicht, die den eingehenden Traffic auf Prompt-Injection-Angriffe, Jailbreaking-Versuche sowie unerlaubte Datenexfiltration prüft und den Agenten schützt, bevor Schaden entsteht. Ein ergänzender Ansatz ist die unabhängige Beobachtung von Agenten von außen. Sobald ein Agent beginnt, Credentials zu berühren oder Daten an unerwartete Ziele zu senden, kann ein an den Sicherheitszustand gekoppelter Zugriff ihn ausbremsen, noch bevor ein Schaden entsteht.

Drei Maßnahmen für bestehende Architekturen

Die meisten Unternehmen, die Zero Trust ernsthaft betreiben, haben bereits in Identity and Access Management, Conditional Access und Netzwerksegmentierung investiert. Diese Investitionen sind nicht wertlos, aber sie reichen nicht aus. Drei strukturelle Erweiterungen sind notwendig.

1. Non-Human Identity Governance, eine Governance für nicht-menschliche Identitäten, als eigenständige Disziplin: KI-Agenten müssen im Identity-Management-System sichtbar, inventarisiert und mit klaren Berechtigungsprofilen versehen sein. Shared Tokens und langlebige Credentials für Agenten sind ein strukturelles Risiko, das durch kurzlebige, aufgabengebundene Credentials ersetzt werden muss.
2. Die Durchsetzung im laufenden Datenstrom (Inline Enforcement) muss das nachträgliche Protokollieren (Post-hoc-Logging) ersetzen: Ein Agent, der eine unerwartete Aktion ausführt, muss gestoppt werden, nicht dokumentiert. Das erfordert eine Security-Stack-Komponente, die MCP-Traffic in Echtzeit versteht und bewerten kann.
3. Unternehmen brauchen Verhaltens-Baselines (Behavioral Baselines) für Agenten: Anomalieerkennung funktioniert nur, wenn bekannt ist, was normal ist. Wer Agenten produktiv einsetzt, sollte systematisch erfassen, welche API-Calls und Datenzugriffe zum Normalbetrieb gehören, und Abweichungen konsequent als Sicherheitssignal behandeln.

Zero Trust neu gedacht

Die klassische Definition von Zero Trust bleibt gültig: die richtigen Personen erhalten zur richtigen Zeit aus den richtigen Gründen Zugang zu den richtigen Ressourcen. Sie muss nur um eine Dimension erweitert werden: die richtigen Personen und Agenten.

Das ist mehr als eine kleine Ergänzung und verändert die Struktur, wie Identitätsmanagement, Zugriffsrichtlinien, Sichtbarkeit und Monitoring aufgebaut werden müssen. Dies macht deutlich, warum „Trust our AI“ als Sicherheitsstrategie nicht funktioniert, und zwar aus demselben Grund, aus dem „Trust our users“ nicht funktioniert hat.

Zero Trust war die Antwort auf blindes Vertrauen in Nutzer. Es muss jetzt die Antwort auf blindes Vertrauen in Agenten werden. Wer die Architektur heute entsprechend erweitert, wird nicht überrascht sein, wenn der erste große agentische Sicherheitsvorfall die Schlagzeilen dominiert.