Ghost Credentials sind der nächste Posten im Cloud-Budget

Die Zahl, die in diesem Quartal auf jedem Schreibtisch eines Plattformverantwortlichen liegen sollte, ist 244. So viele nicht-menschliche Identitäten kann ein einzelner Entwickler ansammeln – laut Forschungsergebnissen des Sicherheitsarchitekten Aleksandr Krasnov. Dieses Verhältnis macht aus Identity Governance ein Thema für das Board, nicht nur einen Posten im Q4-Budget. Für jedes Team, das gerade einen mehrjährigen Vertrag mit einem IAM-Anbieter oder einer KI-Orchestrierungsplattform abschließen will, verändert diese Zahl die Build-vs-Buy-Kalkulation grundlegend.

Die Zahlen

Der Ausgangspunkt, wie Dark Reading berichtete, wirkt täuschend unscheinbar. Ein KI-gesteuerter Workflow-Agent, 30 Tage inaktiv, beginnt plötzlich zu ungewöhnlichen Zeiten API-Aufrufe auszulösen. Das löste eine Anomalie-Untersuchung aus, und Krasnov, ein Distinguished Security Architect bei Ducker Tech Consulting, zog den Faden weiter. Was er darunter fand, war ein Netz aus Ghost Credentials: Tokens, Agenten und Service Accounts außerhalb der traditionellen Vertrauensgrenze, die dennoch in der Lage waren, sich lateral zu bewegen und Privilegien zu eskalieren.

Krasnov nannte das betroffene Unternehmen nicht, aber die Art des Vorfalls ist wichtiger als die Identität des Kunden. Betrachtet man die Ökonomie aus der Perspektive eines Angreifers: Zwei Wochen für eine Phishing-Kampagne – oder fünf Minuten, um exponierte Tokens aufzuspüren. Krasnov formuliert es so: Der rationale Angreifer wählt den Fünf-Minuten-Weg. Das senkt die Kostenstruktur eines Einbruchs so drastisch, dass die meisten Sicherheitsbudgets dafür nicht ausgelegt sind.

Rechnet man dann die 244 noch dazu: Ein 50-köpfiges Entwicklerteam ist theoretisch für über 12.000 nicht-menschliche Identitäten verantwortlich. Die meisten CISOs, mit denen ich gesprochen habe, budgetieren Identity Governance noch immer so, als würde die Angriffsfläche mit der Mitarbeiterzahl skalieren. Das tut sie nicht. Sie skaliert mit dem Produkt aus Mitarbeiterzahl und NHI-Dichte – und diese Dichte ist eine unkontrollierbare Funktion der Anzahl an KI-Agenten, CI/CD-Pipelines und SaaS-Integrationen, die ein Team seit 2024 eingeführt hat.

Krasnov testete sein neues Open-Source-Tool NHI Hound informell bei Unternehmen mit bis zu 2.000 Mitarbeitern. Sein geschätzter Bereinigungszeitraum für diese Organisationen: sechs bis neun Monate. Das ist kein Sprint. Das ist ein ganzes Geschäftshalbjahr, das damit verbracht wird, Vertrauensbeziehungen zu entwirren, die größtenteils durch Standardeinstellungen entstanden sind, die niemand überprüft hat. Über 2.000 Mitarbeiter wird der Graph laut Krasnov „super, super unübersichtlich", und der aktuelle Output des Tools riskiert zu viel Rauschen, um handlungsfähig zu bleiben. Das nutzbare Zeitfenster für eine proaktive Bereinigung mit dem bald verfügbaren Tooling ist daher eng: mittelständische Teams mit der Disziplin, zwei Quartale dafür einzuplanen – bevor sie die Komplexitätsschwelle von 2.000 Mitarbeitern überschreiten.

Was wirklich neu ist

Nicht-menschliches Identitätsrisiko ist keine neue Kategorie. Service Accounts sind seit der SOX-Ära ein Compliance-Problem, und jeder Cloud-IAM-Anbieter verkauft seit einem Jahrzehnt „Least Privilege" als Wertversprechen. Was in diesem Zyklus wirklich anders ist, sind drei aufeinander gestapelte Entwicklungen.

Erstens ist der KI-Agent jetzt der Credential-Inhaber. Der auslösende Vorfall war kein gestohlenes Entwickler-Laptop oder ein falsch konfigurierter S3-Bucket. Es war ein Workflow-Agent, der 30 Tage lang ruhig war und dann wieder aktiv wurde. Das ist ein völlig neues Fehlermuster. Agenten werden von Produktteams bereitgestellt, die Features ausliefern – nicht von IAM-Teams, die Zugriffsanfragen prüfen. Der Vertrauenspfad entsteht als Nebenprodukt des Deployments, und niemand ist für das Offboarding verantwortlich.

Zweitens führt die Pivot-Kette jetzt direkt in Identity Provider. Krasnovs Black-Hat-Session, Teil des Online-Programms am Ende von Black Hat USA 2026, soll zeigen, wie ein einzelner geleakter Schlüssel durch den Missbrauch verketteter Vertrauensbeziehungen in Provider wie Okta zu einer vollständigen Cloud-Kompromittierung führen kann. Das ist der Punkt, der jeden VP Engineering aufschrecken sollte, der annahm, sein SSO-Investment sei eine Sicherheitsgrenze. Wenn der IdP selbst über ein Ghost-NHI erreichbar ist, kollabiert die gesamte Zero-Trust-Architektur auf das, was der schwächste Agenten-Token erlaubt.

Drittens holt das Tooling endlich beim Inventar auf. NHI Hound erfasst Identitätsdaten aus Okta, GitHub und Cloud-IAM-Plattformen, klassifiziert Identitäten nach Trust-Severity-Leveln und markiert, was Krasnov „kritische" Zustände nennt – also Situationen, in denen eine Low-Trust-Identität aufgrund impliziter Vertrauensbeziehungen, die niemand explizit definiert hat, effektiv als Super-Admin agieren kann. Genau dieser letzte Satz verdient eine Unterstreichung. Das Risiko sind nicht die Berechtigungen, die man erteilt hat. Es sind die Berechtigungen, die durch Kombinationen von Grants über mehrere Systeme entstanden sind, die kein einzelner Admin jemals als Einheit autorisiert hat. Das lässt sich sauber auf MITRE ATT&CK-Techniken rund um gültige Accounts und Cloud-Pivot abbilden – aber das Erkennungsproblem hat das Detection-Tooling stets überholt.

Was für Sicherheitsteams bereits eingepreist ist

Die meisten reifen Sicherheitsteams wissen, dass NHI-Sprawl ein Problem ist. Die Gartner-typischen Argumente kursieren seit 18 Monaten, und auf der RSA 2026 hatte jeder Anbieter „Nonhuman Identity" auf seinem Messebanner. Was eingepreist ist: die allgemeine Besorgnis, das Bewusstsein, dass Agenten schneller proliferieren als Menschen, und das Gefühl, dass CIEM-Tooling der großen Cloud-Anbieter unvollständig ist.

Was nicht eingepreist ist – und hier würde ich dem Marktkonsens widersprechen – sind die operativen Kosten der Remediation. Sechs bis neun Monate dedizierter Bereinigungsarbeit bei einem Unternehmen mit unter 2.000 Mitarbeitern ist eine reale Zahl. Das ist eine Headcount-Entscheidung. Für ein Series-B-Fintech, das schlank aufgestellt ist, bedeutet das entweder eine neue Stelle im Plattformteam oder einen verschobenen Produkt-Roadmap. Der CFO wird das vor dem CISO spüren, denn der CFO ist derjenige, der die Anforderung für den Plattformingenieur unterzeichnet.

Ebenfalls nicht eingepreist: die Vendor-Lock-in-Dimension. Wenn NHI Hound (oder ein vergleichbares Tool) zur Source of Truth für den Identitätsgraphen wird, hat man eine weitere Abhängigkeit geschaffen, die Okta, GitHub und das Cloud-IAM überspannt. Das ist in Ordnung, solange das Tool Open Source und selbst gehostet ist. Das Gespräch ändert sich in dem Moment, in dem jemand das Projekt übernimmt oder eine Managed-Version anbietet. Teams, die diese Kategorie evaluieren, sollten die Dreijahreskosten modellieren – nicht die Pilotkosten.

Eine gegenteilige Perspektive

Die Konsenslesart dieser Geschichte ist, dass jede Organisation sofort eine NHI-Discovery-Übung durchführen sollte. Für ein bestimmtes Segment würde ich das Gegenteil argumentieren: Unternehmen mit mehr als 2.000 Mitarbeitern sollten wahrscheinlich warten.

Krasnov selbst sagt, dass der aktuelle Output in dieser Größenordnung überwältigend wird. „Zu viel Chaos und zu viel Rauschen" ist seine Formulierung, und sie verweist auf eine reale Dynamik. Ein Discovery-Tool zu betreiben, das Tausende kritischer Vertrauenszustände aufdeckt, ohne die operative Kapazität, diese zu beheben, erzeugt rechtliche und regulatorische Risiken, die vorher nicht existierten. Sobald der Justiziar weiß, dass eine dokumentierte Liste mit 4.000 kritischen Identitätsrisiken existiert, verschieben sich die Maßstäbe bei der Offenlegungspflicht nach einem Sicherheitsvorfall und bei Standards der angemessenen Sorgfalt. Es gibt ein legitimes Argument dafür, zu warten, bis das Tooling ausgereift ist, die Visualisierung verbessert wurde und Remediation-Playbooks existieren – bevor man das Artefakt erzeugt, das einen in die Pflicht nimmt.

Das ist keine populäre Ansicht in Sicherheitskreisen, wo das Ethos stets lautet: „Man kann nicht beheben, was man nicht sehen kann." Aber Governance ohne die Kapazität zu handeln ist in manchen regulatorischen Kontexten schlimmer als Unwissenheit. Das ist ein Gespräch, das der Security Lead und der General Counsel gemeinsam führen müssen – nicht eine Entscheidung, die das Plattformteam einseitig trifft.

Die Frage nach den Verantwortlichen

Der Head of Platform in jedem Series-B- oder Series-C-Unternehmen, das mehr als eine Handvoll KI-Agenten betreibt, sollte diese Woche seinen CFO fragen, ob der nächste Identity-Governance-Budgetposten eine Tooling-Ausgabe oder eine Headcount-Ausgabe ist. Das sind unterschiedliche Antworten mit unterschiedlichen Dreijahreskosten. Der Open-Source-Weg kostet die Arbeitszeit eines Plattformingenieurs für sechs bis neun Monate. Der Vendor-Weg kostet weniger am Anfang und mehr später, sobald das Tool tragende Funktion übernimmt. Keine Option ist kostenlos – und so zu tun, als passe dieses Projekt ins bestehende IAM-Budget, ist der Fehler, der im Postmortem auftaucht.

Wichtigste Erkenntnisse

• Die 244-NHI-pro-Entwickler-Zahl bedeutet, dass die Identitätsangriffsfläche mit dem Produkt aus Mitarbeiterzahl und Agentendichte skaliert – nicht mit der Mitarbeiterzahl allein. Budget entsprechend planen.
• Angreifer wählen heute eine fünfminütige Token-Suche statt einer zweiwöchigen Phishing-Kampagne. Jedes Bedrohungsmodell, das Social Engineering noch als primären Angriffsvektor gewichtet, ist veraltet.
• Das kritische Risiko sind nicht explizite Berechtigungen, sondern emergente Super-Admin-Fähigkeiten aus verketteten Vertrauensbeziehungen, die kein einzelner Admin als Einheit autorisiert hat.
• Sechs bis neun Monate dedizierter Bereinigung sind für Organisationen unter 2.000 Mitarbeitern realistisch. Über dieser Schwelle produziert das aktuelle Tooling mehr Rauschen als Signal – ein Abwarten kann vertretbar sein.
• Teams, die NHI-Discovery-Tools evaluieren, sollten jetzt fragen, wer die Remediation verantwortet – nicht nur, wer die Discovery verantwortet –, und ob der Output eine rechtliche Exposition erzeugt, auf die sie noch nicht vorbereitet sind.