New Attack Steals Data via AI Workflows, No Jailbreak Needed

Key Takeaways

• A new vulnerability, “Workflow Identity Hijacking,” allows attackers to exfiltrate sensitive data from enterprise AI workflows.
• The attack bypasses traditional AI safeguards, requiring no prompt injection, account compromise, or LLM jailbreaking.
• The flaw exploits authorization gaps, enabling external, unauthorized requests to trigger AI automations with privileged access to internal systems.
• Affected systems include AI workflows connected to public-facing communication channels like email, web forms, and customer support platforms.
• Mitigation involves robust identity propagation, granular access controls, and treating all LLM outputs as untrusted.

A novel attack vector is compromising enterprise AI workflows, enabling unauthorized data exfiltration without the need for prompt injection, account takeovers, or large language model (LLM) jailbreaking. Dubbed “Workflow Identity Hijacking,” this vulnerability leverages critical authorization discrepancies between external requestors and the elevated privileges granted to AI automation processes.

This method exposes sensitive information by exploiting gaps in how AI workflows manage identity and permissions. Systems connected to public interfaces, such as corporate email inboxes, web submission forms, GitHub issues, shared documents, and customer service platforms, are particularly susceptible.

An attacker may only need to submit a seemingly innocuous request to a vulnerable AI workflow. This request can then trigger the workflow to retrieve and disclose internal information, utilizing permissions that the attacker themselves does not possess.

Consider a scenario where an attacker sends an email to a company’s public support address, requesting specific financial data, such as the latest quarterly sales figures, ostensibly mentioned in an executive’s internal email.

Hackers Turn AI Workflows Into Data-Stealing Proxies

If an AI workflow is configured to automatically process incoming messages, search internal data repositories (like mailboxes), and generate automated responses, it could unwittingly fulfill such a request. The core danger here is not in a maliciously crafted prompt, but in the workflow’s inherent ability to access internal data using a highly privileged service account or the credentials of its creator. As Noma Labs highlights, this creates a clandestine channel for data exfiltration.

The AI model itself does not need to be tricked into ignoring its instructions, bypassing security controls, or performing unintended actions. Instead, it merely executes its predefined tasks, while the underlying automation carries out downstream actions with excessive privileges, inadvertently exposing data.

Distinguishing Workflow Identity Hijacking from Prompt Injection

This issue fundamentally differs from traditional prompt injection attacks. Prompt injection aims to manipulate an LLM’s behavior directly or indirectly through crafted input. In contrast, Workflow Identity Hijacking focuses on the legitimacy of the request itself. For example, a Chief Financial Officer legitimately requesting sales data is authorized, but an anonymous external sender asking for the exact same information is not.

Existing AI safeguards often fail to differentiate between these scenarios. From an LLM’s perspective, both requests might appear harmless. Input filters and model guardrails are designed to detect attempts to alter the model’s behavior, but they typically do not verify whether the requester possesses the necessary permissions to access the requested data.

The fundamental security flaw arises from the disconnect between the identity of the requester and the identity under which the workflow executes. This allows unauthenticated external users to influence workflows that subsequently access sensitive data using privileged developer API keys, service accounts, or administrative integrations.

The False Sense of Security in Predictable Workflows

Unlike “agentic” workflows, which can adaptively select tools and actions to achieve goals, most AI workflows are predictable. They follow a fixed process: input is received, an LLM analyzes it, and predetermined actions are executed. This deterministic design can foster a false sense of security, leading development teams to prioritize restricting tool usage while overlooking the security implications of static automations directly linked to internal systems.

Even scheduled workflows remain vulnerable. While administrators might be the only ones able to configure or launch them, these workflows often process inputs from untrusted sources, such as public email inboxes or customer support ticket queues, making them susceptible to exploitation.

What You Should Do

• Evaluate Workflow Inputs: Identify the least-trusted party influencing each AI workflow’s inputs. Pinpoint every untrusted content source and meticulously define permissions at every stage of the workflow.
• Propagate Requester Identity: Ensure that the authenticated identity of the original requester is consistently propagated and verified throughout the entire workflow execution.
• Implement Short-Lived, Scoped Tokens: Replace persistent administrative API keys with short-lived, narrowly scoped tokens or credentials for all workflow actions requiring elevated privileges.
• Enforce Authorization Checks: Mandate robust authorization checks before any sensitive actions are performed by the workflow, verifying that the requester is explicitly authorized for that specific action and data access.
• Treat LLM Outputs as Untrusted: Consider all large language model outputs as untrusted data. Any subsequent workflow step that uses model output to trigger actions should incorporate separate, stringent policies and access control checks.
• Separate Sensitive Data Retrieval: Design workflows to explicitly separate sensitive data retrieval from automated external responses. Workflows capable of accessing financial records or private emails should be prevented from sending results to unauthenticated external users.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.