Workflow identity hijacking

Workflow identity hijacking lets someone trigger a privileged action without any privilege, by asking through a door the workflow trusts. The model processes the request normally. The failure is that it runs with the workflow’s identity, not the sender’s.

How it works

An AI workflow is a predefined sequence with an LLM as one step inside it. The workflow reads input, transforms it, then performs downstream actions. In most deployments those run with the credentials the workflow creator configured — a high-privilege service account or a developer API key.

The requester’s permissions are never consulted at that step. Noma’s opening example is an attacker who emails a public support address asking for the quarterly sales figures in the Finance Director’s most recent email. The workflow reads, searches, and replies. No prompt injection, no breach: the requester had no authority for what happened, and the workflow lent it to them.

Prompt injection manipulates what the model does; this attack exploits whose authority the workflow uses. Noma names the pattern: a trusted workflow acting with its own privileges for a requester who never had them.

Why it matters

Prompt filters and model guardrails cannot see this attack because nothing in the request is wrong. An identical question from the CFO and from an external attacker is classified the same way; the risk is not in the prompt but in the authorization boundary.

It also evades conventional alerts: the workflow uses valid credentials, does what it was built to do, and replies through its usual channel. Noma demonstrated the pattern across more than five major workflow environments, including Google Workflows and the earlier GitHub scenario, GitLost.

The fix is architectural: re-check authorization at the privileged operation itself, with scoped short-lived tokens, a checkpoint before sensitive tool calls, and separation of data retrieval from external replies.

Where definitions disagree

The name “hijacking” overlaps with an older research coinage. The JAW paper (arXiv 2605.11229) calls a related attack class “agentic workflow hijacking” (AWH): an adversary crafts inputs such as GitHub issue comments to manipulate the LLM agent inside an agentic workflow into credential exfiltration or command execution. That attack works by manipulating the model — it is a form of prompt injection against an agent.

Workflow identity hijacking needs no such manipulation. The two are distinct attack classes that land in the same surface of attacker-controlled workflow input, which is why they are easy to conflate. A deployment can be vulnerable to either independently.

Questions and answers

Is workflow identity hijacking the same as prompt injection?

No. Prompt injection manipulates how the model follows instructions by hiding adversarial instructions in text the model reads. Workflow identity hijacking leaves the model alone: a completely ordinary request is executed exactly as designed, and the failure is that the workflow acts with its own high-privilege identity rather than the requester's permissions. Noma Labs, which named the attack, states that standard prompt-injection detectors and agent guardrails classify the benign input identically to legitimate traffic because there is no malicious phrasing in the prompt.

Why does a workflow act with more privilege than the person who triggered it?

Because the identity that triggers a workflow is decoupled from the identity that executes it. When the workflow performs downstream actions it runs as the workflow creator's service account or developer API key, and the original requester's permissions are not re-evaluated at that boundary. Noma's research lead Sasi Levi describes the failure as a missing authorization check: the request is accepted through an unauthenticated intake, and the execution then borrows an identity the requester never possessed.

How do you defend against workflow identity hijacking?

Noma Labs recommends three controls: identity-aware token delegation (short-lived, scoped tokens tied to the authenticated requester instead of static admin keys), contextual authorization checkpoints (an explicit access-control step between the model's output and any database or tool call), and asymmetric output separation (workflows that read sensitive internal data do not share an execution path with automated external replies). Levi's one-line version: do not let the LLM's output directly become authorization.

Where does the attack enter?

Through unauthenticated intake surfaces: a public support inbox, a web form, a GitHub issue, or a shared document. Anyone who can put content in front of the workflow can trigger it, which is why Noma frames the audit question as the least-trusted party capable of influencing what the workflow acts on.