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.
Editorial analysis by NHI Mgmt Group, based on content published by Noma Security: “Workflow Identity Hijacking: The Silent Backdoor in AI Workflows”.
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.
Q: Why does workflow identity hijacking create risk for sensitive internal data?
A: The risk comes from a mismatch between who asks and what the workflow can access.
Q: How should security teams govern AI-enabled workflows that can act on their own?
A: Treat them as identity-governed execution paths, not just software features.
Practitioner guidance
- Separate trigger identity from execution identity Map every AI workflow step to the identity that actually performs the downstream action, then remove any design where a low-trust requester can inherit creator-level privileges.
- Propagate user context into downstream calls Replace standing workflow credentials with short-lived, scoped delegation tied to the authenticated requester so that the action can only occur within the requester’s entitlement.
- Insert authorization checkpoints after LLM transformation Treat LLM output as untrusted input and require a policy decision before any database query, message send, or repository access occurs.
Bottom line: Benign-looking inputs can still drive privileged AI workflows into unauthorized action when the authorization check sits at the wrong boundary.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
14/09/2026 10:10 am
Workflow identity hijacking is an authorization failure, not a model-safety failure. Security teams have spent heavily on prompt injection, but that control family addresses the wrong boundary when a workflow executes with creator privilege. The decisive question is who is authorised to cause the privileged action, not whether the request contains malicious wording. Practitioners should treat this as a governance issue first and an AI issue second.
A question worth separating out:
Q: What is the difference between prompt injection and workflow identity hijacking?
A: Prompt injection manipulates the model through crafted instructions, usually to change behaviour. Workflow identity hijacking does not rely on trick prompts. It exploits weak authentication and permission handling between workflow steps, so the system answers as if the requester already has access. The control gap is identity and authorization, not instruction parsing.
👉 Read our full editorial: Workflow identity hijacking exposes a new AI authorization gap