Was uns die Vercel- und OpenAI-Vorfälle über OAuth-Tokens und Schattenidentitäten lehren

Zwei Vorfälle mit großer Sichtbarkeit. Zwei völlig unterschiedliche Unternehmen. Eine identische Ursache.

Im April 2026 bestätigte Vercel - die Cloud-Plattform hinter Millionen von Next.js-Deployments -, dass Angreifer sich unautorisierten Zugriff auf interne Systeme verschafft hatten. Ein kompromittierter Context.ai-Mitarbeiter löste eine Kette von Ereignissen aus, die bis zum Workspace-Account eines Vercel-Mitarbeiters führte und letztlich zu einem Einbruch in Vercels interne Datenbank - aktuell für 2 Millionen US-Dollar auf BreachForums angeboten.

Einige Monate zuvor, im Oktober 2025, entdeckten Forscher, dass OpenAIs neu gestarteter ChatGPT-Atlas-Browser unverschlüsselte OAuth-Tokens in einer SQLite-Datenbank mit zu großzügigen Dateirechten auf macOS speicherte - ein Fehler, der nur wenige Tage nach dem Launch am 21. Oktober 2025 gefunden wurde und gängige Verschlüsselungspraktiken großer Browser umgeht. Ein klassischer OpenAI Sicherheitsvorfall mit OAuth Bezug.

Zwei Vorfälle. Zwei Angriffsvektoren. Und doch dieselbe Ursache: OAuth-Tokens und KI-Agenten-Credentials, die komplett außerhalb von Identity Governance operieren.

Security-Teams haben über Jahre die Authentifizierung gehärtet. MFA, SSO, Zero Trust - die Haustür ist verriegelt. Aber diese Angriffe kamen nicht durch die Haustür. Sie kamen über OAuth-Berechtigungen, die niemand überwacht hat, KI-Tools, die niemand freigegeben hat, und Credentials, für die niemand jemals Governance definiert hat. Das ist ein anderes Problem. Und es braucht eine andere Lösung.

Der Vercel-Vorfall: Ein OAuth-Grant, den niemand überprüft hat

Was ist genau passiert - und warum sollte Ihr Incident-Response-Team das hier lesen?

Ein Vercel-Mitarbeiter hatte eine KI-App - konkret ein veraltetes, Consumer-orientiertes "AI Office Suite"-Produkt von Context.ai - in seinen Google-Workspace-Tenant eingebunden. Vercel war nicht einmal als offizieller Context.ai-Kunde registriert. Sehr wahrscheinlich handelte es sich um eine Self-Service-Testversion: schnell verbunden, kurz genutzt, dann vergessen - aber mit einem zusätzlichen, unsichtbaren Knoten in der Angriffsfläche der Organisation.

Als Context.ai kompromittiert wurde - mutmaßlich durch einen Infostealer, nachdem ein Mitarbeiter nach Roblox-Cheats gesucht hatte - nutzten die Angreifer die im Context.ai-Produkt gespeicherten OAuth-Tokens, um nachgelagerte Kundenkonten zu erreichen. Dazu gehörte auch das Google-Workspace-Konto eines Vercel-Mitarbeiters. Dieser User hatte weitreichenden Zugriff auf Daten und Secrets in Vercels Systemen: interne Dashboards, Mitarbeiterdaten, API-Keys, NPM-Tokens und GitHub-Tokens. Die Angreifer exfiltrierten alles und forderten Vercel mit 2 Millionen US-Dollar Lösegeld.

Auffällig ist, was in dieser gesamten Kette fehlt: eine Schwachstelle. Ein Zero-Day. Ein Brute-Force-Angriff. Nichts davon.

Das war keine Malware-Exotik. Kein Zero-Day. Es war ein vertrauenswürdiger Zugriff, der genau so funktionierte, wie er designt wurde. Ein einmal erteilter OAuth-Grant, nie überprüft, der alle Workspace-Berechtigungen eines Vercel-Mitarbeiters direkt in die Hände des Angreifers trug.

Aus Sicht von Vercel hätte dieser Angriff verhindert werden können, wenn Mitarbeiter daran gehindert worden wären, neue OAuth-Integrationen ohne Admin-Approval zu verbinden - ein simpler Schalter im Google-Admin-Panel. Oder wenn die Integration in einem regelmäßigen Audit aufgefallen und entfernt worden wäre. Zwei Kontrollen. Beide gehören zur Identity Governance. Keine davon ist eine reine Authentifizierungskontrolle.

Das OpenAI-Atlas-Problem: Wenn KI-Tools Credentials speichern wie im Jahr 2005

Der Vercel-Vorfall zeigt das OAuth-Wildwuchs-Problem, das durch Mitarbeiter entsteht. Der OpenAI-Atlas-Fall zeigt die andere Hälfte: was passiert, wenn KI-Tools selbst mit den ihnen gewährten Credentials fahrlässig umgehen - ein Paradebeispiel für mangelhafte OAuth Sicherheit.

Rund um ChatGPT Atlas, einen macOS-Browser für den Zugriff auf OpenAI-Modelle, tauchte eine Sicherheitsbedenken auf. Forscher fanden heraus, dass OAuth-Tokens - zur Authentifizierung von Usern - im Klartext in einer lokalen SQLite-Datenbank lagen. Dieser Fehler ermöglicht es Angreifern oder bösartigen lokalen Prozessen, User-Konten zu kapern und auf private Konversationen, API-Daten und verknüpfte Dienste zuzugreifen.

Anders als die meisten modernen Browser verschlüsselte Atlas sensible Authentifizierungsdaten nicht. Session-Tokens und Zugangsdaten wurden ungeschützt gespeichert - jeder Prozess mit lokalem Systemzugriff konnte sie auslesen.

Hier kommt der Governance-Aspekt ins Spiel, den viele Post-Mortems ausblenden: Es ist egal, wie gut Ihre MFA-Policy ist, wenn die erzeugten Tokens unverschlüsselt in einer Datei liegen, die jeder Prozess auf der Maschine lesen kann. Die Authentifizierung selbst hat funktioniert. Der Credential-Lifecycle - wie dieses Token gespeichert, gescoped, rotiert und widerrufen wird - wurde schlicht nicht governed.

Unverschlüsselte Tokens ermöglichen es Angreifern, User zu imitieren und nicht nur ChatGPT-Konversationen, sondern - bei überlappenden Scopes - auch verknüpfte Dienste zu erreichen. Ein Muster, das wir aus früheren OAuth-Leakages in KI-Tools kennen.

Das ist das New-Species-of-Identities-Problem in seiner greifbarsten Form. KI-Agenten, Browser und agentische Tools sammeln Credentials über den gesamten Stack: OAuth-Tokens, Session-Cookies, API-Keys - und fast keine davon werden mit derselben Strenge behandelt wie menschliche Identitäten. Sie haben keinen Lifecycle. Kein Offboarding. Keine Access-Reviews.

Das sind keine Ausreißer - das ist ein Muster

Bevor Sie diese Vorfälle als Randfälle abtun, lohnt ein Blick auf den größeren Trend.

2025 starteten Scattered Lapsus$ Hunters OAuth-getriebene Supply-Chain-Angriffe auf Salesforce- und Google-Workspace-Tenants, nachdem sie Salesloft kompromittiert hatten. Über 1.000 Organisationen waren betroffen - darunter Google, Cloudflare, Rubrik, Elastic, Proofpoint, JFrog, Zscaler, Tenable, Palo Alto Networks, CyberArk, BeyondTrust, Qualys und viele weitere - mit mehr als 1,5 Milliarden gestohlenen Datensätzen.

Der Identity Exposure Report 2026 identifizierte 18,1 Millionen geleakte API-Keys und Tokens in nur einem Jahr. Die Angriffsfläche umfasst dabei nicht-menschliche Identitäten (NHIs); allein 2025 wurden 18,1 Millionen exponierte API-Keys und Tokens gezählt.

Eine Analyse von Grip Security über 23.000 SaaS-Umgebungen fand einen Anstieg KI-bezogener Angriffe um 490 % im Jahresvergleich. In der März-2026-Analyse von Grip Security zu 23.000 SaaS-Umgebungen zeigte sich ein 490-%-Anstieg von KI-bezogenen Angriffen - ein klarer Indikator, dass KI-Tools und OAuth Sicherheit in den Fokus gehören.

Der Verizon DBIR 2025 berichtet, dass 54 % aller Ransomware-Angriffe auf infostealer-bedingten Credential-Diebstahl zurückgehen. Der Verizon DBIR 2025 zeigte zusätzlich: 54 % aller Ransomware-Angriffe gingen auf Credential-Diebstahl durch Infostealer zurück, und 46 % der Systeme mit kompromittierten Unternehmenszugängen waren nicht gemanagte Geräte.

Die Vorfälle von 2025 bestätigten eine unbequeme Wahrheit, die viele Sicherheitsverantwortliche längst kennen, aber selten konsequent adressieren: Die größten Schwachstellen sind nicht ungepatchte Systeme oder Zero-Day-Exploits - es sind die vertrauenswürdigen Logins, Tokens und Integrationen, auf denen der Betrieb jeden Tag aufbaut. Angreifer "brechen" zunehmend nicht mehr klassisch ein. Sie nutzen dieselben Credentials, die Cloud-Workloads und Third-Party-APIs antreiben, um sich wie Insider durch Umgebungen zu bewegen - oft über Monate, bevor es jemand bemerkt.

Die Frequenz steigt. Und der rote Faden durch all diese Vorfälle ist derselbe: OAuth-Tokens, API-Credentials und KI-Agentenzugriffe ohne Governance - einmal ausgestellt, nie überprüft, nie widerrufen.

Wie groß ist Ihre Shadow-Identity-Exposure?

Bevor Sie das Problem beheben können, müssen Sie seine Dimensionen in Ihrer eigenen Umgebung verstehen. Nutzen Sie diesen Rechner, um das OAuth-Wachstum und das Risiko durch Schattenidentitäten in Ihrer Organisation zu schätzen - basierend auf realistischen Branchenparametern.

Die meisten Security-Teams sind vom Ergebnis überrascht. Grund: Das flächendeckend über alle SaaS-Apps hinweg zu tun, ist deutlich schwieriger, als es klingt. Sie brauchen ein vollständiges, aktuelles Inventar. Sie müssen in jeder App Admin sein. Und die jeweilige App muss Ihnen überhaupt erlauben, OAuth-Grants tenantweit einzuschränken und zu löschen.

Genau deshalb unterschätzen die meisten Unternehmen ihre OAuth-Grants um den Faktor drei bis fünf - und warum viele Post-Mortems zu Vorfällen wie dem Vercel Datenleck zeigen, dass die ausgenutzten Credentials seit Monaten unüberprüft im System lagen.

Die eigentliche Diagnose: Governance-Versagen, nicht Authentifizierungs-Versagen

Hier liegt die Unterscheidung, die viele Security-Teams übersehen - und die in der Berichterstattung zu Datenlecks häufig untergeht.

Authentifizierung beantwortet: Ist das die richtige Person oder das richtige System?

Governance beantwortet: Soll diese Person oder dieses System genau jetzt mit genau diesen Berechtigungen auf genau diese Ressourcen zugreifen dürfen?

Vercels SSO hat funktioniert. OpenAIs Authentifizierungs-Stack hat funktioniert. Die OAuth-Tokens wurden in beiden Fällen legitim für legitim authentifizierte Sessions ausgestellt. Das Problem war nicht ein Versagen der Authentifizierung. Das Problem war, dass niemand geregelt hat, was nach der Authentifizierung passiert.

Wenn Mitarbeiter neue Anwendungen via OAuth-Login und Third-Party-Integrationen anbinden, ohne zentrale Steuerung, wächst die Angriffsfläche durch ungemanagte Tools schleichend - sensible Daten werden exponiert, Compliance-Lücken entstehen.

Diese Lücke ist nicht neu - aber sie wird durch den massiven, dezentralen Einsatz von KI-Tools dramatisch größer. Der KI-Run wirkt wie ein Verstärker. Jede neue KI-Integration ist ein neuer OAuth-Grant. Jeder Grant ist eine neue Schattenidentität. Und jede Schattenidentität ist ein potenzielles zweites Vercel.

Die drei Governance-Fehler hinter diesen Vorfällen

1. Kein Inventar aller OAuth-Grants
Weder Vercel noch - im Atlas-Fall - die durchschnittliche Enterprise mit KI-Tools verfügt über ein aktuelles, zentrales Inventar aller OAuth-Grants im gesamten Stack. Ohne Inventar gibt es keine Review. Und Sie können nichts widerrufen, von dessen Existenz Sie nichts wissen.

2. Kein Lifecycle-Management für nicht-menschliche Identitäten
Agentic Sprawl - die unkontrollierte Vermehrung von KI-Agenten, ihrer Credentials und ihrer kumulierten Berechtigungen - bedeutet: Diese Identitäten haben keinen Joiner-Mover-Leaver-Prozess. Sie werden nicht offgeboardet, wenn ein Projekt endet. Sie akkumulieren weiter - und werden zur Angriffsfläche.

3. Keine kontinuierlichen Access-Reviews für Third-Party-Integrationen
Eine allzu typische Geschichte: Die SaaS-App, von einem einzelnen Mitarbeiter getestet, sporadisch genutzt, mit Kernsystemen integriert - und vergessen. Ein unsichtbarer Knoten in der Angriffsfläche der Organisation. Statische, quartalsweise Access-Reviews - wenn sie überhaupt so häufig laufen - finden den OAuth-Grant von gestern nicht, den jemand aus dem Engineering gesetzt hat, um ein neues Tool auszuprobieren.

Was das wirklich behebt: Governance auf Berechtigungsebene, nicht Sicherheit auf Prompt-Ebene

Die instinktive Reaktion nach einem Vorfall wie dem Vercel Datenleck ist oft: noch mehr Authentifizierungs-Kontrollen - strengere MFA-Regeln, zusätzliche CASB-Policies, neue SIEM-Alerts. Das ist nicht per se falsch. Aber es adressiert die alte Bedrohungslandschaft.

Die eigentliche Lösung ist Governance auf Berechtigungs- und Identitätsebene, nicht Sicherheit auf Prompt-Ebene. Konkret:

1. Universelle Connector-Abdeckung - inklusive Apps ohne SCIM oder APIs

Viele "moderne IGA"-Lösungen behaupten, das OAuth-Problem zu lösen, decken in der Realität aber nur SCIM-fähige Apps ab. Das sind in der Praxis meist 20-40 % Ihrer tatsächlichen Umgebung. Der Rest - Long-Tail-SaaS-Tools, KI-Integrationen, interne Applikationen - bleibt ohne Identity Governance. Genau dort entstehen Vercel-artige OAuth-Grants.

Vollständige Identity Governance bedeutet: Verbindung zu jeder App im gesamten Stack - unabhängig davon, ob sie SCIM, eine API oder gar nichts davon unterstützt - und ein aktuelles, governed Abbild jeder Identität, jedes Credentials, jedes Tokens und jeder Integration je User und Agent. Keine SCIM-Steuer. Keine Abdeckungs-Lücken.

2. Feingranulare Kontrolle statt nur Gruppenmitgliedschaft

SCIM-Level-Governance sagt Ihnen, dass ein User Zugriff auf GitHub hat. Sie sagt nicht, auf welche Repositories, welche Umgebungen oder welche Secrets die OAuth-Grants dieses Users zugreifen können. Feingranulare Kontrolle geht tiefer: Channel-, Repository-, Projekt- und Environment-Ebene - genau die Granularität, die "Diese OAuth-App kann alle Google-Drive-Dateien dieses Users lesen" als Risiko markiert hätte, bevor Context.ai kompromittiert wurde.

3. Lifecycle-Governance für nicht-menschliche Identitäten

Nicht-menschliche Identitäten - Service-Accounts, API-Keys, Workload-Identities, Zertifikate, OAuth-Apps, Machine-to-Machine-Zugriffe - übertreffen in vielen Cloud-nativen Organisationen längst die Zahl der Menschen. Die größten Risiken: fehlender Lifecycle, überprivilegierter Zugriff, exponierte Credentials.

KI-Agenten, OAuth-Apps, Service-Accounts und API-Tokens brauchen denselben Lifecycle wie menschliche User: Provisionierung nach Least-Privilege-Prinzip, kontinuierliche Reviews, konsequente Deprovisionierung, sobald sie nicht mehr benötigt werden. Aktuell trifft das auf die wenigsten nicht-menschlichen Identitäten zu.

4. Kontinuierliche Access-Reviews - statt quartalsweiser Abnicker-Runden

Beim Vercel Datenleck wurde ein Grant ausgenutzt, der so lange unüberprüft blieb, bis Context.ai kompromittiert und der Angreifer aktiv wurde. Ein Modell kontinuierlicher Governance - in dem Zugriffe in Echtzeit gegen Richtlinien geprüft werden, statt beim nächsten Quartals-Review - verkürzt dieses Zeitfenster drastisch.

Kontinuierliche Governance bedeutet nicht mehr Arbeit für das Team. Sie bedeutet agentische Workflows (KI-gesteuerte, autonome Prozesse), die Zugriffe in Echtzeit bewerten, Anomalien markieren und Revocations auslösen - ohne dass ein Mensch ein Ticket anlegen muss.

Das ist das Governance-Modell, das {{link:sso-isn-t-governance-let-that-sink-in-2}} SSO-Tools nie leisten sollten - und das Legacy-IGA-Anbieter mit zu viel Enterprise-Overhead und zu wenig Geschwindigkeit ausbremsen.

Was CISOs mitnehmen sollten

Wenn Sie als Security-Verantwortliche oder CISO das hier lesen, sind das die Fragen, die Sie sich diese Woche zur eigenen Umgebung stellen sollten:

• Haben Sie ein aktuelles Inventar aller OAuth-Grants in Ihrem gesamten Stack? Nicht nur der Grants, die Ihr IdP kennt - auch derer, die einzelne Mitarbeitende für Tools vergeben haben, die sie einmal ausprobiert haben.
• Haben Ihre KI-Agenten-Credentials einen Lifecycle? Werden sie nach Least-Privilege-Prinzip vergeben? Werden sie geprüft? Was passiert, wenn das Projekt endet oder das Tool abgekündigt wird?
• Welcher Prozentsatz Ihrer Applikationslandschaft liegt außerhalb Ihrer Identity-Governance-Abdeckung? Wenn die Antwort über 30 % liegt, haben Sie eine Vercel-große Lücke.
• Wann haben Sie zuletzt Third-Party-OAuth-Integrationen überprüft - nicht nur in Google Workspace, sondern über Ihren gesamten SaaS-Stack hinweg?

Identity, lange als administrativer Layer betrachtet, ist zur zentralen Kampffläche der Enterprise-Security geworden. Die Frage Richtung 2026 ist nicht, ob Angreifer weiterhin Identitäten ins Visier nehmen - sondern ob die Branche Identity endlich als Fundament von Resilienz behandelt und nicht als Unterkategorie von Access Control.

Die Vorfälle bei Vercel und OpenAI Atlas sind keine reinen Warnungen vor KI-Tools. Sie zeigen, was passiert, wenn Identity Governance nicht mit der Geschwindigkeit Schritt hält, mit der Identitäten - menschlich und nicht-menschlich - erstellt, verknüpft und vergessen werden.

Ihre Authentifizierungs-Landschaft ist wahrscheinlich solide. Ihre Governance-Schicht ist dort, wo die echte Exposure lebt.

Für einen strukturierten Ansatz zur Governance menschlicher und nicht-menschlicher Identitäten - inklusive KI-Agenten und OAuth-Grants - zeigt der {{link:step-by-step-guide-to-securing-ai-agent-access}} Step-by-Step-Guide zur Absicherung von KI-Agenten-Zugriffen den kompletten Lifecycle von Provisionierung bis kontinuierlicher Review. Und wenn Sie evaluieren, wo Sie mit Governance für Non-Human Identities ansetzen, erklärt der {{link:non-human-identity-governance-vs-traditional}} Vergleich von NHI-Governance vs. traditionellem IAM, warum klassische Ansätze hier regelmäßig scheitern.

Fazit

Der Vercel-Vorfall war ein Lösegeld von 2 Millionen US-Dollar - gebaut auf einem vergessenen OAuth-Grant. Die OpenAI-Atlas-Schwachstelle war ein offengelegtes Authentifizierungs-Token, weil niemand geregelt hat, wie KI-Tools Credentials speichern. Beide waren Governance-Fehler, die wie reine Security-Incidents aussehen.

Die Lösung sind weder bessere Passwörter noch strengere MFA. Die Lösung heißt vollständige Identity Governance - ein aktuelles, kontinuierliches, feingranulares Bild jeder Identität (menschlich und nicht-menschlich), jedes OAuth-Grants, jedes KI-Agenten-Credentials und jeder App in Ihrem gesamten Stack, inklusive derjenigen ohne SCIM oder APIs. Genau hier setzt moderne Identity Governance an - jenseits von SSO, jenseits klassischer IGA-Tools.

Das ist nicht das, was Legacy-IGA-Anbieter liefern. Es ist nicht das, wofür SSO gebaut wurde. Es ist das, was eine dedizierte, universelle Governance-Schicht bietet - kontinuierlich, in Echtzeit und ohne 12-monatiges Implementierungsprojekt.

Häufig gestellte Fragen

{{component:faq_placeholder}}