Workflow-Identitätsübernahme: Noma Labs verwandelt eine gewöhnliche Support-E-Mail in privilegierten Datenzugriff

Am 9. September 2026 veröffentlichte das Forschungsteam von Noma Security, das unter dem Namen Noma Labs schreibt, einen Bericht über das, was es als Workflow-Identity-Hijacking bezeichnet: Ein KI-Workflow eines Unternehmens liest eine gewöhnliche Nachricht, die an einem öffentlichen Eingangspunkt eingeht – einem Support-Posteingang, einem GitHub-Issue, einem Webformular, einem gemeinsam genutzten Dokument –, und führt dann die angeforderte Arbeit mit seinem eigenen hochprivilegierten Dienstkonto anstelle der Berechtigungen des Absenders aus. In Nomas Beispielablauf schreibt eine außenstehende Person eine E-Mail an die öffentliche Support-Adresse eines Unternehmens und bittet unter anderem um die Quartalsumsatzzahlen aus der letzten E-Mail des Finanzdirektors; wenige Minuten später treffen die Inhalte im Posteingang des Angreifers ein. Kein Modell wurde getäuscht und kein Konto wurde kompromittiert, und genau das ist der Punkt des Berichts: „Alles, was der Angreifer tun musste, war zu fragen.“ Das Archiv verzeichnet keinen echten Schaden – kein Opfer wird genannt und kein eingesetztes System als kompromittiert beschrieben – und stuft den Befund als Forschung ein, Schweregrad mittel, Konfidenz A, umstritten: nein. Diese Darstellung stützt sich auf den Bericht von Noma Labs, auf die am selben Tag veröffentlichte Berichterstattung von Dark Reading und auf die Folgeberichterstattung von CSO Online, und das KI-Vorfallarchiv führt diesen Eintrag neben seinen Nachbareinträgen, wobei jeder Eintrag eigene Quellen, Schweregrad und Konfidenzstufe hat.

Die Felder des Datensatzes selbst sind eine Lektüre wert, bevor man sich dem Fließtext zuwendet. Er ist mit INFRA und EXFIL getaggt, deckt die Region GLOBAL ab, trägt ein einziges tagesgenaues Datum – den 9. September 2026 – und ist nicht als Meilenstein-Eintrag gekennzeichnet. Das Datum ist das Veröffentlichungsdatum der Untersuchung und nichts weiter; es hängt keine Vorfallchronologie daran, denn es gibt keinen Vorfall, der zeitlich zu erfassen wäre. Das ist der erste Punkt, den man festhalten sollte: Was Noma veröffentlicht hat, ist ein Mechanismus und eine Kategorie, kein Bericht über einen Sicherheitsvorfall.

Was Noma gezeigt hat – und was nicht.

Die Support-Posteingang-Sequenz ist eine konstruierte Illustration und kein Kundenfall. Der Bericht von Noma nennt keine Organisation, gibt keine Zahl betroffener Deployments an, veröffentlicht keine Telemetrie aus einer realen Pipeline und verlinkt keinen Proof-of-Concept-Lauf für dieses Szenario – anders als die Juli-Recherche der Gruppe, die auf einen öffentlichen GitHub-Actions-Lauf verwies. Was der Bericht stattdessen bietet, ist eine Beschreibung des Mechanismus, die präzise genug ist, um sie gegen eine Architektur zu prüfen: eine nicht authentifizierte Eingabe geht ein, das Modell interpretiert sie korrekt, die Pipeline führt den nachgelagerten Aufruf aus, und dieser Aufruf erfolgt mit der Berechtigung des Workflow-Erstellers.

Sasi Levi, {{1}}Leiterin der Sicherheitsforschung bei Noma und Autorin des Berichts{{/1}}, bringt die Grundursache in einem Satz auf den Punkt: „{{2}}Die Identität und die Berechtigungen des Nutzers, der einen Workflow auslöst, sind von der Identität und den Berechtigungen, die zu seiner Ausführung verwendet werden, entkoppelt.{{/2}}“ Wo das zutrifft, wird der Workflow – mit den Worten des Berichts – zu „{{3}}nicht authentifizierten Proxys für privilegierte Aktionen und stille Datenexfiltration.{{/3}}“

Da die Aktionen über vertrauenswürdige Automatisierung mit gültigen Anmeldedaten laufen, argumentiert Noma, gebe es für herkömmliche Alarmierung wenig zu erkennen. Die Anfrage ist normal, die Ausgabe des Modells ist eine gültige Modellausgabe, der API-Aufruf ist authentifiziert, und die Antwort ist die Antwort, für deren Versand der Workflow gebaut wurde. CSO Online zitierte den Red-Teamer Vibhum Dubey, der das Erkennungsproblem greifbar machte: „Die einzelnen Ereignisse können völlig legitim aussehen. Die nützlichen Signale ergäben sich aus der Korrelation des ursprünglichen Anfragenden, der nachgelagert verwendeten Identität, der zugegriffenen Ressourcen, der bereitgestellten Parameter und der abschließenden Aktion.“

Die fehlschlagende Prüfung ist eine Autorisierungsprüfung, kein Inhaltsfilter.

Die prägnanteste Veranschaulichung des Berichts ist ein Paar identischer Anfragen. Von einem Finanzvorstand: „Wie lauten die vierteljährlichen Verkaufszahlen des Finanzdirektors in seiner neuesten E-Mail?“ Von einem externen Absender: dieselben Worte. Nomas Punkt ist, dass der Prompt und die angeforderte Operation dieselben sind, während die Autorisierungsentscheidung gänzlich anders ausfallen sollte – „Ein CFO hat Anspruch auf diese Informationen; ein externer Absender nicht.“

Standard-Detektoren für Prompt-Injection und Agent-Guardrails, so argumentiert der Bericht, klassifizieren die beiden Eingaben identisch, weil in keiner von beiden etwas Böswilliges zu erkennen ist. „Das Sicherheitsrisiko liegt nicht im Prompt; es liegt in der Autorisierungsgrenze.“ Nomas strukturelle Behauptung folgt daraus: Guardrails, Systemanweisungen und Eingabefilter „wurden nicht dafür konzipiert, als Autorisierungsgrenze zu dienen“, sodass eine Pipeline, die sich auf sie verlässt, um zu entscheiden, was ein Aufrufer abrufen darf, sich auf eine Kontrolle verlässt, die nie für diese Aufgabe vorgesehen war.

Die Unterscheidung ist praktisch bedeutsam. Direkte Prompt-Injection manipuliert, wie das Modell Anweisungen befolgt; indirekte Prompt-Injection versteckt Anweisungen in Inhalten, die das Modell später liest; Workflow-Identitäts-Hijacking, wie Noma es definiert, braucht weder das eine noch das andere, weil die Anfrage eine ist, die das Modell verstehen und die Pipeline ausführen soll. Ein Verteidiger, der das Jahr damit verbracht hat, gegen Injection zu härten, hat auf einer anderen Ebene gearbeitet.

Statische Workflows bleiben von der Agent-Hardening-Initiative unberührt

Noma trennt zwei Dinge, die üblicherweise austauschbar verwendet werden. Ein KI-Workflow ist eine vordefinierte, statische Abfolge, in der ein Modell einen Verarbeitungsschritt darstellt – die Kurzschreibweise des Berichts lautet Schritt A, Modell, Schritt B, Schritt C –, und die deterministische Pipeline rund um das Modell kontrolliert, was geschieht. Ein agentischer Workflow ist autonom: Der Agent entscheidet, welche Schritte er unternimmt und welche Tools er aufruft. Ein Großteil der derzeitigen Sicherheitsbemühungen, so argumentiert der Bericht, sei in die zweite Art geflossen – Beschränkung des Toolzugriffs und Festlegung des Berechtigungsumfangs für Agenten, die dynamische Entscheidungen treffen –, und diese Kontrollen erreichten die erste nicht.

Der Bericht schließt außerdem eine offensichtliche Hintertür. Die Einschränkung, wer oder was einen Workflow auslösen kann, behebt das Problem nicht: Wenn eine Automatisierung nach Zeitplan um 8:00 Uhr läuft und auf ein Postfach einwirkt, in das jeder schreiben kann, beantwortet die Prüfung der Frage „wer kann diesen Workflow auslösen“ die falsche Frage. Nomas Regel lautet, dass jede Automatisierung anhand „der am wenigsten vertrauenswürdigen Partei, die beeinflussen kann, worauf sie einwirkt“ bewertet werden muss – einschließlich E-Mails, Formulare, Tickets, GitHub-Issues, gemeinsam genutzter Dokumente und Chatnachrichten.

Noma sagt, Google habe einen Fall in Google Workflows behoben; Google habe nichts veröffentlicht.

Die einzige im Bericht namentlich genannte Plattform ist die von Google. Noma gibt an, denselben Risikovektor in Google Workflows identifiziert, ihn verantwortungsvoll gemeldet zu haben und dass Google den Bericht zur Kenntnis genommen und eine Behebung bestätigt habe, „ohne Implementierungsdetails offenzulegen“. Dieser Satz ist alles, was öffentlich dazu dokumentiert ist. Es ließ sich kein Google-Sicherheitshinweis, Versionshinweis oder CVE finden, der diesen Vektor beschreibt, und jede sekundäre Darstellung der Behebung – einschließlich der in den Tagen nach dem 9. September veröffentlichten – schreibt sie Noma und nicht Google zu.

Der Bericht ist außerdem nicht völlig konsistent darin, welches Google-Produkt er meint. Der Fließtext nennt Google Workflows; eine Abschnittsüberschrift im selben Bericht lautet „Google Workspace: AI Workflow Identity Hijacking“. Beides sind Google-Produkte mit unterschiedlichen Vertrauensgrenzen, und der Bericht bringt sie nicht miteinander in Einklang. Noma sagt nicht, ob der gemeldete Fall ausgenutzt wurde, wie viele Kunden betroffen waren oder was die Behebung geändert hat – und da Google nichts dazu gesagt hat, lassen sich diese Lücken auf Anbieterseite nicht schließen.

GitLost war dieselbe Grenze, betrachtet durch eine engere Linse

Nomas frühere Offenlegung verschafft der Kategorie einen Präzedenzfall. Im Juli 2026 veröffentlichte die Gruppe eine Studie zu GitHub Agentic Workflows, die sie GitLost nannte: Ein Workflow, der ausgelöst wurde, wenn ein Issue zugewiesen wurde, las den Titel und den Text des Issues und antwortete mit einem Kommentar, und weil der Agent über Lesezugriff auf die Repositories der Organisation verfügte, konnten externe Benutzer die Issue-Zuweisung nutzen, um an Daten aus privaten Repositories zu gelangen. Dark Reading berichtete am 7. Juli 2026 darüber und beschrieb einen Angreifer, der Befehle in einfachem Englisch im Text eines in einem öffentlichen Repository eröffneten Issues versteckte und dabei weder Anmeldedaten noch Programmierkenntnisse benötigte.

Die beiden Darstellungen sind nicht identisch, und der Unterschied ist der interessante Teil. Dark Readings Juli-Bericht ist eine Prompt-Injection-Geschichte: Angreiferkontrollierter Text wird als Anweisung gelesen. Nomas September-Bericht beschreibt GitLost anhand des Auslösers und des repositoryweiten Lesezugriffs und stellt es als dieselbe Autorisierungsgrenze dar, aus einem bestimmten Blickwinkel betrachtet. Beide Beschreibungen passen zu einem Workflow, dessen Agent Text gelesen hat, den ein Außenstehender geschrieben hat, aber nur die frühere hängt davon ab, dass das Modell gesteuert wird. Noma sagt nun, dass es denselben Risikovektor an Google gemeldet habe; es sagt nicht, ob der GitLost-Fall jemals über die veröffentlichte Demonstration hinaus ausgenutzt wurde.

Nomas eigene Angabe zur Reichweite lautet, dass Hacker News, Dark Reading und mehr als 100 weitere internationale Medien über die GitLost-Forschung berichtet haben. Diese Zahl stammt vom Anbieter, und dieser Artikel hat die Berichterstattung nicht unabhängig nachgezählt.

Fachleute sind sich einig, dass der Mechanismus alt ist; der Streit dreht sich um den Namen.

Unabhängige Berichterstattung stellte den Befund nicht infrage, und zwei externe Fachleute äußerten Einwände gegen die Neuheit statt gegen die Substanz. Morey Haber, Chief Security Adviser bei BeyondTrust, sagte gegenüber Dark Reading: „Niemand hat ein KI-Modell zu etwas verleitet, was es nicht tun sollte. Das Modell tat genau das, was ihm von einem Fremden (nicht vertrauenswürdig) gesagt wurde, und der Workflow darum herum nutzte die Identität von jemand anderem, um das zu ermöglichen, da er nicht abgegrenzt und nicht nach dem Prinzip der minimalen Rechte behandelt wurde.“ CSO Online zitierte Vibhum Dubey, der das Muster als „eine bekannte Klasse von Autorisierungsschwächen“ beschrieb und hinzufügte, dass ein vertrauenswürdiger Workflow, der mit seinen eigenen Berechtigungen agiert, dann, wenn eine nicht authentifizierte Eingabe ihn auslösen kann, „effektiv als verwirrter Stellvertreter (confused deputy) handeln kann“.

Ram Varadarajan, Chief Executive von Acalvio, bot Dark Reading einen ganz anderen Kontrollmechanismus an: Statt weiter zu filtern, sollte die Umgebung mit Ködern bestückt werden – gefälschte Executive-Threads, Honeytoken-Datensätze –, für die es keinen legitimen Grund gibt, dass ein autorisierter Workflow sie berührt, sodass eine harmlos wirkende Anfrage, die nach einem solchen Köder greift, eine Grenze auslöst, die sie niemals hätte überschreiten dürfen. Die Uneinigkeit, soweit es eine gibt, dreht sich darum, ob der nützliche Beitrag ein neuer Name für einen Delegationsfehler aus der Zeit von 1988 ist oder eine brauchbare Beschreibung dafür, wo dieser Fehler heute zu finden ist. Nomas Position ist die zweite: dass das Muster systemisch durch KI-Pipelines in Unternehmen hindurchgeht und dass aktuelle KI-Sicherheitsframeworks auf die falsche Oberfläche blicken.

Die Abhilfe besteht in Delegation und einem Kontrollpunkt, nicht in einem besseren Filter.

Die von Noma empfohlenen Kontrollen liegen auf Anwendungsebene und nicht auf Modellebene. Identitätsbewusste Token-Delegierung bedeutet, statische administrative API-Schlüssel aus KI-Workflows zu entfernen und Datenoperationen mit kurzlebigen, bereichsbezogenen Delegierungstoken auszuführen, die an den authentifizierten Anforderer gebunden sind, sodass der Benutzerkontext bis zu dem Aufruf weitergegeben wird, der tatsächlich auf die Daten zugreift. Kontextbezogene Autorisierungsprüfpunkte bedeuten, jede Modellausgabe als nicht vertrauenswürdige Eingabe zu behandeln und eine explizite Bewertung der Zugriffskontrolle und des Laufzeitschutzes zwischen dem Transformationsschritt des Modells und jedem nachfolgenden Datenbank- oder Tool-Aufruf zu platzieren. Asymmetrische Ausgabetrennung bedeutet, die Datenabfrage strukturell von externen Kommunikationskanälen zu isolieren, sodass ein Workflow, der sensible interne Daten verarbeitet, keinen Ausführungspfad mit einem automatisierten Mechanismus teilt, der auf Außenstehende antwortet.

Dubey gab CSO Online einen kostengünstigeren Test als jeden der drei: Vergleichen Sie die Ergebnisse über Berechtigungsstufen hinweg. „Wenn ein Benutzer mit geringen Rechten dasselbe Ergebnis wie ein Administrator erzielen kann, weil nachgelagerte Systeme nur die Identität des Workflows sehen, dann würde ich dort die Untersuchung ansetzen.“

Was der Bericht offen lässt

• Kein Opfer, keine Zahl und keine Telemetrie. Nomas Support-Postfach-Fall ist ein Walkthrough; der Bericht nennt keine Organisation, und das Archiv verzeichnet echten Schaden als falsch. Die Plausibilität des Mechanismus ist kein Beweis dafür, dass er eingesetzt wurde.

• Welches Google-Produkt gepatcht wurde und worin der Fix bestand. Nomas Fließtext nennt Google Workflows, ihre Abschnittsüberschrift nennt Google Workspace, und Google hat nichts veröffentlicht. Organisationen können anhand öffentlicher Quellen noch nicht feststellen, ob eine von ihnen betriebene Pipeline betroffen war.

• Ob der Vektor irgendwo ausgenutzt wurde. Weder der Bericht noch eine für diesen Artikel geprüfte Berichterstattung beschreibt eine beobachtete Kampagne, einen Datenverlust oder einen forensischen Befund, der auf Workflow-Identitäts-Hijacking zurückzuführen ist.

• Ob die Kategorie einer Messung standhält. Keine unabhängige Partei hat einen Scan, einen Korpus betroffener Pipelines oder eine Testsuite für das Muster veröffentlicht; die im Umlauf befindlichen Belege sind architektonische Argumente plus die Darstellung eines Anbieters zu einem einzigen konkreten Fall.

• Wer das Argument vorbringt. Noma Labs ist der Forschungsbereich von Noma Security, das genau die Art von Agenten-Sicherheitskontrollen verkauft, die sein Bericht empfiehlt. Das macht den Befund nicht falsch – Dark Reading und CSO Online haben beide darüber berichtet, und keines der beiden fand einen sachlichen Fehler –, aber es ist Kontext, den ein Leser im Blick behalten sollte, während er abwägt, wie breit die Kategorie gefasst ist.

Die Schweregrad-Einstufung „mittel“ des Eintrags und sein Real-Harm-Kennzeichen „false“ beschreiben die Beweislage, nicht den Mechanismus. Was Noma tatsächlich festgestellt hat, ist eng umrissen und überprüfbar: dass die Trigger-Identität eines Workflows und seine Ausführungsidentität getrennte Dinge sind, dass die zweite in der Regel die mächtigere ist und dass eine Pipeline, die diese beiden nie vergleicht, für einen Fremden tun wird, was sie für die Person tun würde, für die sie gebaut wurde. Die daraus folgende Kontrolle ist entsprechend unspektakulär – frage bei jeder Automatisierung, wer beeinflussen kann, worauf sie einwirkt, und ob irgendetwas nachgelagert je erneut prüft, dass die fragende Person berechtigt war zu fragen.