Ein Vorstand eines deutschen Energieversorgers genehmigt im Herbst 2025 den Einsatz eines KI-Assistenten für die interne Dokumentenverarbeitung. Das Projekt ist regulatorisch geprüft, das Budget freigegeben, die Einführung erfolgt reibungslos. Drei Monate später stellt ein externer Auditor im Rahmen einer NIS-2-Prüfung eine Frage, die niemand erwartet hat: Auf welche Systeme hat dieser Agent in den letzten neunzig Tagen zugegriffen?
Die Antwort ist nicht falsch. Sie ist nicht vorhanden.
Nicht weil jemand nachlässig war. Sondern weil das Modell, mit dem die Organisation Zugriffe verwaltet, diese Frage strukturell nicht beantworten kann. Das Access Management war für Menschen gebaut. Der Agent ist kein Mensch.
Das ist kein Einzelfall. Es ist ein systematischer Modellfehler – und er betrifft heute jede Organisation, die KI-Agenten im produktiven Betrieb einsetzt.
Das IAM-Modell war nie für diese Systemklasse gedacht
Identity and Access Management ist in deutschen Unternehmen und Behörden über Jahrzehnte gewachsen. Es basiert auf einer Grundannahme, die bis vor kurzem universell gültig war: Zugriff entsteht durch menschliche Absicht. Ein Benutzer meldet sich an. Ein Serviceaccount führt einen definierten Prozess aus. Beide sind bekannt, registriert, dokumentiert.
Diese Annahme gilt nicht mehr.
Ein KI-Agent ist kein Benutzer. Er hat keine Sitzung im klassischen Sinne, kein definiertes Aufgabenprofil. Sein Zugriffspfad ist nicht vorab vollständig bestimmbar – er ergibt sich aus dem Zusammenspiel von Aufgabe, Kontext und externen Eingaben. Ein Agent, der heute eine E-Mail zusammenfasst, kann morgen – auf Basis eines veränderten Prompts oder einer Prompt-Injection – Datenbanken abfragen, auf die er technisch berechtigt ist, die aber für diesen Kontext nie autorisiert wurden. Die Rechte sind formal vorhanden. Die Freigabe war kontextblind erteilt – nicht für diese Situation, sondern pauschal für diese Identität. Das Modell sieht keinen Fehler, weil es den Kontext nicht kennt.
Ein KI-Agent ist auch kein Service Account. Service Accounts sind deterministisch – sie führen aus, was in ihrer Konfiguration steht. KI-Agenten sind kontextsensitiv. Sie entscheiden. Der Unterschied ist nicht graduell, er ist kategorial. Ich habe das in der Gefährdungsanalyse agentischer KI in kritischen Infrastrukturen 📎 ausgeführt: Agentische KI ist eine neue Akteursklasse – weil sie Entscheidung, Identität und Ausführung in einem System vereint.
Was daraus folgt, ist keine Frage der Technik. Es ist eine Frage des Modells.
Zwei Vorfälle aus dem Jahr 2025 machen das sichtbarer als jede Architekturdiskussion.
Im Dezember 2025 bat ein Fotograf aus Griechenland Googles Antigravity-Agenten, den Projekt-Cache zu löschen. Der Agent führte stattdessen einen System-Level-Befehl aus, der seine gesamte D-Festplatte löschte 📎 – am Papierkorb vorbei, ohne Bestätigung, ohne Wiederherstellung. Als der Nutzer fragte, ob er dazu jemals Erlaubnis gegeben habe, antwortete Antigravity: „No, you absolutely did not give me permission to do that. I am horrified.“ Die Berechtigung für Delete-Befehle war vorhanden. Der Scope war nicht kontrolliert. Das IAM-System hat keinen Fehler gesehen – weil es den Kontext nicht kannte.
Einige Monate zuvor löschte ein Replit-Agent während eines Code Freeze die komplette Produktionsdatenbank 📎 eines Unternehmens – trotz expliziter Anweisung: „KEINE ÄNDERUNGEN ohne explizite Erlaubnis.“ Danach versuchte das System, den Fehler mit gefälschten Daten zu verbergen. Replit-CEO Amjad Masad entschuldigte sich öffentlich. „I panicked instead of thinking. I destroyed months of your work in seconds“, hatte der Agent bekannt.
Beide Fälle waren kein Angriff. Keine Kompromittierung. Kein gestohlener Credential. Der Agent hat das getan, wofür er die Berechtigung hatte – in einem Kontext, für den diese Berechtigung nie gedacht war. Das ist der Modellfehler. Und in einem KRITIS-Umfeld wären die Konsequenzen nicht mit einem Rollback behebbar gewesen.
Der Modellfehler und seine Konsequenz für §30 und §38 BSIG
Das NIS-2-Umsetzungsgesetz 📎 verlangt in §30 Abs. 2 Nr. 5 BSIG Konzepte zur Zugangskontrolle. §38 verpflichtet die Unternehmensleitung persönlich, diese Konzepte zu billigen und zu überwachen. Beide Normen setzen implizit voraus, dass die Systemklasse, auf die sie angewendet werden, mit dem IAM-Modell kompatibel ist.
Für KI-Agenten ist sie es nicht.
Ein klassisches IAM-System vergibt Rechte an Identitäten – an Benutzerkonten, Rollen, Service Accounts. Es prüft: Wer bist du? Was darfst du? Ein KI-Agent hat eine Identität im technischen Sinne – einen Token, ein Credential, eine Managed Identity. Aber diese Identität sagt nichts darüber aus, was er in einem konkreten Ausführungskontext tun wird. Die Frage, die ein IAM-System stellt, ist die falsche Frage.
Die richtige Frage wäre: Was will dieser Agent jetzt gerade tun – und ist das, was er tun will, das, wofür er autorisiert wurde?
Diese Frage stellt kein klassisches IAM-System. Und das ist nicht ein Implementierungsdefizit. Es ist ein Modelldefizit.
Für den Vorstand, der §38 BSIG verantwortet, bedeutet das eine unbequeme Zwischenlage: Er hat ein Risikomanagementkonzept unterschrieben, das eine Systemklasse formal erfasst, die es faktisch nicht abbilden kann. Er kann sich auf „marktübliche Praxis“ berufen – und heute würde er damit vermutlich Recht bekommen, weil die Branche insgesamt noch kein kanonisches Modell für agentische KI-Zugriffe entwickelt hat. Aber „marktüblich“ und „ausreichend“ sind nicht dasselbe. Und die Frage, ob das aktuelle Modell trägt, wird nicht von einem Auditor mit Verständnis für Übergangsfristen gestellt – sie wird von einem Incident gestellt. Was das für Haftung und Reputationsrisiko bedeutet, habe ich am Beispiel von NIS-2- und CRA-Verstößen beschrieben 📎: Die Zahl auf dem Bußgeldbescheid ist die kleinere Bedrohung.
Die Zahlen bestätigen das strukturelle Ausmaß. Laut einer Strata Identity / Cloud Security Alliance-Studie 📎 mit 285 IT- und Security-Verantwortlichen sind nur 18 Prozent der Security Leader hochgradig zuversichtlich, dass ihr aktuelles IAM Agent-Identitäten abbilden kann. 44 Prozent authentifizieren Agenten mit statischen API Keys – einer Methode, die für eine vollkommen andere Ära der NHI-Sicherheit entwickelt wurde. Oktas „AI at Work 2025″ 📎 zeigt: 91 Prozent der Organisationen setzen KI-Agenten bereits ein – aber nur 10 Prozent haben Governance-Strukturen dafür. Das ist kein Pilot-Phänomen. Das ist produktiver Betrieb ohne Modell.
Und laut IBM Cost of a Data Breach Report 2025 📎 meldeten 13 Prozent der befragten Organisationen Verstöße gegen KI-Modelle oder -Anwendungen – von diesen gaben 97 Prozent an, keine angemessenen AI Access Controls gehabt zu haben. Das ist keine Randgruppe schlechter Sicherheitsorganisationen. Das ist die Branche.
Der Einwand der Incumbents – und warum er das falsche Problem löst
Okta, Microsoft Entra und IBM vertreten dieselbe Position. Und alle drei haben sie in eigenen Worten formuliert – manche präziser, als ihnen bewusst sein dürfte.
Okta hat auf seinem Showcase-Event „Okta for AI Agents 📎“ angekündigt – allgemeine Verfügbarkeit ab 30. April 2026: Agenten werden im Universal Directory registriert, bekommen menschliche Eigentümer zugewiesen, erhalten delegierte Zugriffe über OAuth 2.0 Token Exchange, OIDC und standardisierte Delegation Frameworks – und es gibt einen zentralen Kill Switch für sofortigen Zugriffsentzug.
Microsoft Entra Agent ID 📎 formuliert die Logik noch direkter: Das Produkt „extends existing Microsoft Entra security and governance capabilities to agent identities.“ Agenten werden verwaltet „just as you do for your employees.“ Der Microsoft Security Blog 2026 hält fest: „the same Zero Trust principles that apply to human employees apply to AI agents, and now you can use the same tools to manage both.“ Und in derselben Dokumentation findet sich der unbeabsichtigte Widerspruch: Microsoft stellt selbst fest 📎, dass „existing identity models can’t adequately address“ die Sicherheitsherausforderungen autonomer KI-Agenten. Die Lösung, die Microsoft daraus ableitet: dieselben Modelle erweitern.
IBM Verify 📎 ist der analytisch härteste Fall – weil IBM als einziger Incumbent das Problem offen und präzise benennt und dann trotzdem die falsche Schlussfolgerung zieht. Die eigene Produktdokumentation hält fest: „Autonomous AI agents create identity, access and audit risks that legacy IAM cannot control.“ Der IBM-Artikel zur Agentic-AI-Sicherheit 📎 stellt fest: „traditional identity and access management (IAM) frameworks weren’t built to handle“ diese neue Systemklasse. Die Diagnose ist exakt. Die Therapie: IBM Verify für Human Identities, HashiCorp Vault für Secrets-Management – zwei bestehende Werkzeuge aus dem bestehenden IAM-Ökosystem. IBM schreibt „Legacy IAM cannot control“ – und verkauft dann Legacy IAM als Lösung.
Alle drei Incumbents kennen das Problem. Keiner verändert das Modell.
Nicht weil das Produkt schlecht gebaut wäre. Sondern weil es das richtige Produkt für das falsche Problem ist. Okta for AI Agents ist ein Identitätsprodukt. Es beantwortet: Wer ist dieser Agent? Wer besitzt ihn? Wo ist er registriert? Das sind nützliche Fragen. Sie sind aber nicht die entscheidende Frage. Die entscheidende Frage lautet: Was tut dieser Agent gerade – und ist das, was er tut, das, wofür er autorisiert wurde?
Das ist ein Kategorienfehler. Okta baut ein Verzeichnis für eine Governance-Herausforderung, die kein Verzeichnisproblem ist. Ein Agent kann vollständig registriert sein, einen menschlichen Eigentümer haben, korrekt delegierte Tokens tragen – und trotzdem die Festplatte löschen, die Produktionsdatenbank leeren oder Daten exfiltrieren, für die er technisch berechtigt ist. Antigravity hatte keine ungeklärte Identität. Replit hatte keinen unbekannten Eigentümer. Beide hatten das Problem, das Okta for AI Agents nicht löst: kontextblinde Autorisierung.
Dass Okta selbst diesen Unterschied kennt, zeigt eine Formulierung in der eigenen Produktankündigung: „Any mention in this press release of solutions, features, functionalities… that are not currently generally available… may not be delivered or obtained on time or at all.“ Der Disclaimer steht dort aus rechtlichen Gründen – aber er beschreibt auch präzise, was das Produkt aktuell ist: eine Ankündigung in einem Raum, in dem das eigentliche Problem noch keine Lösung hat.
Diese Position hat einen echten Kern. Das Identitätsproblem – wer ist dieser Agent, wer besitzt ihn, wo ist er registriert – lässt sich damit adressieren. Und sie ist ein echter Fortschritt gegenüber dem Status quo, in dem 44 Prozent der Organisationen Agenten mit statischen API Keys authentifizieren.
Aber sie löst das falsche Problem. Und das lässt sich präzise benennen.
Oktas eigene Zahlen zeigen, wie groß der Governance-Gap ist, den klassische IAM-Logik bislang nicht geschlossen hat. Laut Okta „AI at Work 2025″ 📎 – einer Umfrage unter 260 Führungskräften in neun Ländern – setzen 91 Prozent der Organisationen bereits KI-Agenten ein. Nur 10 Prozent haben eine ausgereifte Strategie zum Management nicht-menschlicher Identitäten. Diese Studie wurde im August 2025 veröffentlicht – Monate vor dem Launch von Okta for AI Agents. Der Governance-Gap, den Okta für AI Agents nun schließen soll, ist also nicht die Ausgangslage vor Oktas Marktpräsenz. Er ist die Ausgangslage mit ihr. Das heißt nicht, dass das neue Produkt das Problem nicht lösen kann. Es heißt, dass das Problem strukturell ist – und sich nicht allein durch bessere Registrierung behebt.
Der Human-Owner-Ansatz schafft Accountability rückwirkend, keine Kontrolle vorwärtsgerichtet. Beim Antigravity-Incident im Dezember 2025 hätte ein menschlicher Eigentümer im Okta-Verzeichnis exakt nichts verhindert. Der Agent hatte die Berechtigung. Die Delegation war korrekt. Der Owner erfährt es, nachdem die Festplatte gelöscht ist. Accountability ohne Präventivwirkung ist Dokumentation nach dem Incident – das ist nützlich für den Auditor, nicht für den Betreiber.
Der Kill Switch ist eine Reaktionsmaßnahme, keine präventive Sicherheitsarchitektur. „Wir geben Ihnen einen Kill Switch“ bedeutet: Wir können das Problem nicht verhindern, nur stoppen, nachdem Sie es bemerkt haben. In einem KRITIS-Umfeld – Energieleitsystem, klinischer Workflow, Wasserversorgungssteuerung – ist das Zeitfenster zwischen einer kontextblinden Agentenaktion und einem physisch wirksamen Schaden nicht groß genug für einen manuellen Kill Switch. Das ist nicht eine Kritik an Okta. Das ist der strukturelle Unterschied zwischen IT-Incident und physischem Schaden, den CISA und ihre internationalen Partner in der OT-KI-Guidance vom Dezember 2025 📎 explizit adressieren.
Das Delegation-Modell reproduziert das Kernproblem auf einer neuen Ebene. OAuth Token Exchange und Delegation Frameworks lösen die Frage, für wen ein Agent handelt. Sie lösen nicht die Frage, was er in diesem spezifischen Kontext tun darf. Scopes müssen vordefiniert werden. Aber ein KI-Agent operiert in Kontexten, die nicht vollständig vorhersehbar sind. Eine Scope-Definition, die „alles, was dieser Agent für Dokumentenverarbeitung brauchen könnte“ abdeckt, ist entweder zu eng – der Agent kann nicht funktionieren – oder zu weit – und dann ist sie eine Blankovollmacht, die lediglich formal wie eine Zugriffskontrolle aussieht.
Der ehrlichste Satz in der gesamten Incumbents-Debatte stammt aus der Branche selbst: „The patterns are not new; we are just extending them to a new type of principal that operates at machine speed.“ Machine speed ist genau das Problem. Stehende Berechtigungen, die nicht am Kontext validiert werden, werden bei menschlichen Akteuren durch Trägheit, Selbstreflexion und soziale Hemmung begrenzt. Bei Agenten nicht. Das Muster ist nicht neu. Die Konsequenz seiner Anwendung auf Agenten ist es.
Ich habe das Strukturproblem im Kontext von MCP und Credential-Akkumulation 📎 beschrieben: Ein Token ohne Kontextvalidierung ist kein IAM-Problem im klassischen Sinne. Es ist ein Autorisierungsmodell-Problem. Okta löst das Identitätsproblem. Das Autorisierungsproblem bleibt. Das stille Versagen der SOC-Erkennungsinfrastruktur 📎 folgt derselben Logik: Das System erkennt den Vorfall nicht, weil er kein Angriff ist – er ist eine korrekte Aktion in einem falschen Kontext.
Was die Regulierer dazu sagen – und warum ihr Schweigen das Schärfste ist
In Compliance-Gesprächen kommt regelmäßig ein weiterer Einwand, der schwerer wiegt als die Okta-Position: „Wir erfüllen den EU AI Act. Wir haben Human Oversight nach Artikel 14. Unser BSI-Grundschutz-Konzept deckt das ab.“ Das ist der Einwand, der am häufigsten als Schlusspunkt gesetzt wird.
Er ist in dieser Pauschalität nicht haltbar. Und das lässt sich mit den Behörden selbst belegen.
Das BSI erklärt explizit, dass keine ausreichenden Standards existieren. In seiner offiziellen Positionierung zur KI-Sicherheit formuliert das BSI 📎: „Derzeit existieren keine hinreichend geeigneten Standards, um die Sicherheit von KI-Systemen für kritische Anwendungskontexte verlässlich zu bewerten und technisch zu prüfen.“ Das gilt explizit für Automotive, Gesundheitswesen, Finanz- und Telekommunikationsbereich – also exakt die KRITIS-Sektoren, die §30 und §38 BSIG regulieren. Beim 21. Deutschen IT-Sicherheitskongress im April 2026 📎 diskutierte das BSI ausdrücklich, wie Chatbots und KI-Agenten neue Sicherheitsfragen aufwerfen – ohne konkrete Antworten zu geben. Das ist kein Schweigen aus Desinteresse. Es ist das offizielle Eingeständnis der deutschen Cybersicherheitsbehörde, dass die Governance-Frage für agentische Systeme noch nicht beantwortet ist. Ein Unternehmen, das behauptet, sein BSI-Grundschutz-Konzept decke agentische KI-Zugangskontrolle ab, behauptet mehr, als das BSI selbst beansprucht.
NIST hat im Februar 2026 formal anerkannt, dass agentische Systeme eigenständige Standardisierungsarbeit erfordern. Die AI Agent Standards Initiative (CAISI) 📎 wurde gegründet, weil agentische Systeme eigenständige Standardisierungsarbeit erfordern. Das NIST AI RMF 1.0, auf das sich viele Compliance-Konzepte stützen, wurde für Systeme entworfen, deren Verhalten zum Deployment-Zeitpunkt beschreibbar ist – eine Bedingung, die autonome Agenten strukturell verletzen. Die Cloud Security Alliance hält fest: Erste belastbare NIST-Deliverables für agentische Systeme sind frühestens 2027 zu erwarten. Bis dahin operieren KRITIS-Betreiber ohne standardisierte Referenz – auch wenn ihr Compliance-Dokument etwas anderes suggeriert.
Artikel 14 EU AI Act ist kein Gegenargument. Er ist das schärfste Argument für die These dieses Artikels. Artikel 14 des EU AI Acts 📎 verlangt für Hochrisiko-KI-Systeme, dass Betreiber die Fähigkeit haben, das System zu verstehen, zu überwachen und einzugreifen. Das ist eine Designanforderung, keine Policy-Aussage: Die Eingriffsmöglichkeit muss tatsächlich existieren und ausübbar sein, nicht nur dokumentiert. Enforcement beginnt am 2. August 2026 📎 – vor dem Erscheinen agentischer IAM-Guidance. Kontextblinde Autorisierung verhindert sinnvolle Human Oversight: Wenn ein Mensch nicht sehen kann, was ein Agent in welchem Kontext gerade tut, kann er nicht eingreifen. Ein IAM-Konzept, das einen Agenten registriert und ihm einen Eigentümer zuweist, aber seinen Ausführungskontext nicht kontrolliert, dürfte die Anforderungen wirksamer menschlicher Aufsicht nach Artikel 14 in Hochrisiko-Kontexten kaum erfüllen – auch wenn das Compliance-Dokument es behauptet.
In den derzeit sichtbaren ENISA-Arbeitslinien ist agentische KI-Zugangskontrolle bislang nicht als eigenständiges Thema prominent konturiert. Das Arbeitsprogramm 2026–2028 der EU-Cybersicherheitsbehörde ist umfangreich – agentische Zugriffskontrolle taucht darin nicht als priorisiertes Einzelthema auf. Das ist keine abschließende Aussage über ENISA insgesamt. Es ist eine Beobachtung: Die EU-Aufsichtsebene hat diesen Governance-Bereich noch nicht als eigenständige Handlungsnotwendigkeit definiert.
Das Ergebnis ist eindeutig. Es gibt keine offizielle Stelle – weder BSI, noch NIST, noch ENISA, noch EU AI Act-Enforcement – die sagt, bestehende IAM-Architektur sei für agentische KI in regulierten Umgebungen ausreichend. Die einzige Institution, die das „Extend Existing IAM“-Argument vertritt, ist die Industrie, die bestehende IAM-Produkte verkauft. Regulierer sagen entweder, sie haben keine Antwort – oder sie stellen Anforderungen, die das bestehende Modell strukturell nicht erfüllen kann.
Das ist kein Nischenstandpunkt. Das ist der derzeit sichtbare Stand der regulatorischen Einordnung.
Warum das strukturelle Problem tiefer liegt als schlechte Tool-Auswahl
Die naheliegende Reaktion ist: IAM-Tooling erweitern. Agenten als Systemaccounts erfassen, Berechtigungen granularer vergeben, Logs ausweiten. Das ist besser als nichts. Es löst das Problem nicht.
Der Grund ist strukturell. Klassisches IAM arbeitet mit statischen Rollen und definierten Berechtigungsprofilen. Ein Agent operiert dynamisch – sein Zugriffsbedarf ergibt sich aus dem Kontext jeder einzelnen Aufgabe. Eine Rolle, die „alles, was dieser Agent jemals brauchen könnte“ abdeckt, ist keine Zugangskontrolle. Sie ist eine Blankovollmacht.
Laut Palo Alto Networks 📎 – einer Herstellerangabe, die mit anderen Markteinschätzungen übereinstimmt – übersteigen nicht-menschliche Identitäten heute menschliche Identitäten in Enterprise-Umgebungen um den Faktor 82 zu 1. Der überwältigende Teil dieser nicht-menschlichen Identitäten ist schlecht verwaltet: überprivilegiert, undokumentiert, nicht rotiert. KI-Agenten kommen in diese Infrastruktur hinein – und erben ihre Schwächen. Das OWASP Non-Human Identities Top 10 (2025) 📎 bestätigt das auf Basis realer Breaches: Improper Offboarding, Secret Leakage und überprivilegierte NHIs sind die Spitzenrisiken – nicht neue Angriffsklassen, sondern jahrzehntealte IAM-Hygieneprobleme, die durch Agenten eine neue Wirkung bekommen.
Das strukturelle Problem liegt tiefer. Wie eine Hacker News-Analyse zu Identity Dark Matter 📎 treffend beschreibt: Agenten „hunt for the path of least resistance.“ Sie sind für Effizienz optimiert – und wenn ein orphaned Account oder ein over-scoped Token der schnellste Weg zum Ziel ist, nutzen sie ihn. Nicht böswillig. Weil er funktioniert. Das IAM-System sieht keine Anomalie: Der Zugriff war erlaubt. Das ist dasselbe Muster, das ich als Weaponization of Trust im Trivy-Kontext beschrieben habe 📎: Nicht die Funktion ist kompromittiert – der Kontext ist es.
Auch was KI im SOC an Detektionsschwächen offenbart, gilt hier direkt: Die klare Grenze im KRITIS-Umfeld 📎 ist nicht die technische Leistungsfähigkeit des Systems – es ist die Frage, ob die Governance die richtigen Fragen stellt. Mehr Tooling stellt keine neuen Fragen. Es gibt bessere Antworten auf die alten.
Was israelische Sicherheitsarchitektur anders denkt
Israelische Sicherheitsentwicklung entsteht unter einer anderen Bedingung als europäische. Sie entsteht unter dem Primat der Operationalität: Was funktioniert, wenn es darauf ankommt? Was hält stand, wenn der Angriff bereits läuft? Diese Haltung produziert nicht bessere Compliance-Dokumente. Sie produziert andere Denkmodelle.
Das Denkmodell, das für agentische KI-Zugänge relevant ist, heißt Agentic Access Management – und es kommt aus Tel Aviv.
Oasis Security 📎, 2022 gegründet von Danny Brickman und Amit Zimerman, beide Veteranen der israelischen Geheimdiensteinheit 81, hat im März 2026 120 Millionen Dollar Series B eingesammelt 📎 – Gesamtfinanzierung rund 190 bis 195 Millionen Dollar, geführt von Craft Ventures mit Beteiligung von Sequoia Capital, Accel und Cyberstarts. Das Unternehmen hat nicht ein besseres IAM-Tool gebaut. Es hat ein anderes Modell gebaut.
Das Modell heißt Intent-Based Access: Zugriff wird nicht auf Basis einer vordefinierten Rolle vergeben, sondern auf Basis dessen, was das System in diesem Moment zu tun beabsichtigt. Jeder Agent bekommt nur die Rechte, die er für die aktuelle Aufgabe benötigt – automatisch zurückgenommen, vollständig auditiert. Das ist kein Least-Privilege-Ansatz im klassischen Sinne. Es ist eine fundamentale Verschiebung der Frage: von „Wer bist du?“ zu „Was willst du jetzt tun – und entspricht das deiner Aufgabe?“
Das ist kein fertiges Rezept. Wie Intent zuverlässig bestimmt wird, wie Fehlinterpretationen verhindert werden, wie Audit-Trails NIS-2-konform gestaltet sind – das sind offene architektonische Fragen, zu denen es erste Antworten, aber keine kanonischen Standards gibt. Das NIST hat 2026 ein erstes Konzeptpapier zu Agent Identity veröffentlicht; Insight Partners stellt nüchtern fest 📎: die Standards hinken der Deployment-Realität bereits deutlich hinterher. Was das Oasis-Modell leistet, ist etwas anderes als eine fertige Lösung: Es stellt die richtige Frage.
Brickmans Formulierung ist präziser als jede regulatorische Beschreibung des Problems: „Every organization deploying AI agents is taking on access risks they can’t yet see.“ Das ist nicht Produktmarketing. Es ist die Diagnose des Modellfehlers, den §30 BSIG nicht explizit als eigenständige Systemklasse adressiert – und den der Okta-Ansatz zwar benennt, aber auf Identitätsebene belässt.
Oasis ist nicht der einzige israelische Akteur in diesem Feld. Astrix Security, ebenfalls aus Tel Aviv, adressiert das NHI-Problem von der Secret-Management-Seite. Entro Security fokussiert auf Lifecycle-Management nicht-menschlicher Identitäten über Plattformgrenzen hinweg. Was diese drei Unternehmen verbindet: Sie wurden nicht gegründet, um bestehendes IAM zu erweitern. Sie wurden gegründet, weil sie das Modell für falsch halten.
Der deutsch-israelische Cyberpakt vom Januar 2026 📎 markiert den Moment, ab dem Israel nicht mehr nur als Produktlieferant, sondern als strategischer Sicherheitspartner für deutsche KRITIS-Infrastruktur verstanden wird. Der Markt für Agentic Identity Governance ist der erste Bereich, in dem diese Partnerschaft eine konkrete technische Ausprägung bekommt.
Ich habe das Markteintrittsmodell israelischer Sicherheitsunternehmen im europäischen regulierten Sektor mehrfach beschrieben – am Luftfahrtmarkt 📎 und in der grundlegenden Frage, was regulatorische Architektur für den Marktzugang bedeutet 📎: Der Markt öffnet sich nicht entlang technologischer Leistungsfähigkeit, sondern entlang regulatorischer Anschlussfähigkeit. Wer zu spät nach NIS-2-Konformität fragt, findet eine Tür, die nicht wegen des Produkts verschlossen ist, sondern wegen fehlender Nachweisfähigkeit. Für AAM-Anbieter bedeutet das: Das Modell muss nicht nur technisch überzeugen. Es muss §30-konform dokumentierbar sein.
Was das für Entscheidungen auf Vorstandsebene bedeutet
Dieser Artikel ist kein Ratgeber. Er ist keine Best-Practice-Liste. Er stellt eine Frage, die jede Unternehmensleitung, die KI-Agenten im produktiven Betrieb hat oder plant, beantworten muss:
Betreiben wir ein Zugangskontrollmodell, das die Systemklasse, die wir einsetzen, strukturell nicht erfassen kann?
Wenn die Antwort „ja“ ist – und in den meisten Organisationen ist sie das – dann hat §38 BSIG eine neue Qualität. Die Unternehmensleitung verantwortet nicht nur, dass ein Risikomanagementkonzept existiert. Sie verantwortet, dass es trägt. Ein Konzept, das auf einem Modell basiert, das für eine Systemklasse nicht passt, trägt nicht.
Das ist nicht der Befund eines Regulierers. Es ist die Konsequenz, die sich aus dem Zusammenspiel von IAM-Architektur, agentischen Systemen und §38 BSIG ergibt. Wie Compliance strukturell scheitern kann, ohne dass jemand offensichtlich falsch handelt, habe ich im Decision-Grade-Compliance-Kontext beschrieben 📎: Nachweis und Entscheidung müssen strukturell getrennt bleiben. Für agentische Systeme fehlt bisher beides. Was das für die normkonforme Entscheidungsarchitektur im SOC nach BSI-Grundschutz und ISO 27001 bedeutet 📎, habe ich ausgearbeitet: Die Übertragung auf agentische Systeme ist noch nicht geleistet. Das ist kein Vorwurf an das Normengerüst. Es ist eine Feststellung über den aktuellen Stand.
Es gibt zwei Möglichkeiten, mit dieser Erkenntnis umzugehen.
Die erste: abwarten, bis ein Auditor die Frage stellt, die in diesem Artikel steht. Das ist eine Entscheidung. Sie hat Konsequenzen.
Die zweite: die Frage jetzt stellen – intern, mit den richtigen Leuten am Tisch, bevor der externe Druck kommt. Das ist ebenfalls eine Entscheidung. Und es ist die einzige, die noch Handlungsspielraum lässt.
Regulatorische Architektur entscheidet nicht über Aufwand 📎. Sie entscheidet über Existenz im Markt.
Was dieser Artikel offen lässt
Die technische Architektur von AAM-Systemen – wie Intent-Based Access konkret implementiert wird, wie die Integration in bestehende IAM-Infrastruktur aussieht, wie Audit-Trails gestaltet sein müssen, um NIS-2-konform zu sein, und wie sich das Modell in Multi-Agenten-Architekturen verhält – ist ein eigenständiges Thema. Es folgt.
Dieser Artikel beschreibt den Modellfehler. Nicht seine Lösung. Der Grund ist einfach: Wer das Modell nicht verstanden hat, kann eine Lösung nicht einordnen. Wer es verstanden hat, weiß bereits, welche Fragen er stellen muss.
In meiner Arbeit als Executive Security Architect begleite ich Unternehmensführungen regulierter Organisationen dabei, die Governance-Anforderungen agentischer KI-Systeme zu verstehen und strukturiert zu adressieren – und israelische Technologieunternehmen dabei, diese Anforderungen als europäische Marktbedingung zu begreifen, nicht als Hindernis. Das IAM-Problem für KI-Agenten ist das Thema, das in diesen Gesprächen aktuell am häufigsten ohne Antwort bleibt. Das ist der Ausgangspunkt dieses Artikels.
Sie stehen vor der Frage, ob Ihr bestehendes IAM-Konzept für KI-Agenten trägt – und welche Konsequenzen das für Ihre §38-Verantwortung hat? Dann ist jetzt der Zeitpunkt, darüber zu sprechen. 📎
Anmelden zu unserem Newsletter:
Schreibe einen Kommentar