KI-Tools verändern die Art, wie Unternehmen arbeiten und die Art, wie sie angegriffen werden. In den vergangenen Monaten folgte eine wachsende Zahl von Sicherheitsvorfällen einem Muster, das klassische Identity-Governance-Lösungen schlicht nicht erkennen können: Ein Mitarbeiter verbindet ein KI-Tool eines Drittanbieters mit einem Unternehmenskonto, die Infrastruktur dieses Tools wird kompromittiert, und Angreifer gelangen über die entstandene Vertrauensbeziehung direkt ins Unternehmen. Der Vercel-Angriff ist das bisher deutlichste Beispiel dafür, wie dieses Muster in der Praxis aussieht und warum Identity Attack Path Management keine Zukunftsaufgabe mehr ist.

Was bei Vercel geschah

Vercel, die Cloud-Plattform hinter Next.js, bestätigte, dass ein Angreifer das KI-Tool des Drittanbieters Context.ai kompromittierte und über ein OAuth-Token auf das Google-Workspace-Konto eines Vercel-Mitarbeiters Zugriff erlangte. Von dort konnte der Angreifer in weitere interne Systeme vorstoßen. Die Gruppierung ShinyHunters, die sich zu dem Angriff bekannte, fordert Berichten zufolge zwei Millionen Dollar für die erbeuteten Daten.

Die Kompromittierung begann, als ein Infostealer, mutmaßlich Lumma Stealer, im Februar 2026 den Rechner eines Context.ai-Mitarbeiters über einen manipulierten Roblox-Download kompromittierte. Dabei wurden OAuth-Tokens aus den Systemen von Context.ai exfiltriert. Eines dieser Tokens gehörte einem Vercel-Mitarbeiter, der sich mit seinem Firmenkonto bei der KI-Office-Suite von Context.ai angemeldet und dabei weitreichende OAuth-Berechtigungen für Vercels Google Workspace erteilt hatte. Umgebungsvariablen wie API-Schlüssel, Tokens und Datenbankzugänge waren damit potenziell offengelegt. Vercels CEO beschrieb den Angreifer als jemanden, der sich mit „bemerkenswerter Geschwindigkeit und tiefem Systemverständnis" durch die Infrastruktur bewegte. Frühe Kommentare reduzierten den Vorfall auf ein OAuth-Berechtigungsproblem. Diese Einordnung ist nicht falsch, aber sie greift zu kurz.

Kein Berechtigungsproblem – ein strukturelles Versagen

Die treffendere Erklärung liefert das sogenannte Clean Source Principle: Die Sicherheit einer Ressource ist nur so stark wie die Sicherheit jeder anderen Ressource, die Kontrolle über sie besitzt. In dem Moment, als der Vercel-Mitarbeiter Context.ai umfassende OAuth-Berechtigungen erteilte, wurde die Infrastruktur von Context.ai zu einer Abhängigkeit innerhalb der Identitätsumgebung von Vercel. Die Sicherheit des Google Workspace hing fortan auch von der Endpunktsicherheit der Context.ai-Mitarbeiter ab – eine Abhängigkeit, die kein Identitätsteam modelliert hatte. Sie entstand durch einen einzigen Klick durch einen OAuth-Zustimmungsdialog.

Context.ai war in diesem Szenario kein bloßes Software-Tool. Es war eine nicht-menschliche Identität mit delegierten Rechten innerhalb der Unternehmensinfrastruktur von Vercel – gestützt auf Systeme, die Vercel weder kontrollierte noch überwachte. Jedes KI-Tool, das Mitarbeiter mit Unternehmenskonten verknüpfen, ist in diesem strukturellen Sinne eine nicht-menschliche Identität: Es hält ein Token, trägt Berechtigungen und agiert innerhalb von Vertrauensbeziehungen, die tief in die Unternehmensumgebung hineinreichen.

Warum klassisches IAM nicht mehr ausreicht

Identity Access Management beantwortet die Frage, wer beabsichtigten Zugriff hat. Identity Attack Path Management beantwortet eine andere: Was geschieht, wenn dieser Zugriff missbraucht wird und was kann ein Angreifer von dort aus erreichen? In Umgebungen, in denen KI-Agenten Vertrauensbeziehungen schneller aufbauen, als Governance-Prozesse sie erfassen können, ist die entscheidende Frage nicht, ob ein Tool genehmigt wurde. Sie lautet: Welche Angriffspfade eröffnet die Kompromittierung dieses Tools – und führt einer davon zu kritischen Ressourcen?

Klassische Erkennungs- und Reaktionsstrategien setzen voraus, dass zwischen erstem Zugriff und tatsächlichem Schaden ein Zeitfenster zum Eingreifen bleibt. Bewegen sich Angreifer mit maschineller Geschwindigkeit durch einen bereits bestehenden Identitätsgraphen, kollabiert dieses Fenster. Wenn die Erkennung anschlägt, ist der Angriffspfad längst beschritten.

Was Unternehmen jetzt konkret tun müssen

Der Vercel-Angriff macht eines unmissverständlich klar: Es genügt nicht mehr zu regeln, wer beabsichtigten Zugriff hat. Unternehmen müssen verstehen, was passiert, wenn dieser Zugriff missbraucht wird, und welche Pfade ein Angreifer über ein einziges kompromittiertes Token nehmen kann, um kritische Systeme zu erreichen. Genau hier setzt der Ansatz von SpecterOps an: Angriffspfade proaktiv zu modellieren, bevor sie ausgenutzt werden.

In der Praxis bedeutet das, nicht-menschliche Identitäten mit derselben Sorgfalt zu erfassen wie menschliche Konten, OAuth-Berechtigungen konsequent nach dem Prinzip der minimalen Rechtevergabe zu gestalten und jederzeit nachzuverfolgen, welche Drittanbieter-Tools aktive Vertrauensbeziehungen zu den eigenen Identitätssystemen unterhalten. Viele Unternehmen wissen heute nicht einmal, wie viele solcher Verbindungen in ihrer Umgebung existieren.

Entscheidend ist nicht allein die Liste genehmigter Benutzer, sondern das vollständige Bild aller Identitäten, Berechtigungen und Vertrauensbeziehungen innerhalb einer Umgebung. Dazu gehören menschliche Konten ebenso wie KI-Agenten, Automatisierungstools und Drittanbieter-Integrationen, die im Unternehmensalltag längst dieselben Zugriffsrechte genießen wie reguläre Mitarbeiter. Angreifer denken nicht in einzelnen Konten, sie denken in Pfaden. Was ist von einem kompromittierten Startpunkt aus erreichbar, und wie weit lässt sich dieser Zugriff ausweiten? Wer Identitätssicherheit so versteht, verlagert den Fokus von reaktiver Erkennung hin zu struktureller Risikoreduzierung. Die Unternehmen, die solche Angriffe künftig am besten abwehren, werden jene sein, die diese Pfade bereits geschlossen haben, bevor der erste Angreifer sie beschreitet.