Workflow identity hijacking exposes a new AI authorization gap

At a glance

What this is: This analysis shows that benign-looking requests can drive AI workflows into privileged actions when authorization is checked on the workflow trigger rather than on the requester.

Why it matters: It matters because IAM teams need to govern who can influence downstream execution, not just who can start an AI workflow or submit input.

Context

Workflow identity hijacking is an AI authorization problem, not a prompt-manipulation problem. A workflow can process a normal request exactly as designed and still expose sensitive data if the requester is not entitled to the privilege that the workflow uses during execution.

The gap appears when the identity that submits input is decoupled from the identity that executes the action. For IAM, NHI, and AI governance programmes, that means the control boundary has shifted from model safety to delegated execution authority.

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 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. If a workflow assumes the requester has the same rights as the AI step, it may return sales figures, meeting notes, or other internal data without challenge. The failure is not sophisticated exploitation. It is permission leakage across workflow steps exposed to public 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. Assign a named owner, define least-privilege access, log every tool call, and require revocation paths for credentials and tokens. If the workflow can touch production systems or sensitive data, its permissions must be reviewed with the same discipline used for privileged machine identities.

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.

Technical breakdown

Why static AI workflows create an authorization boundary gap

A static AI workflow is a predefined chain of steps, such as receive input, transform it with an LLM, then continue to a downstream action. The model is not choosing tools at runtime or negotiating scope, so this is not an autonomous agent problem. The failure emerges when the workflow creator’s service account or API key performs the action on behalf of an external requester without re-evaluating that requester’s authority. In practice, the pipeline treats a valid request as sufficient evidence of permission. That design turns a workflow into an authorization proxy, even when the original user has no matching entitlement.

Practical implication: separate input handling from privilege-bearing execution and verify requester authority before any downstream action.

How workflow identity hijacking differs from prompt injection

Prompt injection tries to steer the model’s behaviour by manipulating instructions, either directly or through malicious content. Workflow identity hijacking does not need to alter the model’s output at all. The model can interpret the request correctly, and the workflow can follow its normal path, yet the system still fails because the authorization decision is missing at the handoff to privileged execution. Standard guardrails that classify suspicious text do not detect this because the maliciousness is not in the wording. The threat lives in the trust relationship between the trigger and the executor.

Practical implication: treat model-output validation and authorization as separate controls, and do not rely on prompt filters to protect privileged actions.

Why shared service accounts make benign requests dangerous

When workflows execute through shared service accounts or broad developer API keys, every external trigger inherits the same downstream power. That is a classic NHI governance issue applied to AI systems: the identity used to act is more powerful than the identity that asked. If the workflow can search mail, query repositories, or extract records with creator-level access, then any user who can influence the trigger path can potentially reach privileged data. The design flaw is not the workflow itself, but the absence of user-context propagation into execution-time authorization.

Practical implication: scope workflow credentials to the requester’s context, not to the workflow owner’s standing privilege.

Threat narrative

Attacker objective: The attacker wants to induce a privileged workflow to disclose data or perform an action that the attacker could not legitimately authorize.

1. Entry occurs when an attacker sends a benign request through an unauthenticated channel such as email, a web form, or a shared document.
2. Credential or privilege abuse happens when the workflow executes with the creator's service account or API key instead of the external requester's authority.
3. Impact follows when the workflow retrieves or discloses sensitive internal data, creating silent exfiltration without prompt injection or account compromise.

Breaches seen in the wild

• ForcedLeak (Salesforce Agentforce) 2025: A critical Agentforce flaw let attackers steer an AI agent through a Web-to-Lead form to leak CRM data via an expired allowlisted domain.
• Gemini CLI prompt injection flaw 2025: Tracebit showed a poisoned README could make Gemini CLI run hidden commands and exfiltrate developer secrets; Google fixed it in 0.1.14.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Delegated execution authority must be tied to the requester, not the workflow owner. The article exposes a broken premise that many AI pipelines still inherit from traditional automation: the trigger and the executor are assumed to share authority. That assumption fails when a workflow ingests a request from a low-trust source and performs high-trust retrieval or disclosure using standing credentials. The implication is that authorization must travel with the request context.

Static AI workflows are NHI systems with hidden privilege concentration. Once an LLM is embedded in a deterministic pipeline, the workflow is not autonomous, but it still becomes an identity-bearing execution path. The real risk is a privileged service account acting on behalf of an untrusted input source, which makes workflow governance a subset of NHI lifecycle and access control discipline. Teams should stop classifying these flows as mere model integrations and start governing them as delegated identities.

Contextual authorization checkpoints are the missing control plane. The research shows that output from an LLM can be technically correct and still security-invalid if the requester lacks entitlement. That is a deeper problem than model guardrails because it requires explicit checks at the transition between interpretation and action. Practitioners should view the handoff between AI reasoning and privileged execution as the new enforcement boundary.

Identity-aware delegation will become the baseline for AI workflow governance. As AI systems increasingly sit inside enterprise business processes, the market will move away from static workflow privilege and toward contextual delegation tied to the authenticated user. That shift aligns AI workflows with longstanding IAM principles, but only if teams refuse to let creator privilege leak into every downstream action. The practical conclusion is to govern AI workflow execution like any other high-risk non-human identity.

What this signals

Creator privilege should not survive the handoff from interpretation to action. The key programme lesson is that AI workflow governance now needs an explicit control point between model output and privileged execution. If the workflow can read sensitive data, send messages, or query systems on behalf of a trigger source, the security team must decide whose authority is actually being exercised. That is a delegated identity problem, not a prompt-safety problem.

Workflow identity hijacking is a useful name for a recurring failure mode. It describes what happens when an enterprise automation treats any valid request as sufficient to borrow a more powerful identity downstream. For practitioners, the implication is to inventory AI workflows as non-human identities, then verify whether each one has a distinct authorization boundary, scoped credentials, and a defensible execution context.

For practitioners

• 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.
• Isolate read and reply paths Keep sensitive retrieval workflows separate from external response workflows so that data-gathering logic cannot automatically reuse the same execution path to disclose results.

Key takeaways

• Benign-looking inputs can still drive privileged AI workflows into unauthorized action when the authorization check sits at the wrong boundary.
• The article’s evidence shows that the real weakness is privilege inheritance across the workflow handoff, not prompt manipulation.
• Teams should treat AI workflow execution as delegated identity governance and place policy checks before any privileged downstream action.

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.
• Delegated Execution: Delegated execution is when software is allowed to perform actions on behalf of a user, process, or business function. In NHI governance, the risk is that the delegated actor may chain actions beyond the original intent, so controls must focus on scope, approval, 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.
• 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.

Deepen your knowledge

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