"Workflow Identity Hijacking": An Anonymous Request Makes a Privileged AI Workflow Fetch Data the Requester Was Never Allowed to See

Google Workflows and GitHub Agentic Workflows, and by extension any AI automation triggered by public or low-privilege input while executing under a service account

Sasi Levi, security research lead at Noma Security, published a class of authorization failure in AI workflows on September 9, 2026 that requires no prompt injection at all. The worked example is an attacker emailing a company's public support address to ask for the quarterly sales numbers in the finance director's most recent email, and the AI workflow behind that inbox reading the message, searching, and replying. The model is not manipulated; it reads the request correctly and performs exactly the task it was built for. The defect is that the workflow runs under elevated credentials while the person who triggered it holds none, and nothing between the two checks whether that requester was entitled to the result. An anonymous email sender, a public GitHub issue author, a web form submitter, an external collaborator, a chat participant, or anyone able to edit a shared document can therefore have quarterly sales figures, mailbox contents, cloud storage, source code, or CRM records retrieved and returned to them by an automation acting on its owner's behalf. Levi's framing is that "the core failure is that the requester had no authority to make that request." The researchers connected the finding to the earlier GitLost work on GitHub workflows that processed assigned issues while holding broad repository-read permissions, where external issue activity could reach private repository data. Noma reported the pattern recurring across more than five major workflow environments. Google acknowledged the disclosure and shipped a fix, and neither Google nor GitHub published what they changed. No CVE was assigned, and the attack leaves logs that look entirely legitimate. The recommended controls are per-user identity propagation, least-privilege service accounts, explicit authorization checks before any retrieval or sharing step, restrictions on public triggers, and audit logging

The permissions attach to the workflow, not to the person the workflow is acting for, and the authorization decision is made once at configuration time rather than at each downstream action. Every defense aimed at making the model harder to trick is irrelevant here, because the model was never tricked