Prompts sind keine Sicherheitsgrenze: Zero Trust für KI-Agenten

Der fünfte jährliche Bericht „Horizons of Identity Security“ von SailPoint, eine Umfrage unter 340 Führungskräften aus Identity-Management, IT, Sicherheit und Risikomanagement, kommt zu dem Ergebnis, dass 79 % der Unternehmen KI-Agenten produktiv betreiben, während 2 % Werkzeuge für Identity Security eingeführt haben, die eigens für die Governance dieser Agenten gebaut sind. Neunundsiebzig zu zwei: SailPoint spricht von einer 40-fachen Lücke zwischen Einführung und Readiness.

In seinem Vortrag „Zero Trust Agent Systems that Pass Audits and Still Ship“ auf der QCon AI Boston geht Advait Patel, Senior Site Reliability Engineer bei Broadcom, von einer Prämisse aus, die die meisten Teams in Unternehmen kennen, aber selten offen aussprechen: Prompts sind keine verlässliche Sicherheitsgrenze. Der Schadensradius (Blast Radius) eines Agenten liegt auf der Tool-Ebene, wo er APIs aufruft, Datenbanken liest und Aktionen auslöst. Genau dort müssen deshalb Authentifizierung, Autorisierung und eng zugeschnittene Berechtigungen durchgesetzt werden.

Patels Einordnung ist nützlich, weil sie konkret ist. Er nennt vier Risiken im Produktivbetrieb: Prompt Injection über Tool-Ausgaben; schleichende Rechteausweitung (Privilege Creep), wenn ein Agent Tools ansammelt, die niemand prüft; unsicheres Retrieval, das Mandanten- und Vertraulichkeitsgrenzen überschreitet; und Aktionsverstärkung (Action Amplification), bei der eine einzige vage Anfrage viele folgenreiche Tool-Aufrufe auslöst. Daraus folgen zwei weitere: Aktionen, die niemand nachvollziehen kann, und eine zu langsame Reaktion auf Vorfälle.

Nichts davon ist Theorie. Salt Security hat mehr als 380 Organisationen befragt: 49,8 % bestätigten oder vermuteten, dass ein Agent in den zwölf Monaten vor der Befragung eine unbeabsichtigte oder nicht autorisierte Aktion ausgeführt hat. Nur 12,5 % können den vollständigen Pfad eines Agenten durchgängig nachverfolgen, und nur 17,5 % können einen Agenten automatisch stoppen, der sich unerwartet zu verhalten beginnt.

Diese Zahlen sollten jeden beunruhigen, der in einem regulierten Umfeld Verantwortung für Integrationsarchitektur trägt. Wenn Sie nicht nachvollziehen können, was ein Agent getan hat, und ihn nicht stoppen können, wenn er sich falsch verhält, haben Sie kein System für den Produktivbetrieb. Sie haben ein Haftungsrisiko mit API-Schlüssel.

1. Identität. Jeder Agent und, wo nötig, jede Sitzung erhält eine eigene Identität (Workload Identity auf GCP, IAM-Rollen auf AWS) statt gemeinsam genutzter Zugangsdaten, sodass sich jede Aktion genau einem Agenten und einem Benutzer zuordnen lässt.
2. Tools. Jedes Tool hat eine eigene Identität, eine eigene Autorisierung, Rate Limits sowie Kontrollen für Ein- und Ausgaben und wird mit kurzlebigen Tokens aufgerufen, die auf die jeweilige Aufgabe beschränkt sind.
3. Kontext und Retrieval. Zugriffsregeln werden pro Dokument zum Zeitpunkt der Abfrage durchgesetzt, nicht dadurch, dass man das Modell bittet, sich an die Regeln zu halten.
4. Policy und Entscheidung. Eine eigenständige Engine (OPA, Cedar oder Ihre eigenen Regeln) steht zwischen dem, was der Agent vorhat, und dem, was tatsächlich ausgeführt wird, und protokolliert jede Entscheidung.
5. Audit und Nachweis. Strukturierte Traces pro Aktion, verknüpft mit Identität und Sitzung, zeigen, worauf der Agent zugegriffen und was er getan hat.

Das ist eine Steuerungsebene (Control Plane), kein Schaubild für die Wand. Wer wie wir seit Jahren vertritt, dass die Integrationsschicht die Control Plane des Unternehmens ist, kann die Parallele kaum übersehen. Agentensysteme erben die strukturellen Probleme jeder Integrationslandschaft: Routing, Fallback, Observability, die Frage, wer um 02:00 Uhr zuständig ist. Der Unterschied: Agenten können schneller handeln, als Menschen prüfen können, und deshalb muss die Prüfung außerhalb des Modells liegen. Damit haben wir uns in einem eigenen Beitrag befasst: deterministische Gates gegen stille Policy-Verstöße.

Ein Großteil des Aufwands für die Absicherung von Agenten fließt in Prompt Engineering, Guardrails für das Modellverhalten und Eingabevalidierung. Patel hält das nicht für ausreichend. Über Tool-Ausgaben lassen sich Anweisungen in Prompts einschleusen. Berechtigungen sammeln sich unbemerkt an. Daten überschreiten beim Retrieval Mandantengrenzen. Die Durchsetzung muss dort stattfinden, wo der Agent handelt.

Das deckt sich mit einem Grundsatz, den Integrationsarchitekten gut kennen: Punkt-zu-Punkt-Vertrauen ist genau einmal billig. Danach zahlen Sie Zinsen in Form von Vorfällen, Ausnahmen und unangenehmen Runden im Lenkungsausschuss. Eng zugeschnittene Tokens, Least Privilege auf der Tool-Ebene und Allowlists für destruktive Aktionen sind für Agenten das Gegenstück zu der Governance, die wir bereits auf APIs und Service-Verträge anwenden, und ein Gateway vor dem Modell und seinen Tools ist ein naheliegender Ort, um sie durchzusetzen; mehr dazu in unserer Betrachtung eines KI-Gateways als Kontrollpunkt. Was sich ändert, ist die Geschwindigkeit: Ein Agent kann Dutzende Tool-Aufrufe in Sekunden aneinanderreihen, sodass schleichende Rechteausweitung und Aktionsverstärkung schneller eintreten, als irgendeine menschliche Freigabeschleife sie abfangen könnte.

Patels Kontrollen sind konkret. Behandeln Sie Tool-Ausgaben als nicht vertrauenswürdig und bereinigen Sie sie. Setzen Sie ACLs zum Zeitpunkt der Abfrage durch. Stufen Sie destruktive Aktionen nach ihrem Schadensradius ab, mit einem Probelauf (Dry Run) oder einer ausdrücklichen Bestätigung für die höchste Stufe. Und bauen Sie den Kill Switch, bevor der Vorfall eintritt. In der Praxis heißt das, das Token eines Agenten sofort widerrufen zu können. Ein Kill Switch ist keine Paranoia, sondern betriebliche Hygiene.

Der übliche Einwand lautet, Governance bremse die Auslieferung. Patel kehrt ihn um: Auditfähigkeit, die über strukturierte Traces und Entscheidungsprotokolle vom ersten Tag an eingebaut ist, verringert die Reibung mit der Zeit. Ohne Traces wird die Untersuchung eines Vorfalls zur Archäologie. Mit ihnen können Sie einem Auditor zeigen, worauf der Agent zugegriffen hat, welche Policy für jede Aktion maßgeblich war und wie weit der Schaden hätte reichen können. Genau dieser Nachweis erlaubt es Ihnen, die nächste Iteration ohne dreiwöchige Prüfung auszuliefern. Wie sich ein Trace durch APIs, Queues, Workflow-Engines und Modellaufrufe ziehen lässt, beschreibt unser Leitfaden zu Trace-IDs.

Was auf dem Spiel steht, ist bereits sichtbar. Am 21. Oktober 2026 ordnete Microsoft die Kompromittierung von ConnectWise Cloud Backup dem Akteur zu, den das Unternehmen als Storm-0940 führt. Laut Microsoft nutzte dieser Akteur ARTEX, ein Open-Source-Framework für Penetrationstests, das sich von jedem beliebigen KI-Modell steuern lässt, um Aufklärung, Password Spraying und den Missbrauch von OAuth-Anwendungszugriffen zu beschleunigen. Dazu gehörten Anmeldeversuche bei mehr als 2.250 Mandanten. Die Grundursache waren nach wie vor kompromittierte Zugangsdaten und vertrauenswürdige Integrationen; die agentischen Werkzeuge machten die Angriffskette schneller. Wenn Angreifer sich automatisiert durch Ihre Integrationslandschaft arbeiten, sind Least Privilege, starke Anwendungsidentitäten und Monitoring rund um Integrationen kein theoretischer Business Case mehr.

Patels praktischer Rat: Wählen Sie einen wertvollen Anwendungsfall mit kleinem Schadensradius. Beginnen Sie mit Logging, noch vor jeder Policy-Engine, denn was Sie nicht beobachten können, können Sie nicht kontrollieren. Lassen Sie den Agenten mindestens zwei Wochen im Schattenmodus (Shadow Mode) laufen, bevor Sie sich auf ihn verlassen. Und binden Sie das SOC früh ein, denn dort geht der erste Alarm ein. Beschränken Sie die menschliche Freigabe auf destruktive Aktionen. Eine Freigabe für alles ist eine Kontrolle, die niemand auf Dauer durchhält.

Die Umfragedaten, der Bedrohungsbericht und die Architektur weisen in dieselbe Richtung: Agentenidentität, Autorisierung auf der Tool-Ebene, kurzlebige Zugangsdaten und durchgängige Traces sind die Mindestanforderung für den Produktivbetrieb, keine Kür für reife Organisationen.

Nehmen Sie einen Agenten, der produktiv läuft, und beantworten Sie drei Fragen. Unter welcher Identität läuft er, und ist es seine eigene? Welche Tools kann er aufrufen, mit welchen Berechtigungen, und wie lange ist sein Token gültig? Können Sie den Trace seiner letzten zehn Aktionen vorlegen und ihn innerhalb von Minuten stoppen? Jede Frage, die Sie nicht beantworten können, ist der nächste Eintrag im Backlog.

Führt der Agent Aktionen in Unternehmenssystemen aus, ist das die Arbeit, die wir in der Entwicklung von KI-Agenten leisten: Agenten, die über Ihre Integrationsschicht handeln, mit eng zugeschnittenen Berechtigungen, auditiertem Tool-Zugriff und einem Menschen an den Kontrollpunkten, auf die es ankommt.