Noma's Workflow Identity Hijacking turns a service account into a privilege proxy for strangers

Levi's three conditions are conjunctive: an untrusted or weakly authenticated input, a workflow executing with privileges greater than the requester's, and a path that lets the result of that privileged operation flow back to the requester ^[8]. A service identity on its own is normal, and Levi will not say every workflow using one is vulnerable ^[10]. The failure arrives when that identity effectively becomes a privilege proxy for someone who never possessed the permissions ^[11]. The useful audit question is whether the output of a privileged read can reach a sender nobody authenticated, regardless of whether the pipeline runs on a high-privilege service account or a developer API key ^[15].

Two shapes held under Noma's testing, according to Levi: authorization enforced again at the point of data access or action, and privileged retrieval structurally separated from attacker-controlled output ^[9]. The first is a check inside the tool call. The second is wiring, and it is the one you can verify by reading a graph rather than trusting a policy engine.

The public inbox is the hard case, and Levi does not dodge it. There is no authenticated requester, and running strictly with the sender's permissions means zero access to internal data, which kills most support automations ^[13]. His answer splits what the workflow may touch from what it may tell the requester: an anonymous workflow can classify tickets, summarize them, retrieve public documentation, route issues and identify the likely customer ^[14]. That design works because it puts the mail-search tool off the anonymous path entirely. Identity propagation is unglamorous plumbing, which is why it tends to be the last wire connected.

On scale, the evidence is deliberately thin, and Levi says so: Noma did not approach this as a statistical survey of workflow products, so he would not give a success rate that implied broader coverage than the work performed ^[5]. What is on the record is a recurring architectural pattern across more than five major workflow environments, of which two are named, Google Workflows and the GitHub scenario Noma disclosed as GitLost ^[4]. That leaves at least three environments unnamed ^[21]. If you want to know whether your stack is one of them, the demonstration will not tell you; the three conditions will.

The decoupling diagnosis is the publication's characterisation of Noma's framing of its own findings ^[15], and the fix leaves in place the defenses the industry has spent two years building. Prompt injection is the attack those defenses were built for, tricking the model into disobeying its instructions ^[22]. Levi's claim is narrower and more durable: enforcing authorization at the privileged operation prevents prompt injection, or completely benign instructions, from borrowing somebody else's privileges ^[16].

For anyone building agent workflows, that converts a filtering problem into an accounting problem. Every sensitive tool call needs an authorization decision that takes the requester's identity as an input ^[18]. When the requester cannot be named, the tool does not belong on that path.