A newly disclosed AI security threat dubbed Workflow Identity Hijacking could let attackers extract sensitive enterprise data by submitting ordinary requests through public-facing channels such as support inboxes, web forms, GitHub issues, or shared documents.
Unlike prompt injection attacks, the technique does not require adversaries to manipulate, jailbreak, or override a large language model’s instructions.
Instead, it exploits a broken authorization boundary between an untrusted person who influences an AI workflow and the privileged identity the workflow uses to execute downstream actions.
AI Workflow Identity Hijacking
Security researchers at Noma Labs described a scenario in which an attacker sends a benign email to a company’s public support address asking for quarterly sales figures from the Finance Director’s latest email.
The AI workflow receives the request, searches the internal mailbox using its configured permissions, and sends the answer back externally. The workflow behaves exactly as designed. The failure is that the external requester was never authorized to access the information.
AI workflows commonly combine a fixed automation sequence with one or more LLM processing stages. A typical flow may receive an email, pass the content to an LLM for intent extraction, query a connected application, and send a response.
Those downstream tasks frequently run through persistent API keys, service accounts, or OAuth tokens belonging to the workflow creator or administrator.
If the workflow does not propagate and enforce the original requester’s identity, an external actor can effectively cause the automation to exercise permissions they do not possess.
This creates an unauthenticated proxy for privileged data access. This distinction matters because the same request may be legitimate or malicious depending on who made it.
A CFO asking for internal sales information may have a valid business need and appropriate permissions. An unknown sender submitting the identical request through a public inbox does not.
Traditional AI security controls may miss this scenario because they lack suspicious language to detect.
Prompt-injection filters, model guardrails, and jailbreak defenses generally evaluate whether content attempts to alter model behavior. In Workflow Identity Hijacking, the model follows its system instructions and the predefined workflow path correctly.
Noma Labs differentiates the issue from agentic AI attacks. Agentic workflows dynamically determine which tools to invoke and which actions to take, while traditional AI workflows use a predefined sequence in which an LLM performs a processing step.
Security teams may focus heavily on autonomous agents because of their broad tool access and dynamic decision-making. However, static automations can create an equally significant exposure when untrusted content influences a workflow that operates with elevated credentials.
The least-trusted party able to influence a workflow matters more than the nominal workflow owner. That party could be an external email sender, a user filing a public issue, a customer submitting a support form, or an individual editing a shared document.
Mitigations
Organizations should treat LLM-produced output as untrusted input before allowing it to trigger database queries, API calls, or external communications. Key protections include:
- Propagating the authenticated requester’s identity through downstream actions using short-lived, scoped delegation tokens.
- Enforcing authorization checks between LLM output and every sensitive tool or data-access operation.
- Removing static, high-privilege API keys from workflows exposed to external input.
Workflow Identity Hijacking shifts AI security from model manipulation to a more familiar enterprise problem: ensuring that automation never grants attackers the authority of the people who built it.
Detect 58% more threats with fresh intelligence from 16K+ organizations. Integrate TI Feeds in you SOC
