Kapning av arbetsflödesidentitet: Noma Labs förvandlar ett vanligt supportmejl till privilegierad dataåtkomst

Den 9 september 2026 publicerade forskningsteamet på Noma Security, under namnet Noma Labs, en redogörelse för det de kallar workflow identity hijacking: ett AI-arbetsflöde i ett företag läser ett vanligt meddelande som anländer till en offentlig ingång – en supportinkorg, ett GitHub-ärende, ett webbformulär, ett delat dokument – och utför sedan det begärda arbetet med sitt eget högprivilegierade tjänstekonto i stället för avsändarens behörigheter. Nomas genomgång låter en utomstående mejla ett företags offentliga supportadress och bland annat be om kvartalets försäljningssiffror från ekonomidirektörens senaste mejl; några minuter senare anländer innehållet till angriparens inkorg. Ingen modell lurades och inget konto komprometterades, vilket är rapportens poäng: "allt angriparen behövde göra var att fråga." Arkivet registrerar ingen verklig skada – inget offer namnges och inget driftsatt system beskrivs som komprometterat – och graderar fyndet som research, allvarlighetsgrad medium, konfidens A, omstritt false. Den här redogörelsen vilar på Noma Labs rapport, på Dark Readings bevakning som publicerades samma dag och på CSO Onlines uppföljning, och AI-incidentarkivet har denna post tillsammans med sina grannar, var och en med sina egna källor, allvarlighetsgrad och konfidensgrad.

Postens egna fält är värda att läsa innan den löpande texten. Den är taggad INFRA och EXFIL, täcker regionen GLOBAL, bär ett enda dagprecist datum – den 9 september 2026 – och är inte markerad som en milstolpe. Datumet är forskningens publiceringsdatum och inget annat; ingen incidenttidslinje är knuten till det, eftersom det inte finns någon incident att tidsbestämma. Det är det första att hålla fast vid: det Noma publicerade är en mekanism och en kategori, inte en intrångsrapport.

Vad Noma demonstrerade, och vad det inte gjorde

Sekvensen för supportinkorgen är en konstruerad illustration snarare än ett kundärende. Nomas rapport namnger ingen organisation, anger inget antal påverkade driftsättningar, publicerar ingen telemetri från någon verklig pipeline och länkar inte till någon proof-of-concept-körning för detta scenario – till skillnad från gruppens forskning från juli, som hänvisade till en offentlig GitHub Actions-körning. Det rapporten i stället erbjuder är en beskrivning av mekanismen som är tillräckligt precis för att kunna kontrolleras mot en arkitektur: en oautentiserad inmatning anländer, modellen tolkar den korrekt, pipelinen utför det nedströms anropet, och det anropet görs med arbetsflödesskaparens behörighet.

Sasi Levi, Nomas säkerhetsforskningschef och författare till rapporten, sammanfattar grundorsaken i en mening: ”identiteten och behörigheterna för den användare som utlöser ett arbetsflöde är frikopplade från identiteten och behörigheterna som används för att köra det.” Där det gäller blir arbetsflödet, med rapportens ord, ”oautentiserade proxyservrar för privilegierade åtgärder och tyst dataexfiltrering.”

Eftersom åtgärderna körs via betrodd automation med giltiga autentiseringsuppgifter hävdar Noma att det finns lite för konventionell larmning att fånga upp. Begäran är normal, modellens utdata är en giltig modellutdata, API-anropet är autentiserat och svaret är det svar som arbetsflödet byggdes för att skicka. CSO Online citerade red team-medlemmen Vibhum Dubey, som gjorde detekteringsproblemet konkret: "De enskilda händelserna kan se helt legitima ut. De användbara signalerna skulle komma från att korrelera den ursprungliga förfrågaren, den identitet som används nedströms, de resurser som används, de angivna parametrarna och den slutliga åtgärden."

Kontrollen som misslyckas är en auktoriseringskontroll, inte ett innehållsfilter.

Rapportens skarpaste illustration är ett par identiska förfrågningar. Från en finanschef: "Vilka är de kvartalsvisa försäljningssiffrorna från ekonomidirektören i dennes senaste e-post?" Från en extern avsändare: samma ord. Nomas poäng är att prompten och den begärda åtgärden är densamma, medan auktoriseringsbeslutet borde vara helt annorlunda – "En finanschef har rätt till den informationen; en extern avsändare har inte det."

Standarddetektorer för prompt-injektion och agentguardrails, hävdar rapporten, klassificerar de två indata på identiskt sätt, eftersom det inte finns något skadligt i någon av dem att upptäcka. "Säkerhetsrisken ligger inte i prompten; den ligger i auktoriseringsgränsen." Nomas strukturella påstående följer av detta: guardrails, systeminstruktioner och indatafilter "utformades inte för att fungera som en auktoriseringsgräns", så en pipeline som förlitar sig på dem för att avgöra vad en anropare får hämta förlitar sig på en kontroll som aldrig fick uppgiften att göra det.

Skillnaden spelar praktisk roll. Direkt prompt-injektion manipulerar hur modellen följer instruktioner; indirekt prompt-injektion gömmer instruktioner i innehåll som modellen senare kommer att läsa; kapning av arbetsflödesidentitet, så som Noma definierar det, behöver inget av dessa, eftersom begäran är en som modellen förväntas förstå och pipelineflödet förväntas utföra. En försvarare som har ägnat året åt att härda mot injektion har arbetat på ett annat lager.

Statiska arbetsflöden ligger utanför satsningen på agenthärdning

Noma skiljer på två saker som rutinmässigt används synonymt. Ett AI-arbetsflöde är en fördefinierad, statisk sekvens där en modell utgör ett bearbetningssteg – rapportens kortform är steg A, modell, steg B, steg C – och den deterministiska pipeline som omger modellen styr vad som händer. Ett agentiskt arbetsflöde är autonomt: agenten avgör vilka steg som ska tas och vilka verktyg som ska anropas. Mycket av det nuvarande säkerhetsarbetet, hävdar rapporten, har gått till den andra typen: att begränsa verktygsåtkomst och avgränsa behörigheter för agenter som fattar dynamiska beslut, och dessa kontroller når inte den första.

Rapporten stänger också ett uppenbart kryphål. Att begränsa vem eller vad som kan utlösa ett arbetsflöde löser inte problemet: om en automatisering körs enligt schema kl. 08:00 och agerar på en inkorg som vem som helst kan skriva till, besvarar granskningen "vem kan utlösa detta arbetsflöde" fel fråga. Nomas regel är att varje automatisering måste bedömas utifrån "den minst betrodda part som kan påverka det den agerar på" – e-post, formulär, ärenden, GitHub-ärenden, delade dokument och chattmeddelanden inräknade.

Noma säger att Google har åtgärdat ett Google Workflows-ärende; Google har inte publicerat något.

Den enda namngivna plattformen i rapporten är Googles. Noma uppger att de identifierade samma riskvektor i Google Workflows, att de rapporterade den på ett ansvarsfullt sätt och att Google bekräftade rapporten och en rättning "utan att avslöja implementeringsdetaljer". Den meningen utgör hela den offentliga dokumentationen. Inget säkerhetsmeddelande från Google, ingen versionsnotis och ingen CVE som beskriver denna vektor kunde hittas, och varje sekundär redogörelse för rättningen – inklusive de som publicerades dagarna efter den 9 september – tillskriver den Noma i stället för Google.

Rapporten är inte heller helt konsekvent när det gäller vilken Google-produkt den avser. I löptexten namnges Google Workflows; en avsnittsrubrik i samma rapport lyder ”Google Workspace: AI Workflow Identity Hijacking”. Båda är Google-produkter med olika förtroendegränser, och rapporten förklarar inte hur de hänger samman. Noma säger inte om det fall som rapporterades hade utnyttjats, hur många kunder som exponerades eller vad åtgärden förändrade – och eftersom Google inte har sagt något kan ingen av dessa luckor täppas till från leverantörens sida.

GitLost var samma gräns, sedd genom en snävare lins

Nomas tidigare avslöjande ger kategorin ett prejudikat. I juli 2026 publicerade gruppen forskning om GitHub Agentic Workflows, som den kallade GitLost: ett arbetsflöde som utlöstes när ett ärende tilldelades, läste ärendets titel och brödtext och svarade med en kommentar, och eftersom agenten hade läsbehörighet till organisationens samtliga repositorier kunde externa användare använda ärendetilldelning för att nå data i privata repositorier. Dark Reading rapporterade om det den 7 juli 2026 och beskrev en angripare som gömde kommandon i klartext i brödtexten i ett ärende som öppnats i ett offentligt repo, utan att behöva några inloggningsuppgifter eller någon kodningskunskap.

De två inramningarna är inte identiska, och skillnaden är det intressanta. Dark Readings juliartikel är en berättelse om prompt-injektion: angriparkontrollerad text läses som instruktioner. Nomas septemberrapport beskriver GitLost utifrån utlösaren och läsbehörigheten för hela kodförrådet, och framställer det som samma auktoriseringsgräns sedd från en vinkel. Båda beskrivningarna passar ett arbetsflöde där en agent läste text som en utomstående hade skrivit, men endast den tidigare är beroende av att modellen styrs. Noma säger nu att man rapporterade samma riskvektor till Google; man säger inte om GitLost-fallet någonsin utnyttjades utöver den publicerade demonstrationen.

Nomas egen redogörelse för räckvidden är att Hacker News, Dark Reading och fler än 100 andra internationella medier rapporterade om GitLost-forskningen. Siffran är leverantörens egen, och den här artikeln har inte självständigt räknat bevakningen.

Utövare är eniga om att mekanismen är gammal; tvisten gäller namnet

Oberoende rapportering bestred inte fyndet, och två utomstående yrkesverksamma invände mot nyhetsvärdet snarare än mot sakfrågan. Morey Haber, chefsäkerhetsrådgivare på BeyondTrust, sade till Dark Reading: "Ingen lurade en AI-modell att göra något den inte skulle göra. Modellen gjorde exakt vad den blev tillsagd av en främling (ej betrodd), och arbetsflödet runt den använde någon annans identitet för att åstadkomma detta, eftersom det inte var avgränsat och hanterades med minsta behörighet." CSO Online citerade Vibhum Dubey, som beskrev mönstret som "en känd klass av auktoriseringssvaghet" och tillade att när en oautentiserad indata kan utlösa ett betrott arbetsflöde som agerar med sina egna privilegier, "kan arbetsflödet i praktiken agera som en förvirrad ställföreträdare."

Ram Varadarajan, vd för Acalvio, erbjöd Dark Reading en helt annan typ av kontroll: i stället för mer filtrering, plantera lockbeten i miljön – falska chefstrådar, honeytoken-poster – som inte har någon legitim anledning för något auktoriserat arbetsflöde att röra, så att en begäran som ser godartad ut och sträcker sig efter en sådan utlöser en gräns den aldrig borde passera. Oenigheten, om man nu kan kalla den det, handlar om huruvida det användbara bidraget är ett nytt namn på en delegeringsbrist från 1988 eller en fungerande beskrivning av var den bristen nu finns. Nomas hållning är den andra: att mönstret är systemiskt i företags-AI-pipelines och att nuvarande AI-säkerhetsramverk tittar på fel yta.

Åtgärden är delegering och en kontrollpunkt, inte ett bättre filter.

Nomas rekommenderade kontroller ligger på applikationslagret snarare än modellagret. Identitetsmedveten tokendelegering innebär att statiska administrativa API-nycklar tas bort från AI-arbetsflöden och att dataoperationer utförs med kortlivade delegeringstoken med begränsat omfång som är knutna till den autentiserade förfrågande parten, så att användarkontexten fortplantas till det anrop som faktiskt rör data. Kontextuella auktoriseringskontrollpunkter innebär att varje modellutdata behandlas som otrusted indata och att en explicit åtkomstkontroll och utvärdering av skydd vid körning placeras mellan modellens transformeringssteg och efterföljande databas- eller verktygsanrop. Asymmetrisk utdataseparering innebär att datahämtning strukturellt isoleras från externa kommunikationskanaler, så att ett arbetsflöde som hanterar känsliga interna data inte delar exekveringsväg med en automatiserad mekanism som svarar utomstående.

Dubey gav CSO Online ett billigare test än något av de tre: jämför utfall mellan behörighetsnivåer. "Om en användare med låg behörighet kan få samma resultat som en administratör eftersom nedströms system bara ser arbetsflödets identitet, är det där jag skulle fokusera utredningen."

Vad dokumentet lämnar öppet

• Inget offer, inget antal och ingen telemetri. Nomas fall med supportinkorgen är en genomgång; rapporten namnger ingen organisation och arkivet registrerar verklig skada som falsk. Att mekanismen är rimlig är inte bevis för att den har använts.

• Vilken Google-produkt som åtgärdades och vad åtgärden var. Nomas löptext anger Google Workflows, medan avsnittsrubriken anger Google Workspace, och Google har inte publicerat något. Organisationer kan ännu inte utifrån offentliga källor avgöra om en pipeline som de kör omfattades.

• Huruvida attackvektorn har utnyttjats någonstans. Varken rapporten eller någon av de artiklar som granskats för den här artikeln beskriver en observerad kampanj, en dataförlust eller ett forensiskt fynd som kan tillskrivas kapning av arbetsflödesidentiteter.

• Huruvida kategorin håller måttet när den mäts. Ingen oberoende part har publicerat en genomsökning, en korpus av drabbade pipelines eller en testsvit för mönstret; den evidens som cirkulerar är arkitektoniska argument plus en leverantörs redogörelse för ett enda åtgärdat fall.

• Vem som för fram argumentet. Noma Labs är forskningsavdelningen inom Noma Security, som säljer säkerhetskontroller för agenter av exakt det slag som dess rapport rekommenderar. Det gör inte fyndet felaktigt — Dark Reading och CSO Online rapporterade båda om det, och ingen av dem hittade något sakfel — men det är ett sammanhang som läsaren bör ha i åtanke när den väger hur brett kategorin är definierad.

Registreringens allvarlighetsgrad medium och dess flagga för verklig skada satt till false beskriver bevisningen, inte mekanismen. Det Noma faktiskt har fastställt är snävt och kontrollerbart: att ett arbetsflödes utlösaridentitet och dess exekveringsidentitet är separata saker, att den andra vanligtvis är den mäktigare, och att en pipeline som aldrig jämför dem kommer att göra för en främling vad den skulle göra för personen den byggdes för. Kontrollen som följer är motsvarande oglamorös – fråga, för varje automatisering, vem som kan påverka det den agerar på, och om något nedströms någonsin kontrollerar igen att personen som frågar hade tillåtelse att fråga.