Workflow Identity Hijacking: AI Workflows Returning Internal Data Without Checking the Requester’s Authority

1. Basic Information

• Article Title: Identity-Based AI Attack Threatens Security of Enterprise Data
• Publisher: Dark Reading / Noma Labs
• Publication Date: 2026-09-09
• Original Source: Dark Reading / Noma Labs
• Related Sources: Noma Labs primary report
• Related Malware, Groups, CVEs, and Products: Enterprise AI workflows, Support inbox, GitHub Issues, Service accounts, API keys
• Priority: High

2. Executive Summary

An AI workflow handles an external request using its creator’s or service account’s permissions and returns internal data without checking whether the requester may access it. This is an authorization failure; neither prompt injection nor an autonomous agent is required.

3. Attack Flow

Authorization failure described by Noma Labs

1. An attacker supplies a request through an input the workflow processes, such as a support email, issue, or form.
2. The LLM interprets the request and passes it to predefined downstream processing. A fixed workflow can be vulnerable.
3. Internal searches or other downstream actions run with the creator’s or service account’s privileges.
4. The workflow returns the retrieved information to the external requester without enforcing the requester’s permissions.

4. Attacker Position and Execution Environment

• An external requester can influence the content of a support email, form, issue, or similar input. The processing runs in the organization’s AI workflow and connected services.

5. What Users and Administrators May See

Users

• A workflow may process an external request and reply with internal information without any internal user taking action.

Administrators

• Inference: Audit records may show only the service account. If the original requester is not linked to that execution identity, unauthorized use may be missed.

6. Success Conditions and Risk Reduction

Success Conditions

• An untrusted requester can influence input processed by the workflow.
• Downstream processing can access internal information without checking the original requester’s authorization.
• An external response path can return the information to the requester. Scheduled execution does not remove this input trust boundary.

Failure Conditions and Risk Reduction

• Authenticate the requester and authorize each object and operation. Where delegation is used, use short-lived, scoped tokens bound to that requester.
• Check authorization before LLM output drives internal retrieval or tool execution, and separate sensitive-data retrieval from external responses.

7. Potential Impact

• Unauthorized retrieval of internal email, database records, or documents.
• A confused-deputy condition in which a privileged workflow performs actions for a requester who lacks the required authority.

8. Observable Logs

Inference: These are investigation sources and their collection requirements.

• Email: Preserve request and reply message IDs, senders, recipients, and timestamps. Inspect reply content within access and retention policies.
• Proxy/SWG/DNS: Review APIs and destinations contacted by the workflow. Ordinary network logs alone cannot establish requester permissions or which documents were returned.
• Endpoint/EDR: Inspect processes and configuration if the workflow runs on a host you manage. Do not require endpoint EDR evidence for a workflow running entirely in SaaS.
• Identity/IdP: Link the original requester to the service identity, delegated token scope and lifetime, and authorization decisions.
• SaaS/Cloud: Audit run IDs, inputs, searches and tool calls, retrieved objects, and external replies. Record identifiers that connect these stages.
• Network: Review connections from the execution environment to internal services and external reply destinations. Transfer volume alone is not proof of disclosure.

9. Assessing Attack Success

The following are evidence criteria for an individual investigation, not claims that each stage occurred. See Facts and Unknowns for the reported scope.

• Attempt observed (success unconfirmed): Evidence criterion: Confirm a request from a party lacking the necessary permissions reached the workflow’s input.
• User interaction confirmed: Evidence criterion: Distinguish receipt of an external request from approval by an internal user. Lack of approval does not mean the workflow did not run.
• Initial execution confirmed: Evidence criterion: Confirm the run and downstream calls associated with that input. This is workflow execution, not malware execution.
• Malware execution or authentication success confirmed: Evidence criterion: Confirm that the service identity accessed an object the requester was not authorized to access. Service-account authentication alone does not establish an authorization flaw.
• Data theft or session compromise confirmed: Evidence criterion: Match retrieval records to reply contents to confirm that internal data reached an unauthorized requester.
• Follow-on compromise confirmed: Evidence criterion: Require separate evidence for subsequent access or modification using the disclosed information. Do not treat research examples as counts of real-world victims.

10. Investigation Playbook

Inference: Operational recommendations based on the described behavior.

• Trigger: An internal search initiated by external input followed by a reply containing sensitive information.
• Initial Checks: Review the workflow definition, input source, run ID, service permissions, and the original requester’s authorization.
• Endpoint: Inspect processes and configuration if the workflow runs on a host you manage. Do not require endpoint EDR evidence for a workflow running entirely in SaaS.
• Identity and Cloud: Link the original requester to the service identity, delegated token scope and lifetime, and authorization decisions. Audit run IDs, inputs, searches and tool calls, retrieved objects, and external replies. Record identifiers that connect these stages.
• Follow-on Activity: Require separate evidence for subsequent access or modification using the disclosed information. Do not treat research examples as counts of real-world victims.
• Containment: Disable or restrict the problematic retrieval and reply paths and add requester authorization checks. Review excessive permissions or static API keys where relevant.
• Classification: Distinguish contact, execution, abuse of privileges, data collection, and follow-on compromise using evidence. Missing logs do not prove that compromise did not occur.

11. Defense and Detection Ideas

Inference: Operational recommendations based on the described behavior.

• Single Event: An internal search initiated by external input followed by a reply containing sensitive information.
• Time-Series Correlation: Link the input message or issue, workflow run ID, internal access by the service identity, and external reply.
• Threat Hunting: Find externally writable inputs whose workflows use creator or shared service-account privileges to retrieve information and return it externally.
• Logging Gaps: Inspect processes and configuration if the workflow runs on a host you manage. Do not require endpoint EDR evidence for a workflow running entirely in SaaS. Review connections from the execution environment to internal services and external reply destinations. Transfer volume alone is not proof of disclosure.
• Priority Controls: Authenticate the requester and authorize each object and operation. Where delegation is used, use short-lived, scoped tokens bound to that requester. Check authorization before LLM output drives internal retrieval or tool execution, and separate sensitive-data retrieval from external responses.

12. Facts / Inference / Hypothesis

Facts

• Noma Labs describes Workflow Identity Hijacking as a separation between the identity influencing a workflow and the service identity used for downstream actions.
• Example inputs include support inboxes, GitHub issues, web forms, and shared documents. Permission to submit input is separate from permission to read internal information.
• In its example, a workflow processes an external sender’s request under creator privileges, searches a finance director’s email, and replies externally.
• The described failure is missing requester authorization and does not require prompt injection.
• Noma Labs notes that scheduled workflows also need assessment when an external party can influence the inputs they consume.

Inference

• The investigation, success-assessment, and defense recommendations are derived from public information. They are not observations of real-world compromise.

Hypothesis

No additional hypotheses. Unresolved points are listed under Unknowns and Further Investigation.

13. MITRE ATT&CK Mapping

No technique is assigned because the described authorization failure does not establish a sufficiently specific ATT&CK procedure.

14. Unknowns and Further Investigation

• Real-world victim counts and the exact affected scope for each product and configuration.
• Noma Labs says Google acknowledged its report and confirmed a fix, but implementation details are undisclosed.

15. Impact on SOCs and Organizations

AI reviews should establish whose input drives the action, whose privileges are used, which information is accessed, and who receives the result. Even when scheduled execution is restricted, externally writable emails or issues still require requester-level authorization. Enforce that decision at the downstream processing boundary rather than relying solely on an LLM’s judgment.

16. Audience Summaries

• SOC: Link the input message or issue, workflow run ID, internal access by the service identity, and external reply.
• Administrators: Disable or restrict the problematic retrieval and reply paths and add requester authorization checks. Review excessive permissions or static API keys where relevant.
• Users: Requests made through AI still require normal access permissions. Report unexpected internal information returned in a reply.