Workflow identity hijacking exposes a new AI authorization gap

At a glance

What this is: This is an analysis of workflow identity hijacking, a control flaw where AI workflows execute privileged actions on behalf of unauthorised requesters.

Why it matters: It matters because IAM, NHI, and agent governance teams now have to treat workflow triggers, delegation boundaries, and execution identity as separate control points.

By the numbers:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• Only 5.7% of organisations have full visibility into their service accounts.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.

👉 Read Noma Security's analysis of workflow identity hijacking in AI workflows

Context

Workflow identity hijacking is a failure of authorization design, not a failure of model comprehension. The workflow accepts a request, but the execution path uses a different identity and a wider permission set than the requester actually has, which means the security decision is happening in the wrong place.

That distinction matters for AI security programmes because prompt filters and guardrails do not establish authority boundaries. When a workflow can read messages, retrieve data, and act using creator privilege, IAM and NHI controls have to govern the trigger source, delegated execution, and downstream tool access as one chain.

The article's central point is that static AI workflows and autonomous agentic workflows are not the same thing. Static workflows still create a privileged execution channel, but the risk emerges from delegated authority rather than runtime agent autonomy.

Key questions

Q: What breaks when an AI workflow uses creator privilege for external requests?

A: The security boundary breaks because the workflow is acting as a privileged proxy for an unauthorised requester. A benign external message can trigger data access or action execution that the sender could never perform directly. The control failure is not model manipulation. It is the absence of an authorization check that binds the requester's identity to the downstream operation.

Q: Why do prompt-injection defences miss workflow identity hijacking?

A: Prompt-injection defences inspect the text that reaches the model, but workflow identity hijacking can use a perfectly normal request. The malicious step is not the prompt content. It is the workflow's decision to execute a downstream action with higher privilege than the requester owns. That is why model-layer filtering alone cannot close the gap.

Q: How should security teams control privileged AI workflows that consume email, issues, or forms?

A: Security teams should separate input handling from privileged execution and require an explicit authorization decision before any sensitive action. The requester context, the data source, and the action target all need to be evaluated together. If the workflow cannot enforce that binding, the safer choice is to strip the privilege from the workflow entirely.

Q: What role do lifecycle reviews play in AI workflow governance?

A: Lifecycle reviews expose whether a workflow still needs the service accounts, API keys, and creator privileges it carries. If those credentials outlive the business purpose, they become standing access paths for silent misuse. Recertification and offboarding should cover workflow identities, not just human users, because the access risk is tied to the execution path.

Technical breakdown

Why workflow identity hijacking is an authorization problem

Workflow identity hijacking happens when the identity that triggers a workflow is not the identity that authorizes the resulting action. In the article's example, a normal email or form submission is enough to start a predefined AI pipeline, but the pipeline later performs data access using the workflow creator's privileges. This is not prompt injection, because the model is not being tricked into unsafe behaviour. The failure sits in the delegation boundary between input acceptance and privileged execution.

Practical implication: treat trigger provenance and execution identity as separate controls, not a single trust decision.

Why static AI workflows differ from agentic workflows

A static AI workflow follows a predefined sequence, such as receive input, transform it, and execute the next step. An agentic workflow, by contrast, can choose actions, tools, and timing at runtime. That difference matters because static workflows fail through misplaced authorization, while agentic systems add independent decision-making and tool selection to the risk surface. In both cases, the security issue is identity, but the governance model has to match the actor's behaviour rather than the label attached to the system.

Practical implication: classify each AI path by its execution model before deciding which identity and access controls apply.

Why prompt-injection defences miss this attack pattern

Prompt injection defences look for malicious instructions inside content, but workflow identity hijacking can use a completely benign request. The dangerous step is not what the model reads. It is what the workflow is permitted to do after the model produces a valid output. Because the request itself looks legitimate, content-based filtering, model safety tuning, and input sanitisation can all pass while the workflow still executes privileged actions on behalf of an unauthorised party.

Practical implication: insert an explicit authorization checkpoint before any downstream tool call or data retrieval step.

Threat narrative

Attacker objective: The attacker wants to turn a normal AI workflow into a silent proxy for unauthorized data access or privileged action execution.

1. Entry occurs when an attacker submits a benign request through an unauthenticated channel such as a support inbox, issue tracker, or web form.
2. Escalation occurs when the workflow processes the request and executes downstream actions using the creator's or service account's privilege rather than the requester's authority.
3. Impact occurs when the workflow discloses sensitive data or performs privileged actions that the attacker could not have performed directly.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Workflow identity hijacking is an authorization flaw, not an AI safety flaw: The attack works because the requester's authority is decoupled from the workflow's execution authority. Prompt filters and model guardrails may still function exactly as designed, but they are being asked to solve a problem they were never built to solve. The practitioner conclusion is that authorization must be enforced at the workflow boundary, not only at the model boundary.

Static AI workflows create a privileged proxy, not an autonomous actor: The article describes predefined pipelines, not agents with runtime decision freedom. That means the governance problem is closer to delegated NHI access than to autonomous agent control, even though the business user experience feels AI-driven. The practitioner conclusion is that execution identity, trigger provenance, and output-to-action transitions need separate review.

Identity does not stop at authentication when workflows consume external input: A support email, shared document, GitHub issue, or form submission can become an authorization event if the workflow treats it as a trusted request. That is a named concept worth keeping: workflow identity hijacking is the collapse of request authority into execution authority. The practitioner conclusion is to assess who can influence what a workflow acts on, not just who can log in.

Least privilege must be measured against the least-trusted influencer, not the workflow owner: The article shows that lock-down of schedule, trigger, or inbox access alone does not solve the issue if the workflow still acts on content from untrusted senders. This is where identity governance, NHI scope, and runtime authorization intersect. The practitioner conclusion is that governance should follow the most permissive downstream action reachable from an unauthorised input.

AI workflow security is moving into lifecycle and offboarding territory: Workflows often inherit old API keys, service accounts, and creator privileges long after the original business need has changed. That makes this problem a lifecycle issue as much as a design issue, because unmanaged execution identities become silent backdoors. The practitioner conclusion is to bring workflow credentials and delegated permissions into the same lifecycle controls used for other non-human identities.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means workflow credentials are often governed without complete inventory.
• Use 52 NHI Breaches Analysis to trace how exposed credentials and overbroad delegation turn into breach paths.

What this signals

Workflow identity hijacking should push IAM teams to stop treating AI orchestration as a model problem and start treating it as delegated authority management. Once a workflow can translate a benign request into privileged action, the real control plane is the authorization boundary between requester, workflow owner, and downstream system.

Workflow identity boundary: this is the point where request context must be checked against execution privilege before any sensitive action proceeds. Organisations that cannot define that boundary will continue to confuse prompt safety with access safety, and the result will be a growing gap between AI adoption and governance maturity.

With 97% of NHIs carrying excessive privileges in the NHI Mgmt Group research, the operational lesson is clear: workflow credentials should be assessed as part of the same least-privilege programme that governs service accounts, tokens, and API keys. That is where the security team will find the reusable control pattern.

For practitioners

• Separate trigger trust from execution trust Map every workflow so the party who can start it is not assumed to be the party who may consume the resulting privilege. Define explicit authorization checks before each sensitive downstream action, especially where email, issue, or form input can influence database or tool access.
• Replace creator privilege with scoped delegation tokens Remove static administrative API keys from AI workflows and bind execution to short-lived tokens tied to the authenticated requester where possible. Where requester context cannot be propagated, block privileged actions rather than inheriting the workflow owner's access.
• Add runtime authorization checkpoints between model output and action Treat LLM output as untrusted until an access control decision confirms that the requested action is permitted for the original requester. Put that decision immediately before any read, write, or send operation that could expose sensitive data.
• Review all user-influenced inputs as attack surfaces Assess support inboxes, GitHub issues, shared documents, chat messages, and web forms as possible influence channels for privileged workflows. The relevant question is not whether the input is malicious, but whether an unauthorised sender can shape a privileged action.
• Bring workflow identities into lifecycle governance Inventory the service accounts, API keys, and creator privileges used by AI workflows, then recertify them with the same rigor applied to other NHIs. Offboard any credential that survives beyond the business need for the workflow it enables.

Key takeaways

• Workflow identity hijacking shows that AI security can fail even when the model is not manipulated, because the flaw sits in authorization rather than prompt content.
• The same security pattern appears whenever a workflow acts with creator privilege on behalf of an unauthorised requester, which makes the issue an NHI governance problem as much as an AI problem.
• The decisive control is an explicit authorization checkpoint that binds the requester, the workflow, and the downstream action before privilege is used.

Key terms

• Workflow Identity: A workflow identity is the non-human identity represented by an automated CI/CD process when it authenticates, accesses secrets, or performs actions in other systems. In practice, it is the authority carried by the pipeline itself, and it must be governed with explicit scope, review, and revocation.
• Authorization Boundary: The authorization boundary is the defined scope of systems, identities, and dependencies that must satisfy a compliance programme. In FedRAMP, it determines what the assessor evaluates and what must be documented as external, so boundary accuracy is a control decision, not a paperwork exercise.
• Delegated Execution Identity: The identity a system uses when an agent acts on behalf of a human or another agent. It includes the delegator, the executing agent, the target resource, and the policy context needed to decide whether the action is still within scope.
• Contextual Authorization Checkpoint: A contextual authorization checkpoint is a runtime decision that checks who influenced the workflow, what they asked for, and what the workflow is about to do. It is used to stop model output or workflow logic from becoming privileged action without an explicit access decision.

What's in the full article

Noma Security's full article covers the operational detail this post intentionally leaves for the source:

• The article's side-by-side comparison of direct prompt injection, indirect prompt injection, and workflow identity hijacking.
• The reported GitLost research path and the specific workflow behaviour that exposed private repository data.
• The Google Workflows disclosure context and how the vendor-confirmed fix maps to the attack pattern.
• The defensive architecture examples for identity-aware token delegation and contextual authorization checkpoints.

👉 The full Noma Security article covers the attack chain, failure mode comparisons, and defensive design details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.