Kurzfassung
Warum ist Identity-Management der primäre limitierende Faktor für die KI-Skalierung in Unternehmen?
Traditionelle IAM-Systeme sind statisch. Agentenbasierte KI-Systeme dagegen zeigen ein dynamisches Laufzeitverhalten, bei dem Delegierungsketten und 5- bis 30-mal (bis zu 1.000-mal) mehr Berechtigungsereignisse als bei Standard-Interaktionen entstehen. Unternehmen skalieren KI 12-mal schneller, wenn sie Identity Governance (Rechteeinschränkung, kontextbezogenes Scoping und automatisierte Rotation) in die Architekturphase integrieren, statt Sicherheit wie eine nachträgliche Compliance-Prüfung zu behandeln.
Seit 18 Monaten sind wir live dabei, wenn Entscheidungen zur KI-Skalierung getroffen werden. Wir sprechen dabei nicht von Keynote-Podien, sondern von den Arbeitsbesprechungen, in denen Sicherheitsverantwortliche, Plattform-Architekt:innen und Unternehmenssponsor:innen aushandeln, was freigegeben wird und was nicht. Das von uns immer wieder beobachtete Muster war immer dasselbe und hat uns überrascht: Die Produktionsphase am schnellsten erreichten nicht die Unternehmen mit den besten Modellen oder den meisten Daten, sondern die Unternehmen, die das Identity-Management vom ersten Tag an als zentralen Baustein ihres KI-Designs behandelten.
Die Fähigkeit, die Agentenidentität zu verwalten, entscheidet darüber, ob Sie in die Produktion gehen oder in der Pilotphase stecken bleiben. Damit ist dies der limitierende Faktor bei der KI-Einführung in Unternehmen, den fast niemand frühzeitig genug berücksichtigt.
Wir wissen das, weil wir 18 Monate lang immer wieder in Echtzeit beobachtet haben, wie ein System zusammenbricht – im Finanzsektor, Gesundheitswesen, Einzelhandel und bei Unternehmenssoftware, um nur einige Bereiche zu nennen. Die Muster, die zum Zusammenbruch führen, sind über alle Branchen, Modelle und Cloud-Plattformen hinweg bemerkenswert konsistent.
Eine menschliche Absicht, tausend Berechtigungsereignisse
Eine Sicherheitsverantwortliche bei einem Finanzdienstleistungsunternehmen hat das Problem vor einigen Monaten für uns auf den Punkt gebracht. Ihr Team hatte im Januar im Rahmen eines kontrollierten Pilotprojekts drei KI-Agenten bereitgestellt – jeweils mit Berechtigungsbereich, Dokumentation und Genehmigung. Bis März hatten sie bereits 17 weitere Agenten gefunden, die im gesamten Unternehmen im Einsatz waren und von niemandem genehmigt wurden. Sie konnten auf Produktionsdaten zugreifen, API-Aufrufe durchführen und mit Anmeldedaten von Mitarbeiter:innen agieren.
„Ich weiß gar nicht mehr, womit sie verbunden sind“, sagt sie. Und damit war sie kein Einzelfall, sondern der Median.
Eine einzelne agentenbasierte Aufgabe generiert 5- bis 30-mal so viele Identity-bezogene Ereignisse wie eine Standardinteraktion. Wenn Agenten-Flows miteinander verknüpft werden (z. B. wenn ein Agent einen anderen aufruft, Teilaufgaben delegiert und Unteragenten erstellt), können laut Untersuchungen von Forscher:innen der Stanford University bei komplexen Reasoning-Workflows mit Wiederholungsschleifen und Selbstkorrektur bis zu 1.000-mal mehr Ereignisse anfallen.
Eine menschliche Absicht. Tausend Berechtigungsereignisse. Jedes einzelne Ereignis stellt eine Angriffsfläche, ein Compliance-Risiko und eine Governance-Entscheidung dar, für das traditionelles IAM nie ausgelegt war.
Nur 24,4 % der Unternehmen haben vollständige Transparenz zu ihren KI-Agenten. Bis 2028 werden typische Fortune 500-Unternehmen mehr als 150.000 Agenten im Einsatz haben. Heute verfügen 90 % dieser Agenten über zu viele Berechtigungen. Dies gilt nicht nur für diskrete Agenten, sondern auch für feinabgestimmte Modelle, die Inferenzaufrufe durchführen, für RAG-Pipelines, die Daten aus sensiblen Speichern abrufen, für Prompt-Ketten, die Tools aufrufen, und für Multi-Agenten-Orchestrierungen, bei denen Berechtigungen über Delegierungsebenen kaskadiert werden, die niemand explizit genehmigt hat.
53 % greifen ohne angemessene Governance auf sensible Daten zu. Das Schatten-KI-Problem geht über Agenten hinaus. Jede nicht autorisierte Inferenz bringt vererbte Berechtigungen mit sich, die sich in Maschinengeschwindigkeit vervielfachen.
„Die explosionsartige Zunahme von Identity-bezogenen Ereignissen ist kein Nebeneffekt agentenbasierter KI – sie ist das bestimmende Merkmal. Jeder Agent, den Sie ohne Governance bereitstellen, ist ein Multiplikator für jedes andere Risiko in Ihrer Umgebung.“
– Sai Lolayekar, Business Innovation Leader, Security Partners, AWS
Die meisten Governance-Frameworks lösen das Problem von gestern
Die Branche einigt sich momentan auf ein bequemes Narrativ: „Überarbeiten Sie Ihre Workflows, integrieren Sie Sicherheit frühzeitig, verwalten Sie Ihre Agenten.“ Führende Analystenunternehmen und Cloud-Anbieter bestätigen das. Der Ansatz ist grundsätzlich richtig, reicht aber nicht aus.
Das Problem? Die meisten der heute bereitgestellten Governance-Frameworks sind statische Richtlinien-Engines, die versuchen, dynamische Systeme zu verwalten. Sie definieren Berechtigungen im Zuge der Bereitstellung. Aber so funktioniert agentenbasierte KI nicht: Das Verhalten eines Agenten zeigt sich erst zur Laufzeit. Er überlegt, welches Tool als Nächstes aufgerufen werden soll. Er entscheidet über Delegierungen. Er bestimmt anhand eines Kontexts, welche Daten er benötigt. Diesen Kontext gab es aber noch gar nicht, als die Richtlinien geschrieben wurden.
Wenn Sie statische Governance für dynamische Agenten verwenden, ist das so, als ob Sie Verkehrsregeln für eine Stadt schreiben wollen, die ihre Straßen stündlich neu gestaltet.
Was benötigt wird – aber bisher von fast niemandem vollständig entwickelt wurde –, ist Identity Governance, die mit derselben Geschwindigkeit und Anpassungsfähigkeit agiert wie die Agenten selbst:
- Berechtigungen, die eingeschränkt werden, wenn Delegierungsketten im Nachgang länger werden
- Kontextbezogener Zugriff, der mit zunehmender Sensibilität enger gefasst wird
- Not-Aus-Schalter, bei denen nicht erst ein Mensch das Problem bemerken muss
Das ist die Lücke. Und deshalb ist Identity-Management für die KI-Skalierung nicht nur „wichtig“: Es entscheidet über die Geschwindigkeit. Unternehmen, die dieses Problem zuerst lösen, vermeiden nicht nur Risiken. Sie kommen schneller voran alle andere, da sie Agenten bereits in der Produktionsumgebung bereitstellen können, während Mitbewerber:innen noch im Pilotmodus feststecken und auf perfekte Richtlinien warten.
Die vier wichtigsten Muster bei Sicherheitsproblemen, die wir tatsächlich beobachten (live vor Ort, nicht in Berichten)
Aus Gesprächen mit Hunderten Unternehmen erkennen wir vier wiederkehrende Muster, die Projekte ausbremsen. So sehen sie aus, wenn Sie am Tisch sitzen:
1. Der blinde Fleck für Chancen
Ein Unternehmen im Gesundheitswesen investierte 4 Millionen US-Dollar in die Entwicklung KI-gestützter Agenten für die Bearbeitung von Leistungsanträgen mit angemessenen Zugriffskontrollen. Die wertvollste Gelegenheit bot sich tatsächlich in einem Upstream-Workflow für Vorabgenehmigungen, bei dem medizinisches Personal Anmeldedaten gemeinsam nutzte und Agenten standardmäßig Berechtigungen auf Administratorebene erbten. Das Unternehmen hat den falschen Bereich abgesichert, weil im Vorfeld nicht analysiert wurde, wo sich die tatsächlichen Identity-Risiken konzentrieren.
2. Die Diskrepanz zwischen Strategie und Umsetzung
In einem Einzelhandelsunternehmen hat der CEO im Januar „AI-first“ ankündigt, der CTO drei Plattform-Initiativen finanziert und der CISO ein Governance-Framework eingeführt – drei Maßnahmen, die alle in unterschiedliche Richtungen weisen. Bis zum dritten Quartal entwickelten zwölf Teams Agenten in vier Laufzeitumgebungen, ohne sich in irgendeiner Form beim Identity-Management abzustimmen. Sie entwickelten zwölf Versionen derselben technischen Schulden und keine davon überstand einen standardisierten Security-Review.
3. Experimente, die nie in eine Produktionsumgebung gelangen
Ein Anbieter von Unternehmenssoftware startete innerhalb von 18 Monaten 47 Pilotprojekte für KI-Agenten – nur drei erreichten die Produktionsphase. Jedes erfolglose Pilotprojekt stieß auf dasselbe Hindernis: den Security-Review. In jedem Fall wurde ein eigenes Authentifizierungs-, Anmeldedatenspeicher- und Berechtigungsmodell entwickelt. 44 maßgeschneiderte Identity-Implementierungen, null wiederverwendbare Governance-Infrastruktur. Die Pilotprojekte scheiterten nicht an den KI-Fähigkeiten, sondern daran, dass niemand die Identity-Plattform entwickelt hat, die ihnen den nächsten Schritt ermöglicht hätte.
4. Leitplanken, die zu Hindernissen werden
Die Global CISO Insights 2026 von Okta ergaben, dass nur 31 % der CISOs das Gefühl haben, hinsichtlich des akzeptablen KI-Risikos vollständig mit ihrer Führungsebene und dem Vorstand auf einer Linie zu liegen. Darüber hinaus gab weniger als die Hälfte an, dass ihr Vorstand KI-Sicherheit als Wegbereiter für Geschäfte und nicht als reine Compliance-Formsache betrachtet. Das Ergebnis: Security-Teams werden zur Abteilung der Neinsager – nicht, weil sie es wollen, sondern weil der Prozess sie dazu zwingt.
Jedes dieser Muster hat dieselbe Ursache: Identity-Management wurde als Nebensache und nicht als grundlegender Design-Baustein behandelt.
Die Lösung besteht nicht in besserer Abstimmung oder mehr Richtlinien, sondern in einem neuen Ansatz für Verantwortlichkeit, bei der die Verwaltung der Identität zu einer Architekturentscheidung und nicht zu einer nachträglichen Kontrollinstanz wird.
„Sie können Autonomie nicht skalieren, ohne die Verantwortlichkeiten zu skalieren. Das Identity-Management ist eine zentrale Design-Entscheidung, die exponentielle Vorteile von exponentiellen Risiken trennt.“
– Eddie Kim, Head of AI Market Development, AWS ISV North America
Um es klar zu sagen: Modellqualität und Datenbereitschaft sind nicht irrelevant – sie sind notwendig. Aber dort geraten Unternehmen nicht ins Stocken. Wir haben beobachtet, wie Teams mit erstklassigen Modellen und makellosen Daten-Pipelines Monate verloren, weil sie grundlegende Fragen zur Agentenautorisierung nicht beantworten konnten. Der Engpass hat sich verlagert.
Das Enterprise Brain-Problem
In der Branche wird derzeit über „Enterprise Brain“ diskutiert. Damit wird der Ansatz bezeichnet, dass Agenten gemeinsamen Speicher und Kontext benötigen, damit das von einem Agenten Erlernte auch für andere Agenten verfügbar ist und nicht nach Session-Ende verschwindet.
Das ist der richtige Instinkt. Neutrale Agenten, die zwischen zwei Sessions alles vergessen, sind der Grund, warum Pilotprojekte beeindrucken und Produktionssysteme enttäuschen. Aber niemand in dem Gespräch fragt: „Wer verwaltet den Speicher?"
Wenn Agent A etwas über die finanzielle Situation der Kundschaft erfährt und es an Agent B weitergibt, der einen Marketing-Workflow bearbeitet – war diese Weitergabe autorisiert? Wenn der gesammelte Kontext eines Agenten personenbezogene Daten, Geschäftsgeheimnisse oder privilegierte Kommunikation enthält, wer entscheidet dann, was aufbewahrt wird, was gelöscht wird und wer sonst noch darauf zugreifen kann?
Wenn Unternehmen das Enterprise Brain ohne Identity Governance umsetzen, ersetzen sie organisatorische Amnesie durch organisatorische Überwachung. Damit haben sie aber das Problem nicht gelöst, sondern ein neues geschaffen, das schwerer zu erkennen und schwerer einzudämmen ist.
Hier wird das Identity-Management nicht nur zu einer Sicherheitskontrolle, sondern zu einem zentralen Design-Baustein für die nächste Generation von KI-Architektur. Die Speicherebene, die Kontextebene, die Ebene für gemeinsames Wissen … all das erfordert Identity-orientierte Zugriffskontrollen, die genauso schnell arbeiten wie die Agenten, die sie nutzen.
Ein Finanzdienstleistungsunternehmen, mit dem wir sprachen, hatte Agenten mit gemeinsam genutztem Speicher bereitgestellt, aber keine Zugriffskontrollen mit Identity-bezogenen Berechtigungsbereichen implementiert. Innerhalb weniger Wochen hatte ein Marketing-Agent Finanzdaten der Kundschaft erfasst, die ein Compliance-Agent offengelegt hatte – Daten, für deren Speicherung er keine Berechtigung und für deren Löschung er keinen Mechanismus besaß.
Wie Okta und AWS gemeinsam Agentic Memory und delegierte Workflows absichern
Genau deshalb haben wir die Okta-AWS-Integration so konzipiert, dass sie nicht nur Agentenaktionen, sondern auch den Agentic Memory verwaltet. Für Teams, die agentenbasierte Workloads auf Amazon Bedrock ausführen, ist jeder neu bereitgestellte Agent eine neue Identität, die erkannt, mit Berechtigungsbereichen versehen und verwaltet werden muss.
Okta for AI Agents lässt sich direkt in Amazon Bedrock und Amazon Bedrock AgentCore integrieren, um die KI-Governance-Lücke zu schließen und gleichzeitig fünf Herausforderungen zu bewältigen:
- Erkennung von Schatten-KI in der gesamten Umgebung
- Universelle Registrierung mit Zuweisung einer menschlichen verantwortlichen Person für jede autonome Identität
- Durchsetzung des Least-Privilege-Prinzips, bei dem Berechtigungen mit wachsenden Delegierungsketten immer weiter eingegrenzt werden
- Automatisierte Rotation von Anmeldedaten mit Maschinengeschwindigkeit
- Vollständige Audit-Protokolle für manipulationssichere Aufzeichnungen jeder Agentenaktion
Entscheidend ist, dass es bei jedem bestehenden Identity-Anbieter (Entra ID, Ping oder anderen) funktioniert, ohne dass alles komplett neu aufgesetzt werden muss.
Wie sieht das in der Praxis aus? Ein von uns beratenes Team aus dem Einzelhandel entwickelte seine Governance-Ebene für Agenten, bevor es auch nur einen einzigen Agenten programmierte. Jeder Agent erbt bei der Instanziierung eine mit Berechtigungsbereichen versehene Identität. Berechtigungen werden automatisch eingeschränkt, sobald ein Agent Delegierungen vornimmt. Für seinen ersten Agenten brauchte das Team elf Tage vom Konzept bis zur Produktion. Für seinen zwölften Agenten brauchte das Team drei Tage, weil die Governance-Infrastruktur bereits vorhanden war.
Der Business Case ist eine Frage der Geschwindigkeit, nicht des Risikos
Bei Dutzenden von uns beratenen Unternehmen hat sich das Muster bewährt: Teams, die Identity Governance vom ersten Tag an integrieren, erreichen die Produktionsphase in Zyklen von sechs Wochen. Teams, die die Governance erst nachträglich implementieren, stecken auch nach 18 Monaten noch in der Pilotphase, weil sie die Architektur nach jedem Security-Review neu überarbeiten müssen.
Das ist ein 12-facher Geschwindigkeitsunterschied zwischen Identity-First- und Identity-Last-Unternehmen. Und er potenziert sich. Das Identity-First-Team hat zwölf Iterationen bereitgestellt und aus dem Produktionsfeedback gelernt, während das Identity-Last-Team noch über die Genehmigung für seine erste Bereitstellung verhandelt.
Die Daten von BCG für 2026 bestätigen das breitere Muster: Unternehmen mit einer klaren KI-Strategie, die eine Neugestaltung der Workflows umfasst, verzeichnen einen Anstieg von 25 Prozentpunkten bei den messbaren geschäftlichen Auswirkungen. Untersuchungen von Eightfold gehen von einem EBITDA-Zuwachs von 10–25 % aus. Nach unseren Erfahrungen in der Praxis ist Identity-First-Design der wichtigste Indikator dafür, ob ein Workflow-Redesign die Produktionsphase erreicht oder in der Pilotphase scheitert.
Der Mechanismus ist einfach: Identity-First-Teams erstellen einmalig eine gemeinsame Governance-Ebene, die jeder nachfolgende Agent erbt. Identity-Last-Teams setzen die Governance für jeden Agenten jedes Mal individuell neu auf. Der erste Ansatz skaliert linear. Der zweite skaliert quadratisch in Bezug auf Kosten und Reibungsverluste und lässt sich schließlich gar nicht mehr skalieren.
Aktionsplan: Drei Frameworks für die Vorbereitung auf Identity-Management für KI-IdentitätsbereitschaftAgenten
Wir glauben an „Groß denken, klein anfangen, schnell skalieren.“ Hier sind drei Gespräche für den Einstieg:
1. Das Audit der Reibungspunkte
- Wer: Sie + Ihr Betriebsteam
- Aufgabe: Identifizieren Sie 3–5 häufig auftretende Reibungspunkte.
- Fragen zu jedem Reibungspunkt: „Wie würde dies aussehen, wenn wir es heute von Grund auf neu entwickeln würden – mit KI als nativer Funktion und integrierter Identity Governance?“
2. Die Entscheidung zur Identity-Architektur
- Wer: Sie + CISO + Leiter:in für KI-Plattform
- Drei Fragen: „Wie viele Agenten sind gerade aktiv – autorisiert und nicht autorisiert? Können wir den Zugriff eines beliebigen Agenten in weniger als 60 Sekunden widerrufen? Wenn ein Agent an einen Unteragenten delegiert, werden Berechtigungen dann eingegrenzt oder vererbt?“
- Die Diagnose: Wenn Sie nicht alle drei Fragen beantworten können, haben Sie ein Architekturproblem.
3. Das Gespräch über Geschwindigkeit
- Wer: Sie + CEO/Vorstand
- Definieren Sie Sicherheit neu – weg von der „Risiko-Minimierung“, hin zur „Bereitstellungsgeschwindigkeit“.
- Der strategische Fokus: Die Frage ist nicht, wie man sichere KI-Governance umsetzt, sondern wie man 12-mal schneller als Mitbewerber:innen in die Produktion geht. Identity-First-Design ist die Antwort.
Die agentenbasierte Wirtschaft kommt schneller, als die meisten Unternehmen darauf vorbereitet sind. Die Branche ist sich zunehmend einig, dass Agenten maschinell ausgestellte Identitäten benötigen, verbunden mit der Durchsetzung des Least-Privilege-Prinzips und vollständiger Auditfähigkeit. Dies wurde nun vom NCCoE des NIST in seinem Framework für die Identity-Management und Autorisierung von KI-Agenten festgeschrieben. Einigkeit über das Konzept ist aber nicht dasselbe wie Einigkeit bei der Umsetzung. Die Lücke zwischen dem Wissen um die Bedeutung von Identity-Management und dessen Integration in die Architektur ist der Punkt, an dem sich Vorteile potenzieren. Unternehmen, die dies richtig umsetzen, werden nicht nur Risiken vermeiden – sie werden auch schneller agieren und mehr ausliefern.
Identity-Management ist die Designentscheidung, die die Produktionsreife bestimmt. Übersehen Sie es nicht und entwickeln Sie es zuerst.