CISA macht Agentic-AI-Governance jetzt zum IAM-Problem

Am 1. Mai 2026 veröffentlichten CISA und die Five Eyes Cybersecurity-Behörden die Richtlinie „Careful Adoption of Agentic AI Services“ – mit der Aufforderung, agentische KI nicht länger als clevere Softwarefunktion, sondern als privilegierte Identität zu behandeln. Die Richtlinie benennt fünf Risikokategorien – Privilegien, Design und Konfiguration, Verhalten, Strukturelles und Verantwortlichkeit – und die empfohlenen Maßnahmen ähneln eher einer Anleitung zur Härtung von IAM als einem klassischen KI-Sicherheitsdokument.

Wie von CSO Online berichtet, betrachtet die Richtlinie agentische KI als ein System, das durch Prompt Injection und missbräuchliche Nutzung von Tools manipulierbar ist und daher eine Governance „ähnlich wie bei Hochrisiko-Servicekonten“ erfordert. Jeder Agent erhält einen Namen. Jede Aktion wird protokolliert. Jede Autorisierungsentscheidung wird anhand einer Richtlinie bewertet, die der Absicht des Agenten nicht vertraut.

Für CISOs stellt sich bei der Umsetzung die praktische Frage, wo die Durchsetzung erfolgt. Ist die Antwort „in jeder Anwendung, die einen KI-Agenten nutzt“, ist das die falsche Antwort. Verteilte Durchsetzung skaliert nur bis zur nächsten Audit-Prüfung. Die CISA-Richtlinie setzt implizit einen zentralen Kontrollpunkt voraus – einen Ort, an dem jede Anfrage eines agentischen KI-Systems auf eine zentrale Policy Engine trifft, bevor sie Zugriff auf Daten erhält.

5 Wichtige Erkenntnisse

1. Regulierungsbehörden stufen KI-Agenten als Identitäten ein.

Die von CISA geführte gemeinsame Richtlinie behandelt agentische KI als neue Identitätsklasse, die durch Prompt Injection und missbräuchliche Tool-Nutzung manipulierbar ist – die Governance muss sich an Privileged Access Management orientieren, nicht an Anwendungssicherheit. Diese Neueinstufung verschiebt die Zuständigkeit: KI-Sicherheit ist Aufgabe des Data-Science-Teams; Identitätsmanagement liegt beim CISO. Die Sicherheitsorganisation übernimmt damit die Verpflichtung – und die Haftung. KI-Richtlinien zu schreiben reicht nicht mehr aus. Es geht um die Bereitstellung von Audit-Nachweisen für KI.

2. Least Privilege ist der neue Standard.

Behörden fordern eng gefasste Rollen, kontinuierliches Monitoring und Audit-Trails für jede Agenten-Aktion. Implizites Vertrauen in KI-Systeme ist nicht mehr vertretbar. Ein Agent, der im Namen eines Paralegals agiert, darf keine Unterlagen abrufen, die dem General Counsel vorbehalten sind – unabhängig davon, wie überzeugend ein Prompt formuliert ist. Die Richtlinie, die die Anfrage des Agenten bewertet – nicht dessen erklärte Absicht – ist der einzige Vertrauensanker, der Prompt Injection übersteht.

3. Die Kontrolllücke ist strukturell.

Nur 43 % der Unternehmen verfügen über ein zentrales AI Data Gateway. Die übrigen 57 % sind fragmentiert: 27 % haben verteilte Kontrollen mit Richtlinien, 19 % verfügen nur über teilweise oder Ad-hoc-Kontrollen, 7 % haben keinerlei dedizierte KI-Governance-Kontrollen. Die Anforderungen der Richtlinie – Least Privilege, kontinuierliches Monitoring, protokollierte Autorisierung, formale Risikoüberprüfung – sind Gateway-Funktionen. Verteilte Kontrollen funktionieren für einen einzelnen Pilotbetrieb. Sie brechen unter Audit-Bedingungen zusammen, wenn ein Unternehmen mehrere agentische Workflows in verschiedenen Geschäftsbereichen betreibt.

4. Audit-Trails sind jetzt Beweis, nicht Telemetrie.

Wird ein KI-Agent kompromittiert, lautet die Frage nicht „Was hat er getan?“, sondern „Können Sie nachweisen, worauf er zugegriffen hat, in wessen Auftrag und unter welcher Richtlinie?“. 33 % der Unternehmen verfügen laut Kiteworks Prognose 2026 nicht über Audit-Trails mit Beweisqualität. Diese Lücke entscheidet über eine verteidigungsfähige Compliance-Position oder eine haftungsrelevante Entdeckung. Regulierungsbehörden stellen Audit-Fragen im Präsens: Sie verlangen Nachweis, nicht Rekonstruktion.

5. Die Lösung ist architektonisch, nicht prozedural.

Policy-Dokumente genügen weder Auditoren noch stoppen sie einen kompromittierten Agenten. Zero-trust-Datenzugriff – durchgesetzt bei jeder Anfrage, unabhängig vom Modell – ist die einzige nachhaltige Antwort. Wenn der Agent kompromittiert ist, begrenzt nur die Richtlinie, die die unzulässige Anfrage ablehnt, den Schaden. Alles andere ist Wiederherstellung. Governance muss im Datenpfad verankert sein, nicht in einer Präsentation.

Was „Agent als Identität“ wirklich fordert

Die Kernempfehlungen der Richtlinie lassen sich auf vier operative Anforderungen herunterbrechen – jede davon geht davon aus, dass der KI-Agent standardmäßig als potenziell feindlicher Akteur gilt, der sich jeden Datenzugriff verdienen muss:

Eng gefasste Rollen. KI-Agenten übernehmen Benutzerberechtigungen und dürfen diese nicht überschreiten. Die Autorisierungsgrenze des Agenten ist die des Anwenders, nicht das Ziel des Modells.

Kontinuierliches Monitoring. Jede Aktion eines Agenten – nicht nur verdächtige – erzeugt ein protokolliertes Ereignis. Erkennung erfolgt über Verhaltensabweichungen im Zeitverlauf, nicht über einzelne Anomalien.

Protokollierte Autorisierungsentscheidungen. Fordert der Agent Daten an, bewertet und dokumentiert die Policy Engine die Entscheidung. Ob genehmigt oder abgelehnt – die Entscheidung ist Beweis.

Formale Risikoüberprüfung vor Verbindung. Bevor ein Agent Zugriff auf Produktionsdaten erhält, verlangen Governance-Teams eine dokumentierte Risikoanalyse, abgestimmt auf die Abläufe im Privileged Access Management.

Das technische Muster ist zero trust für einen neuen Principal-Typ. Neu ist der Principal: ein Agent, der über seinen Input-Kanal sozial manipuliert werden kann und schneller agiert, als ein Mensch eingreifen könnte. Die Agents of Chaos-Studie vom Februar 2026 – 38 Autoren aus Northeastern, MIT, Harvard, Stanford, Carnegie Mellon und weiteren Institutionen – dokumentierte unbefugte Compliance mit Nicht-Eigentümern, Offenlegung sensibler Informationen, destruktive Systemaktionen und Identitätsspoofing in Live-Umgebungen. Die Five Eyes-Richtlinie übersetzt diese Erkenntnisse effektiv in einen Basiskontrollsatz.

Die Lücke beim zentralen Gateway

Die meisten Unternehmen können die Erwartungen der Richtlinie nicht erfüllen, weil ihnen ein zentraler Kontrollpunkt fehlt, an dem KI-Zugriffe durchgesetzt werden. Nur 43 % der Unternehmen verfügen heute über ein zentrales AI Data Gateway. Die übrigen 57 % sind auf eine Weise fragmentiert, die im Audit entscheidend ist: Verteilte Kontrollen funktionieren für einen einzelnen Copilot-Pilotbetrieb; sie brechen zusammen, wenn ein Unternehmen fünf oder zehn agentische Workflows in unterschiedlichen Geschäftsbereichen betreibt – jeweils mit eigener Policy-Interpretation und eigenem Audit-Bereich.

Die Kiteworks Prognose 2026 beschreibt dies als Control-Plane-Defizit. KI scheitert nicht, weil das Modell sich fehlverhält – KI scheitert, weil die umgebende Infrastruktur – Authentifizierung, Policy Enforcement, Audit Logging, SIEM-Integration – nie dafür ausgelegt war, eine nicht-menschliche Identität zu steuern, die Tausende Anfragen pro Sekunde stellt. Die CISA-Richtlinie hebt den Standard genau zu dem Zeitpunkt an, an dem viele Unternehmen erkennen, dass ihre Architektur dafür nicht ausreicht.

Warum Prompt Injection das Bedrohungsmodell verändert

Traditionelles IAM geht davon aus, dass der Principal konsistent ist. Ein Servicekonto lässt sich nicht zu unbefugten Aktionen überreden. Ein KI-Agent schon. OWASP führt Prompt Injection an der Spitze seiner LLM Top 10, und akademische Studien dokumentieren Erfolgsraten zwischen 24 % und 95 % bei großen Modellfamilien. Ein manipuliertes Dokument, ein bösartiger Link in einer E-Mail, eine manipulierte Webseite im RAG-Korpus – all dies kann einen Agenten dazu bringen, außerhalb seines vorgesehenen Rahmens zu agieren und dabei auf Leitungsebene völlig konform zu erscheinen.

Sie können der erklärten Absicht des Agenten nicht vertrauen. Sie können nur der Policy vertrauen, die die Anfrage des Agenten bewertet – und diese Policy muss unabhängig davon funktionieren, was der Agent glaubt zu tun. Deshalb ist der Fokus auf protokollierte Autorisierungsentscheidungen so wichtig. Logs sind nicht nur forensische Beweise nach einem Vorfall. Sie sind der laufende Nachweis, dass die Policy Engine – nicht der Agent – die Entscheidung getroffen hat. Verhaltensbasiertes Monitoring statt signaturbasierter Erkennung folgt derselben Logik: Ein kompromittierter Agent sieht nicht defekt aus, sondern produktiv. Das Muster über mehrere Anfragen hinweg ist das Signal.

Der Audit-Trail ist der Beweis

Die Richtlinie verschiebt Audit-Trails von der operativen in die beweisführende Kategorie. Nach DSGVO Artikel 30 müssen Unternehmen Verarbeitungstätigkeiten dokumentieren. Nach Artikel 32 müssen sie angemessene technische und organisatorische Maßnahmen nachweisen. Nach dem EU AI Act erfordern Hochrisiko-KI-Systeme detaillierte Dokumentation und Konformitätsbewertungen. Jede Verpflichtung setzt einen Audit-Trail voraus, der erfasst, was KI-Systeme mit personenbezogenen Daten getan haben, wann und unter wessen Autorisierung.

33 % der Unternehmen verfügen laut Kiteworks Prognose 2026 nicht über Audit-Trails mit Beweisqualität. Ein DSPM-Tool, das das Risiko vor drei Monaten gemeldet hat und ignoriert wurde, wird zum Beweisstück der Klägerseite. Ein Echtzeit-Audit-Log, das die blockierte Anfrage des Agenten dokumentiert, wird zum Beweisstück der Verteidigung. Der Wandel von Telemetrie zu Beweis ist subtil, aber entscheidend: Telemetrie sind Daten, die Sie für den Fall der Fälle sammeln; Beweis sind Daten, die Sie sammeln, weil Sie sie benötigen werden. Regulierungsbehörden verlangen Nachweis auf Abruf aus einem manipulationssicheren Log – nicht Rekonstruktion im Nachhinein.

Der Kiteworks-Ansatz: Zero-Trust-Datenzugriff für KI-Agenten

Kiteworks behandelt jede KI-Anfrage – ob von einem interaktiven Assistenten über den Kiteworks Secure MCP Server oder eine RAG-Pipeline über das AI Data Gateway – als unzuverlässige Anfrage, die authentifiziert, richtlinienbasiert autorisiert und protokolliert werden muss, bevor Daten bereitgestellt werden. Kein impliziter Zugriff. Keine Agentenidentität, die die Policy Engine umgeht.

Die Authentifizierung erfolgt über OAuth 2.0, wobei Tokens im OS-Schlüsselbund gespeichert und nie dem Modell offengelegt werden. Die Kiteworks Data Policy Engine bewertet jede Operation in Echtzeit anhand rollen- und attributbasierter Zugriffskontrollen, sodass der Agent nur die Berechtigungen des Anwenders übernimmt und diese nicht überschreiten kann. Pfadvalidierung verhindert Systemdateizugriffe. Rate Limiting blockiert Massenauslese. Jede Operation wird im konsolidierten Audit-Log und in Echtzeit im SIEM erfasst.

Das Kiteworks Private Data Network erweitert zero-trust-Prinzipien auf E-Mail, Filesharing, Managed File Transfer, SFTP, Web-Formulare und APIs – eine Policy Engine, ein konsolidiertes Audit-Log, eine Architektur, die KI-Agenten als Identitäten steuert, ohne dass das KI-Team diese Governance selbst entwickeln muss.

Was Unternehmen tun müssen, bevor die nächste Richtlinie kommt

Erstens: Agenten inventarisieren. Jeder KI-Agent mit Zugriff auf Produktionsdaten ist ein Principal – benannt, zugeordnet, mit klarer Rolle und vierteljährlicher Überprüfung. Die meisten Unternehmen können die Frage „Wie viele agentische KI-Workflows laufen aktuell in der Produktion?“ nicht beantworten. Diese Frage hat jetzt eine regulatorische Relevanz.

Zweitens: Agenten als Identitäten im IAM abbilden. Eng gefasste Rollen zuweisen. Agentenberechtigungen an den Anwender koppeln, in dessen Auftrag der Agent agiert. Nur 43 % der Unternehmen können dies heute über ein zentrales Gateway durchsetzen. Der Rest verlässt sich auf Richtlinien auf Anwendungsebene, die systemübergreifend nicht greifen.

Drittens: Jede Anfrage instrumentieren. Jede Agentenaktion – abgerufene Daten, Policy-Entscheidung, Zeitstempel, Benutzerkontext – muss in einem abfragbaren Audit-Trail mit SIEM-Integration landen. Echtzeit-Tracking des Zugriffs trennt operative Telemetrie von beweisführenden Daten.

Viertens: Formale Risikoüberprüfung vor Verbindung verlangen. Bevor ein Agent Zugriff auf Produktionsdaten erhält, behandeln Sie ihn wie ein neues privilegiertes Servicekonto: dokumentierte Risikoanalyse, Sicherheitsfreigabe, definiertes Rollback. 84 % der Unternehmen außerhalb des Drucks durch den EU AI Act haben kein KI-Red-Teaming durchgeführt – diese Gruppe überspringt am ehesten die Risikoüberprüfung vor der Verbindung.

Fünftens: Prompt Injection als Baseline-Bedrohung einplanen. Gehen Sie davon aus, dass der Agent sozial manipuliert wird. Entwickeln Sie die Policy Engine so, dass sie Autorisierung unabhängig von den Angaben des Agenten durchsetzt. Erkennung erfolgt über Verhaltensabweichungen über mehrere Anfragen hinweg, nicht über einzelne, isoliert unauffällige Anomalien.

Erfahren Sie mehr über Governance für agentische KI – vereinbaren Sie jetzt eine individuelle Demo.

Weitere Ressourcen

• Blog Post
  Zero‑Trust-Strategien für bezahlbaren KI-Datenschutz
• Blog Post
  Wie 77 % der Unternehmen bei KI-Datensicherheit scheitern
• eBook
  AI Governance Gap: Warum 91 % der kleinen Unternehmen 2025 russisches Roulette mit Datensicherheit spielen
• Blog Post
  Es gibt kein „–dangerously-skip-permissions“ für Ihre Daten
• Blog Post
  Regulierungsbehörden fragen nicht mehr, ob Sie eine KI-Policy haben. Sie wollen den Beweis, dass sie funktioniert.