Es beginnt mit Flow, nicht mit einem Sicherheitsvorfall
Es beginnt nicht mit einem Incident.
Es beginnt mit Flow.
Ein Entwickler aktiviert einen AI Copilot. Der Fokus liegt nicht auf Security, sondern auf Geschwindigkeit. Der Copilot liest Code, erkennt Abhängigkeiten, analysiert Konfigurationen und bewegt sich souverän durch Repositories und Build-Systeme via APIs. Die Tokens sind gültig. Die Scopes genehmigt. Die Architektur sauber. Alles verhält sich exakt so, wie es vorgesehen ist.
In einer anderen Abteilung verbindet eine Marketingmanagerin ein GenAI-Tool mit dem CRM. OAuth regelt den Zugriff. Access Tokens laufen wie vorgesehen ab, Refresh Tokens verlängern die Verbindung unauffällig. Die AI segmentiert Kunden, passt Kampagnen an, schreibt Daten zurück. Die Performance steigt. Keine Alarme. Kein Anlass zur Sorge.
An anderer Stelle experimentiert ein Fachbereich mit einem autonomen Agenten. Er aggregiert Daten aus ServiceNow, SAP und Salesforce, priorisiert Tickets und erstellt entscheidungsreife Analysen für das Management. Der Agent arbeitet headless, authentifiziert über Client Credentials, in Maschinen-Geschwindigkeit. Er schläft nicht. Er vergisst nicht. Er meldet sich nicht ab.
Keiner dieser Schritte verletzt eine Policy.
Keiner bricht einen Standard.
Keiner löst einen Incident aus.
Und genau so entsteht die zweite Identität.
Der Aufstieg eines Akteurs ohne Gesicht
Diese Identität ist kein Mensch – und handelt dennoch.
Sie ist keine klassische Maschine – und entscheidet dennoch.
Sie ist AI, ausgestattet mit Rechten, Kontext und Dauer.
Das eigentliche Risiko besteht nicht darin, dass OAuth Tokens nicht ablaufen. Sie tun es. Das Risiko liegt darin, dass Zugriffsbeziehungen ihren ursprünglichen Zweck überleben. Refresh Tokens bleiben aktiv. Client Credentials werden nie rotiert. Tokens sind selten an konkrete Workloads oder Laufzeitkontexte gebunden. Und vor allem: Niemand beobachtet in Echtzeit, wofür diese Rechte tatsächlich genutzt werden.
Die Technologie funktioniert.
Die Governance nicht.
Wenn Ownership leise verschwindet
Der gefährlichste Moment ist selten ein Angriff. Es ist der leise Übergang in einen Zustand, für den sich niemand mehr aktiv verantwortlich fühlt.
Ein Entwickler verlässt das Unternehmen. Die AI-Integration bleibt bestehen.
Ein Projekt endet. Der Agent läuft weiter.
Eine Anbieterbeziehung schläft ein. Die Tokens bleiben gültig.
Was hier entsteht, ist kein klassisches Security-Problem. Es ist ein Identitätsproblem.
Identität ohne Ownership.
Zugriff ohne klaren Zweck.
Handlung ohne Verantwortung.
Kommt ein externer Impuls hinzu – etwa ein kompromittierter SaaS-Anbieter, ein manipuliertes Modell oder eine Prompt Injection –, eskaliert das System nicht chaotisch. Es verhält sich korrekt. Mit gültigen Berechtigungen. Über genehmigte APIs. Innerhalb aller bestehenden Kontrollen.
Der Schaden ist selten spektakulär. Er ist strukturell. Entscheidungen basieren auf subtil verfälschten Daten. Prozesse verschieben sich schleichend. Geschäftskritische Systeme verhalten sich anders, ohne dass jemand den Ursprung benennen kann.
Wenn der Effekt sichtbar wird, ist er längst in Umsatz, Compliance-Exposure und Vertrauen eingeschrieben.
Warum Zertifizierungen ein trügerisches Sicherheitsgefühl erzeugen
Wenn dieses Unbehagen aufkommt, verweisen viele Organisationen auf Vertrautes: ISO 27001. SOC 2. Audits, Policies, dokumentierte Kontrollen.
Diese Frameworks sind wichtig. Sie schaffen Struktur. Sie zeigen Absicht. Aber sie operieren auf einer anderen Ebene als das eigentliche Problem.
Sie bestätigen, dass Prozesse existieren.
Sie bestätigen nicht, dass autonome Akteure sich sicher verhalten.
Sie zertifizieren Governance-Reife.
Sie liefern keine Kontrolle zur Laufzeit.
Sie sagen nichts darüber aus, welche AI-Identitäten heute aktiv sind, welche Privilegien sie besitzen, in welchem Kontext sie handeln oder welchen geschäftlichen Impact ihre Aktionen haben.
Security-Teams sehen Logs. IAM-Systeme kennen Accounts. PAM schützt privilegierte Zugriffe. IGA rezertifiziert Rollen. Alles funktioniert – innerhalb von Annahmen, die nicht mehr gelten.
Diese Annahmen setzen stabile Identitäten voraus.
AI ist nicht stabil.
Vier Risiken, die getrennt betrachtet werden müssen
Aus meiner Sicht bricht Kontrolle genau dort zusammen, wo Unternehmen grundlegend unterschiedliche Risiken unter dem Sammelbegriff „AI Security“ vermischen.
Es sind nicht dieselben Risiken.
Da ist das Identitätsrisiko: AI-Identitäten existieren, deren Lifecycle niemand steuert und deren Ownership implizit oder schlicht vergessen ist.
Da ist das Zugriffsrisiko: Scopes wachsen über Zeit, Client Credentials bleiben dauerhaft aktiv, APIs bleiben angebunden – lange nachdem ihre ursprüngliche Berechtigung abgelaufen ist.
Da ist das Verhaltensrisiko: Autonome Agenten driften, verketten Aktionen und erzeugen Ergebnisse, die nie explizit genehmigt wurden.
Und da ist das Entscheidungsrisiko: Führungskräfte treffen strategische Entscheidungen auf Basis von Outputs, deren Herkunft, Integrität und Intention nicht mehr vollständig erklärbar sind.
Diese Risiken als eines zu behandeln, garantiert das Scheitern. Jedes erfordert andere Kontrollen, andere Telemetrie und andere Reaktionsmechanismen.
Identity First Security als Ordnungsprinzip
Genau hier beginnt Identity First Security.
Nicht als Produkt.
Nicht als Zertifizierung.
Sondern als Denkmodell.
Identity First Security geht davon aus, dass jede Handlung – menschlich oder nicht – zuerst ein Identitätsereignis ist. Wer oder was handelt? Mit welchen Rechten? In welchem Kontext? Für welchen Zeitraum? Und unter wessen Verantwortung?
Wenn Netzwerkgrenzen verschwimmen, Geräte an Bedeutung verlieren und AI autonom agiert, bleibt Identität die einzige konstante Durchsetzungsschicht.
Warum CIAM in einer AI-getriebenen Welt entscheidend wird
Aus dieser Perspektive erhält CIAM eine präzisere Bedeutung.
CIAM ist nicht die alleinige Antwort auf AI-Identitäten. Das war es nie. Aber es ist ein zentraler Bestandteil einer Identity Fabric, weil es genau für jene Akteure gebaut wurde, die AI verkörpert: externe, hochskalierte, dynamische Non-Human Identities.
CIAM ermöglicht fein granulare Autorisierung, Token-Lifecycle-Kontrolle, kontextbasierte Zugriffe und Continuous Verification – Fähigkeiten, an denen klassische Enterprise-IAM-Modelle im grossen Massstab scheitern. In Kombination mit Machine Identity, Workload Identity, API Security und Identity Threat Detection & Response entsteht eine kohärente Kontrollschicht für AI-getriebene Ökosysteme.
Kein einzelnes System löst dieses Problem.
Nur Integration tut es.
Die Frage, der sich kein Verwaltungsrat mehr entziehen kann
Unternehmen verlieren nicht die Kontrolle, weil sie AI einsetzen.
Sie verlieren sie, weil sie Identität als nachgelagertes Thema behandeln.
Die zweite Identität ist längst im Unternehmen.
Sie arbeitet. Sie entscheidet. Sie delegiert.
Die einzige offene Frage ist, ob jemand ihre Existenz steuert –
oder ob sie bereits Teil der Unternehmensrealität ist, ohne dass jemand je ihren Namen gelernt hat.
