Zero Trust für KI-Agenten: die Vertrauensannahmen, die Angreifer ausnutzen — und die Durchsetzung dagegen

KI-Agenten handeln zunehmend autonom: Sie rufen APIs auf, schreiben in Datenbanken, lösen Zahlungen aus und sprechen untereinander. Das klassische Sicherheitsmodell, das einem Dienst nach einmaliger Anmeldung dauerhaft vertraut, bricht in dieser Welt zusammen. Wer einen Agenten kompromittiert, erbt dessen stehende Berechtigungen. Genau hier setzt Zero Trust für Agenten an.

Was bedeutet Zero Trust für KI-Agenten konkret?

Zero Trust für Agenten heißt: Kein Agent erhält Vertrauen aufgrund seines Standorts im Netzwerk oder einer einmaligen Anmeldung. Stattdessen wird jede einzelne Aktion gegen eine zentrale Richtlinie geprüft, jede Identität bei jedem Zugriff erneut verifiziert und jede Verbindung zwischen Agenten kryptografisch beidseitig abgesichert. Das Prinzip lautet „niemals vertrauen, immer überprüfen“ – und zwar pro Anfrage, nicht pro Sitzung.

Drei Bausteine tragen dieses Modell. Erstens die kontinuierliche Verifizierung, die Identität und Kontext eines Agenten bei jeder Aktion neu bewertet. Zweitens der Policy Decision Point (PDP), eine zentrale Instanz, die über jede Zugriffsanfrage entscheidet. Drittens Agent-zu-Agent-mTLS, das die Kommunikation zwischen Agenten durch beidseitige Authentifizierung absichert. Wenn einer dieser Bausteine fehlt, entsteht eine Lücke, die ein kompromittierter Agent sofort ausnutzt.

Der konzeptionelle Rahmen dafür ist nicht neu: Das US-amerikanische NIST beschreibt in der Publikation SP 800-207 eine Zero-Trust-Architektur, die genau auf der Trennung von Policy Decision Point und Policy Enforcement Point beruht. Was bei Agenten neu ist, ist die Geschwindigkeit und Autonomie, mit der Entscheidungen fallen müssen.

Warum reicht das alte Vertrauensmodell für Agenten nicht?

Klassische Dienste sind weitgehend vorhersehbar: Ein Microservice ruft bekannte Endpunkte mit bekannten Mustern auf. Ein KI-Agent dagegen entscheidet zur Laufzeit, welches Werkzeug er aufruft – abhängig vom Prompt, vom Kontext und teils von Daten, die ein Angreifer beeinflussen kann. Eine Prompt Injection kann einen ansonsten harmlosen Agenten dazu bringen, Daten zu exfiltrieren oder Aktionen auszulösen, die nie vorgesehen waren.

Hinzu kommt das Problem stehender Berechtigungen. Erhält ein Agent einen breiten Token mit langer Gültigkeit, wird dieser Token zum Generalschlüssel. Wer ihn abgreift – über eine kompromittierte Abhängigkeit, ein durchgesickertes Protokoll oder eine manipulierte Werkzeugantwort – bewegt sich frei durch die Systeme, an die der Agent angebunden ist. In einer Architektur mit vielen kooperierenden Agenten potenziert sich dieses Risiko, weil ein gekaperter Agent andere Agenten als legitime Aufrufer missbrauchen kann.

Zero Trust antwortet darauf, indem es Vertrauen radikal verkürzt: Berechtigungen sind eng gefasst, kurzlebig und an einen nachprüfbaren Kontext gebunden. Ein gestohlener Token taugt dann höchstens für Sekunden und nur für eine eng umrissene Aktion.

Wie funktioniert kontinuierliche Verifizierung bei Agenten?

Kontinuierliche Verifizierung bedeutet, dass die Berechtigung eines Agenten nicht einmal zu Beginn, sondern fortlaufend bewertet wird. Bei jeder relevanten Aktion fließen Signale in die Entscheidung ein: Wer ist der Agent (Identität)? In wessen Auftrag handelt er (delegierter Nutzerkontext)? Welche Aufgabe verfolgt er? Wie ungewöhnlich ist diese Anfrage im Vergleich zu seinem normalen Verhalten?

In der Praxis stützt sich kontinuierliche Verifizierung auf mehrere Mechanismen, die sinnvoll zusammenspielen:

• Kurzlebige Anmeldedaten statt langlebiger Token. Ein Agent erhält ein Zugriffstoken mit Minutengültigkeit, das eng auf eine Zielressource und einen Zweck zugeschnitten ist (Audience- und Scope-Bindung).
• Kontextbindung pro Anfrage. Die Entscheidung berücksichtigt nicht nur die Identität, sondern auch den aktuellen Auftrag, den delegierenden Nutzer und die angeforderte Operation.
• Verhaltensbasierte Signale. Weicht ein Agent stark von seinem üblichen Muster ab – plötzliche Massenabfragen, untypische Zielsysteme –, kann die Richtlinie strenger greifen oder eine Bestätigung verlangen.
• Widerrufbarkeit in Echtzeit. Erkennt das System eine Anomalie, lassen sich die Anmeldedaten eines Agenten sofort entziehen, ohne dass ein Token bis zum Ablauf weiterläuft.

Wichtig ist der Unterschied zur reinen Authentifizierung. Authentifizierung beantwortet „Wer bist du?“ einmalig. Kontinuierliche Verifizierung beantwortet „Darfst du das, hier, jetzt, in diesem Kontext?“ – und zwar bei jeder Aktion erneut.

Welche Rolle spielt der Policy Decision Point?

Der Policy Decision Point ist die zentrale Instanz, die über jede Zugriffsanfrage entscheidet. Er trennt die Frage „Darf das passieren?“ sauber von der Frage „Wie wird es technisch umgesetzt?“. Diese Trennung ist das Herzstück einer belastbaren Zero-Trust-Architektur, weil sie Richtlinien aus dem Anwendungscode herauslöst und an einer Stelle prüfbar, versionierbar und auditierbar macht.

Dem PDP gegenüber steht der Policy Enforcement Point (PEP). Der PEP sitzt im Datenpfad – etwa als Sidecar-Proxy, als API-Gateway oder als Bibliothek im Agenten-Laufzeitsystem. Er fängt jede Anfrage ab, fragt den PDP nach einer Entscheidung und setzt diese durch: Er lässt die Anfrage durch, blockiert sie oder verlangt zusätzliche Schritte. Der PEP entscheidet nie selbst; er erzwingt nur, was der PDP vorgibt.

Eine typische Entscheidungskette sieht so aus:

Schritt	Komponente	Aufgabe
1. Anfrage abfangen	Policy Enforcement Point (PEP)	Aktion des Agenten im Datenpfad unterbrechen
2. Kontext sammeln	PEP / Identitätsdienst	Identität, Auftrag, Ziel, Risikosignale bündeln
3. Entscheidung treffen	Policy Decision Point (PDP)	Richtlinie auswerten: erlauben, verweigern, eskalieren
4. Durchsetzen	PEP	Entscheidung umsetzen, Aktion zulassen oder stoppen
5. Protokollieren	PDP / Audit-Log	Entscheidung samt Begründung revisionssicher ablegen

Für die Umsetzung von Richtlinien haben sich offene Werkzeuge etabliert. Der Open Policy Agent (OPA) mit der Sprache Rego ist ein verbreiteter, herstellerneutraler Ansatz, Richtlinien als Code zu formulieren und an einem PDP auszuwerten. Der Vorteil: Die Richtlinie liegt nicht verstreut in dutzenden Agenten, sondern an einer Stelle – nachvollziehbar und unabhängig vom Modell, das den Agenten antreibt.

Ein häufiger Fehler in der Praxis ist, die Entscheidungslogik in den Agenten selbst zu legen. Das wirkt schnell und bequem, untergräbt aber das gesamte Modell: Ein Agent, der über seine eigenen Rechte entscheidet, ist genau der, dem man nach Zero-Trust-Logik nicht vertrauen darf. Die Entscheidung muss außerhalb des Agenten liegen.

Wie sichert Agent-zu-Agent-mTLS die Kommunikation ab?

Sobald mehrere Agenten zusammenarbeiten, reicht es nicht, nur den Menschen am Anfang der Kette zu authentifizieren. Jeder Agent muss wissen, mit welchem anderen Agenten er gerade spricht – und umgekehrt. Genau das leistet Agent-zu-Agent-mTLS: gegenseitiges TLS, bei dem nicht nur der Server, sondern auch der Client ein Zertifikat vorweist. Beide Seiten beweisen einander kryptografisch ihre Identität, bevor Daten fließen.

Der Unterschied zum gewöhnlichen TLS ist entscheidend. Beim normalen TLS prüft nur der Client, ob der Server echt ist – wie beim Aufruf einer Webseite. Beim mutual TLS prüfen beide Seiten einander. Ein Agent kann sich nicht einfach als legitimer Aufrufer ausgeben, weil er ohne gültiges, nachprüfbares Zertifikat gar nicht zur Verbindung zugelassen wird. Das schließt eine ganze Klasse von Angriffen aus, bei denen sich ein kompromittierter Dienst als vertrauenswürdiger Gesprächspartner tarnt.

Damit das skaliert, braucht es eine saubere Identitätsbasis. Hier hat sich der offene Standard SPIFFE etabliert, mit der Referenzimplementierung SPIRE: Jeder Arbeitslast – und damit jedem Agenten – wird eine kryptografisch verifizierbare Identität (eine sogenannte SVID) zugewiesen, oft als kurzlebiges X.509-Zertifikat. Diese Identitäten werden automatisch rotiert, sodass kein Zertifikat lange genug gültig ist, um nach einem Diebstahl noch zu nützen. In Service-Mesh-Umgebungen übernehmen Werkzeuge wie Istio oder Linkerd die mTLS-Terminierung im Sidecar, sodass die Agenten selbst keinen Zertifikatscode enthalten müssen.

Wichtig ist, mTLS nicht als Ersatz für den PDP zu verstehen. mTLS beantwortet die Frage „Mit wem rede ich?“. Der Policy Decision Point beantwortet die Frage „Darf dieser Gesprächspartner das, was er gerade verlangt?”. Erst beide zusammen ergeben Zero Trust: starke Identität auf der Leitung, harte Autorisierung bei jeder Aktion.

Wie greifen die drei Bausteine zusammen?

Stellen Sie sich einen Agenten vor, der im Auftrag eines Mitarbeiters eine Rechnung in einem Buchhaltungssystem anlegen soll und dafür einen zweiten, spezialisierten Agenten aufruft.

Zuerst stellt der aufrufende Agent über mTLS eine Verbindung zum zweiten Agenten her; beide weisen ihre SPIFFE-Identität nach. Der zweite Agent weiß nun gesichert, wer ihn anspricht. Bevor er handelt, fängt der Policy Enforcement Point seine geplante Schreibaktion ab und fragt den Policy Decision Point: Darf dieser Agent, in diesem delegierten Nutzerkontext, in diesem Mandanten, eine Rechnung dieser Höhe anlegen? Der PDP wertet die Richtlinie aus und entscheidet. Parallel sorgt die kontinuierliche Verifizierung dafür, dass das verwendete Token nur Minuten gültig und genau auf diese eine Operation zugeschnitten ist.

Wird der erste Agent durch eine Prompt Injection gekapert, hilft ihm das wenig: Sein gestohlenes Token läuft binnen Minuten ab, mTLS verhindert, dass er sich als anderer Dienst ausgibt, und der PDP verweigert jede Aktion, die außerhalb der erlaubten Richtlinie liegt. Kein einzelner kompromittierter Baustein öffnet die ganze Kette.

Wie führt man Zero Trust für Agenten schrittweise ein?

Zero Trust ist kein Produkt, das man einschaltet, sondern ein Weg. Ein pragmatischer Einstieg, der den Betrieb nicht überfordert:

1. Identitäten vergeben. Geben Sie jedem Agenten eine eindeutige, verifizierbare Identität (etwa über SPIFFE/SPIRE). Ohne klare Identitäten ist jede weitere Maßnahme wirkungslos.
2. Token verkürzen. Ersetzen Sie langlebige Schlüssel durch kurzlebige, eng gefasste Anmeldedaten mit Audience- und Scope-Bindung.
3. Entscheidung zentralisieren. Führen Sie einen Policy Decision Point ein und verlagern Sie Berechtigungslogik aus den Agenten dorthin – Richtlinien als Code, versioniert und auditierbar.
4. Durchsetzung im Datenpfad verankern. Setzen Sie Policy Enforcement Points als Gateway oder Sidecar ein, sodass keine Aktion am PDP vorbeikommt.
5. mTLS zwischen Agenten erzwingen. Aktivieren Sie gegenseitiges TLS für die Agent-zu-Agent-Kommunikation, idealerweise über ein Service Mesh, das Zertifikate automatisch rotiert.
6. Beobachten und nachschärfen. Protokollieren Sie jede Entscheidung revisionssicher, werten Sie Anomalien aus und verfeinern Sie die Richtlinien iterativ.

Wer in dieser Reihenfolge vorgeht, baut Sicherheit von unten auf: erst Identität, dann knappe Rechte, dann zentrale Entscheidung, dann gesicherte Leitung. Jede Stufe bringt für sich genommen schon einen Gewinn an Kontrolle.

Was bedeutet das für Compliance im DACH-Raum?

Für Organisationen im deutschsprachigen Raum kommt eine regulatorische Dimension hinzu. Verarbeiten Agenten personenbezogene Daten, verlangt die DSGVO nachvollziehbare Zugriffe und das Prinzip der Datenminimierung – beides deckt sich gut mit Zero Trust: enge Berechtigungen, revisionssichere Entscheidungsprotokolle und der Nachweis, wer wann was im Auftrag von wem getan hat. Auch die EU-KI-Verordnung rückt Protokollierung und menschliche Aufsicht in den Vordergrund. Ein zentraler Policy Decision Point mit lückenlosem Audit-Log liefert genau die Belege, die solche Anforderungen verlangen.

Zero Trust für Agenten ist damit kein reines Sicherheitsthema, sondern zunehmend eine Voraussetzung dafür, autonome KI-Systeme im regulierten Umfeld überhaupt verantwortbar zu betreiben.