Notifications
Clear all
Topic starter
14/09/2026 10:09 am
TL;DR: Workflow identity hijacking lets attackers trigger privileged AI workflows with ordinary, unauthenticated requests, bypassing prompt-injection defences because the flaw sits in authorization, not model manipulation, according to Noma Security. The real control failure is assuming the requester and the executor share the same authority, when the workflow actually acts with creator-level privilege.
NHIMG editorial — based on content published by Noma Security: Workflow Identity Hijacking, the Silent Backdoor in AI Workflows
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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.
👉 Read Noma Security's analysis of workflow identity hijacking in AI workflows →
Workflow identity hijacking: are your AI workflows checking identity?
Explore further
14/09/2026 10:10 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Workflow identity hijacking exposes a new AI authorization gap
