Noma's researcher tells LDS the AI attack no filter can see

Noma Labs published research on September 9 describing Workflow Identity Hijacking, an AI workflow attack that requires no prompt injection because the identity triggering a workflow is decoupled from the identity executing it, according to Sasi Levi, Security Research Lead at Noma Security and author of the research. Levi told Lets Data Science the pattern recurred across more than 5 major workflow environments, including Google Workflows and the GitHub scenario previously disclosed as GitLost, and that neither Google nor GitHub provided enough technical detail to say precisely what changed in their remediations. Levi said the highest-return control is an authorization check before every sensitive tool call, which prevents prompt injection or benign instructions from borrowing another identity's privileges.

Noma's researcher tells LDS the AI attack no filter can see Sasi Levi, Security Research Lead at Noma Security, answered Lets Data Science in writing about Workflow Identity Hijacking, the research Noma Labs published on September 9. The attack needs no prompt injection: an ordinary request sent to a public inbox is executed by an AI workflow that runs with privileges the sender never had. Levi says the pattern recurred across more than five major workflow environments, that neither Google nor GitHub disclosed what they changed to fix it, that the attack leaves logs that look legitimate, and that the single highest-return control is an authorization check before every sensitive tool call. The AI attack the industry has spent two years defending against is prompt injection: trick the model into disobeying its instructions. The research Noma Labs published on September 9 describes an attack those defenses were never built to see, because nothing in it is tricked. Sasi Levi , Security Research Lead at Noma Security and the author of the research, told Lets Data Science in written answers that the model is not the problem. "The attacker can send a completely straightforward request, the model can understand it correctly, and every component can behave exactly as designed. The problem is that the workflow executes that request using an identity with privileges the requester does not have." Noma calls it Workflow Identity Hijacking. The research opens with the example: an attacker emails a company's public support address asking for the quarterly sales numbers in the Finance Director's most recent email, and the AI workflow behind that inbox reads the message, searches, and replies. Noma's diagnosis, which is the company's framing of its own findings, is that the identity that triggers a workflow has been decoupled from the identity that executes it. Pipelines run on high-privilege service accounts or developer API keys rather than on the permissions of whoever sent the request. Where it fails, and where it holds Levi was careful about scale. "We did not approach this as a statistical survey of workflow products, so I don't want to give a success-rate number that would imply broader coverage than we actually performed." What Noma demonstrated, Levi said, is "a recurring architectural pattern across more than 5 major workflow environments, including Google Workflows and the GitHub scenario we previously disclosed as GitLost." The condition that matters is not whether a workflow uses a service identity. "A service identity by itself is normal. The dangerous combination is an untrusted or weakly authenticated input, a workflow executing with privileges greater than those of the requester, and a path that allows the result of that privileged operation to flow back to the requester." Systems held "when authorization was enforced again at the point of data access or action, or when privileged retrieval and attacker-controlled output were structurally separated." The conclusion is narrower than the headline: "So no, I would not say every workflow using a service identity is vulnerable. The failure happens when that identity effectively becomes a privilege proxy for someone who never possessed those permissions." Fixing that boundary does not retire prompt injection, Levi said. It "prevents prompt injection, or even completely benign instructions, from borrowing somebody else's privileges." What Google and GitHub changed: unknown Noma's research says Google acknowledged the report on Google Workflows and confirmed a fix without disclosing implementation details. We asked what mechanically changed, there and at GitHub after GitLost, because the fix is the most instructive part for anyone building this themselves. The answer is that Noma does not know. "Neither Google nor GitHub provided us with enough technical detail about their remediation to say precisely what changed internally." Levi would not fill the gap with inference: "I don't want to reverse-engineer a vendor's fix from the outside and present speculation as fact." The lesson for builders does not depend on the patches: "authorization should be enforced at the privileged operation itself." The support inbox problem The hard case is Noma's own example. A public inbox has no authenticated requester, and running strictly with the sender's permissions means zero access to internal data, which would kill most support automations. Levi's answer separates workflow access from requester disclosure. An anonymous workflow "can classify tickets, summarize them, retrieve public documentation, route issues, identify the likely customer, or perform internal enrichment. What it should not do is assume that because the workflow itself can read internal systems, whatever it retrieves is automatically safe to send back to the sender." Before account-specific data goes back out, "you need a trust transition": authentication, an authenticated portal, ownership verification, or a hand-off to a person. What it looks like in logs "At the application layer, many of the events look legitimate." A normal inbound request. A workflow that starts normally. A valid-looking model result. An authenticated API call the service account is genuinely allowed to make. A reply through the usual channel. "There may be no authentication failure, no malicious payload, no jailbreak signature, and no obviously anomalous model behavior." The detection point, Levi said, is "the relationship between identities and data flows rather than the text of the prompt": who initiated the workflow, which identity touched the resource, how sensitive it was, and where the result went. In Noma's testing, "the identity-boundary problem itself was not surfaced as a security event." GitLost had prompt-injection defenses in the path, "which we were able to get past." The cheapest fix Noma's research lists three mitigations: identity-aware token delegation, contextual authorization checkpoints, and asymmetric output separation. Asked which buys the most protection per engineering hour, Levi chose the checkpoint, "an explicit authorization checkpoint immediately before every sensitive tool call or data access," and reduced it to one instruction: "Do not let the LLM's output directly become authorization." Delegation is "architecturally stronger" but depends on whether downstream services support it. Output separation matters most for externally triggered workflows. The pattern Levi worries about most is a public or semi-public trigger, then a model, then a privileged connector or API credential, then an automatic reply to the original sender. It appears "in support automation, CRM assistants, ticket triage, email workflows, developer workflows, and low-code automation." There is no number attached, and Levi declined to invent one: "We don't currently have enough representative telemetry to give a defensible prevalence percentage." This lands where Front's VP of engineering https://letsdatascience.com/news/front-tells-lds-how-it-scores-ai-agents-before-trusting-them-f754fce7 landed with us last week: identity and permissions have to be architectural primitives before any agent is trusted. Noma's four questions are the audit: who influenced the workflow, what were they authorized to do, what greater authority did the agent possess, and was that distinction enforced when the agent acted. Key Points - 1The flaw is an authorization boundary, not a model failure : the workflow executes an ordinary request using a service identity with privileges the requester never had. Levi's condition for failure is untrusted input, a workflow more privileged than the requester, and a path for the result to flow back. "So no, I would not say every workflow using a service identity is vulnerable." - 2 Neither Google nor GitHub told Noma what they changed. Levi declined to guess: "I don't want to reverse-engineer a vendor's fix from the outside and present speculation as fact." Noma reports the pattern across more than five major workflow environments, ran no statistical survey, and gives no prevalence figure. - 3 In logs, the attack looks legitimate , so prompt filtering cannot catch it. The signal is a low-privileged event causing a privileged identity to touch sensitive data that then leaves for a lower-trust destination. The cheapest fix is an authorization checkpoint before every sensitive tool call: "Do not let the LLM's output directly become authorization." Scoring Rationale Written answers provided directly to Lets Data Science by the author of new security research that identifies an attack class distinct from prompt injection, with candid limits on scale and on what vendors disclosed about their fixes. Directly actionable for practitioners wiring AI workflows to privileged systems, which is a large share of our audience. Sources Original reporting, with the public references used alongside it. LDS Exclusive Reporting based on written answers given directly to Let's Data Science by Sasi Levi, Security Research Lead, Noma Security . Practice interview problems based on real data 1,625 SQL & Python problems across 15 industry datasets — the exact type of data you work with. Try 250 free problems /problems