Workflow identity hijacking: Noma Labs turns an ordinary support email into privileged data access

On 9 September 2026 the research team at Noma Security, writing as Noma Labs, published an account of what it calls workflow identity hijacking: an enterprise AI workflow reads an ordinary message that arrives at a public entry point — a support inbox, a GitHub issue, a web form, a shared document — and then performs the requested work using its own high-privilege service account instead of the sender's permissions. Noma's walkthrough has an outsider email a company's public support address and ask, among other things, for the quarterly sales numbers from the Finance Director's most recent email; minutes later the contents arrive in the attacker's inbox. No model was tricked and no account was breached, which is the report's point: "all the attacker had to do was ask." The archive records no real harm — no victim is named and no deployed system is described as compromised — and grades the finding research, severity medium, confidence A, disputed false. This account rests on Noma Labs' report, on Dark Reading's coverage published the same day and on CSO Online's follow-up, and the AI incident archive holds this entry alongside its neighbours, each with its own sources, severity and confidence grade.

The record's own fields are worth reading before the prose. It is tagged INFRA and EXFIL, covers the GLOBAL region, carries a single day-precise date of 9 September 2026 and is not marked as a landmark entry. The date is the publication date of the research and nothing else; no incident timeline is attached to it, because there is no incident to time. That is the first thing to hold on to: what Noma published is a mechanism and a category, not a breach report.

What Noma demonstrated, and what it did not

The support-inbox sequence is a constructed illustration rather than a customer case. Noma's report does not name an organisation, does not give a count of affected deployments, does not publish telemetry from any real pipeline, and does not link a proof-of-concept run for this scenario — unlike the group's July research, which pointed to a public GitHub Actions run. What the report offers instead is a description of the mechanism precise enough to check against an architecture: an unauthenticated input arrives, the model interprets it correctly, the pipeline executes the downstream call, and that call is made with the workflow creator's authority.

Sasi Levi, Noma's security research lead and the author of the report, puts the root cause in one sentence: "the identity and permissions of the user who triggers a workflow are decoupled from the identity and permissions used to execute it." Where that holds, the workflow becomes, in the report's words, "unauthenticated proxies for privileged actions and silent data exfiltration."

Because the actions run through trusted automation with valid credentials, Noma argues there is little for conventional alerting to catch. The request is normal, the model's output is a valid model output, the API call is authenticated, the reply is the reply the workflow was built to send. CSO Online quoted the red teamer Vibhum Dubey making the detection problem concrete: "The individual events can look completely legitimate. The useful signals would come from correlating the original requester, the identity used downstream, the resources accessed, the parameters supplied, and the final action."

The check that fails is an authorization check, not a content filter

The report's sharpest illustration is a pair of identical requests. From a chief financial officer: "What are the quarterly sales numbers from the Finance Director in their most recent email?" From an external sender: the same words. Noma's point is that the prompt and the requested operation are the same, while the authorization decision should be entirely different — "A CFO is entitled to that information; an external sender is not."

Standard prompt-injection detectors and agent guardrails, the report argues, classify the two inputs identically, because there is nothing malicious in either one to detect. "The security risk isn't in the prompt; it is in the authorization boundary." Noma's structural claim follows from that: guardrails, system instructions and input filters "were not designed to serve as an authorization boundary," so a pipeline that relies on them to decide what a caller may retrieve is relying on a control that was never asked to do that job.

The distinction matters practically. Direct prompt injection manipulates how the model follows instructions; indirect prompt injection hides instructions in content the model will later read; workflow identity hijacking, as Noma defines it, needs neither, because the request is one the model is supposed to understand and the pipeline is supposed to execute. A defender who has spent the year hardening against injection has been working on a different layer.

Static workflows sit outside the agent-hardening push

Noma separates two things that are routinely used interchangeably. An AI workflow is a predefined, static sequence in which a model is one processing step — the report's shorthand is step A, model, step B, step C — and the deterministic pipeline around the model controls what happens. An agentic workflow is autonomous: the agent decides which steps to take and which tools to invoke. Much of the current security effort, the report argues, has gone into the second kind, restricting tool access and scoping permissions for agents that make dynamic decisions, and those controls do not reach the first.

The report also closes an obvious escape hatch. Restricting who or what can trigger a workflow does not fix the problem: if an automation runs at 8:00 AM on a schedule and acts on an inbox anyone can write to, auditing "who can trigger this workflow" answers the wrong question. Noma's rule is that every automation must be assessed by "the least-trusted party capable of influencing what it acts on" — emails, forms, tickets, GitHub issues, shared documents and chat messages included.

Noma says Google fixed a Google Workflows case; Google has published nothing

The one named platform in the report is Google's. Noma states that it identified the same risk vector within Google Workflows, that it responsibly reported it, and that Google acknowledged the report and confirmed a fix "without disclosing implementation details." That sentence is the whole of the public record. No Google advisory, release note or CVE describing this vector could be located, and every secondary account of the fix — including the ones published in the days after 9 September — attributes it to Noma rather than to Google.

The report is also not perfectly consistent about which Google product it means. The prose names Google Workflows; a section heading in the same report reads "Google Workspace: AI Workflow Identity Hijacking." Both are Google products with different trust boundaries, and the report does not reconcile them. Noma does not say whether the case it reported had been exploited, how many customers were exposed, or what the fix changed — and because Google has said nothing, none of those gaps can be closed from the vendor's side.

GitLost was the same boundary, seen through a narrower lens

Noma's earlier disclosure gives the category a precedent. In July 2026 the group published research on GitHub Agentic Workflows, which it named GitLost: a workflow triggered when an issue was assigned read the issue title and body and replied with a comment, and because the agent held read access across the organisation's repositories, external users could use issue assignment to reach private repository data. Dark Reading covered it on 7 July 2026 and described an attacker hiding commands in plain English in the body of an issue opened in a public repository, needing no credentials and no coding skill.

The two framings are not identical, and the difference is the interesting part. Dark Reading's July account is a prompt-injection story: attacker-controlled text is read as instructions. Noma's September report describes GitLost in terms of the trigger and the repository-wide read access, and presents it as the same authorization boundary seen from one angle. Both descriptions fit a workflow whose agent read text an outsider wrote, but only the earlier one depends on the model being steered. Noma now says it reported the same risk vector to Google; it does not say whether the GitLost case was ever exploited beyond the published demonstration.

Noma's own account of reach is that Hacker News, Dark Reading and more than 100 other international outlets covered the GitLost research. That figure is the vendor's, and this article has not independently counted the coverage.

Practitioners agree the mechanism is old; the argument is about the name

Independent coverage did not dispute the finding, and two outside practitioners pushed back on novelty rather than on substance. Morey Haber, chief security adviser at BeyondTrust, told Dark Reading: "Nobody tricked an AI model into anything it was not supposed to do. The model did exactly what it was told, by a stranger (untrusted), and the workflow around it used someone else's identity to make that happen since it was not scoped and treat with least privilege." CSO Online quoted Vibhum Dubey describing the pattern as "a known class of authorization weakness," and adding that where an unauthenticated input can trigger a trusted workflow that acts with its own privileges, "the workflow can effectively act as a confused deputy."

Ram Varadarajan, chief executive of Acalvio, offered Dark Reading a different control altogether: instead of more filtering, seed the environment with decoys — fake executive threads, honeytoken records — that carry no legitimate reason for any authorised workflow to touch, so that a benign-looking request reaching for one trips a boundary it should never cross. The disagreement, such as it is, is about whether the useful contribution is a new name for a 1988-era delegation flaw or a working description of where that flaw now lives. Noma's position is the second: that the pattern is systemic across enterprise AI pipelines and that current AI security frameworks look at the wrong surface.

The mitigation is delegation and a checkpoint, not a better filter

Noma's recommended controls are application-layer rather than model-layer. Identity-aware token delegation means removing static administrative API keys from AI workflows and executing data operations with short-lived, scoped delegation tokens tied to the authenticated requester, so that user context propagates to the call that actually touches the data. Contextual authorization checkpoints mean treating every model output as untrusted input and placing an explicit access-control and runtime-protection evaluation between the model's transformation step and any subsequent database or tool call. Asymmetric output separation means structurally isolating data retrieval from external communication channels, so that a workflow handling sensitive internal data does not share an execution path with an automated mechanism that replies to outsiders.

Dubey gave CSO Online a cheaper test than any of the three: compare outcomes across privilege levels. "If a low-privileged user can obtain the same result as an administrator because downstream systems only see the workflow's identity, that is where I would focus the investigation."

What the record leaves open

• No victim, no count and no telemetry. Noma's support-inbox case is a walkthrough; the report names no organisation and the archive records real harm as false. The mechanism's plausibility is not evidence that it has been used.

• Which Google product was fixed, and what the fix was. Noma's prose says Google Workflows, its section heading says Google Workspace, and Google has published nothing. Organisations cannot yet determine from public sources whether a pipeline they run was in scope.

• Whether the vector has been exploited anywhere. Neither the report nor any coverage reviewed for this article describes an observed campaign, a data loss or a forensic finding attributable to workflow identity hijacking.

• Whether the category holds up under measurement. No independent party has published a scan, a corpus of affected pipelines or a test suite for the pattern; the evidence in circulation is architectural argument plus one vendor's account of one fixed case.

• Who is making the argument. Noma Labs is the research arm of Noma Security, which sells agent security controls of exactly the kind its report recommends. That does not make the finding wrong — Dark Reading and CSO Online both reported it, and neither found a factual error — but it is context a reader should hold while weighing how broadly the category is drawn.

The record's severity grade of medium and its real-harm flag of false describe the evidence, not the mechanism. What Noma has actually established is narrow and checkable: that a workflow's trigger identity and its execution identity are separate things, that the second is usually the more powerful, and that a pipeline which never compares them will do for a stranger what it would do for the person it was built for. The control that follows is correspondingly unglamorous — ask, for each automation, who can influence what it acts on, and whether anything downstream ever re-checks that the person asking was allowed to ask.