AI Workflows Bypass Identity Checks

An AI workflow can read a support ticket, a GitHub issue, or a shared document and then go do something on the company's behalf. That is the point of building it. Noma Labs says the same design can also let a stranger ask for the action, because the workflow never checks whether the person on the other end had any right to ask.

The research firm calls the technique "workflow identity hijacking," and frames it as a gap in how identity and access controls apply to AI agents rather than a flaw in the models themselves. The report was authored by Noma Labs lead researcher Sasi Levi.

A benign request, an unauthenticated door

The attack does not start with a malicious prompt. According to the report, an attacker sends an ordinary, benign request into an unauthenticated entry point — a support inbox, a GitHub issue, a web form, or a shared document. The workflow picks it up and processes it exactly as it was built to do.

What is missing is any check on whether the sender had the authority to make the request in the first place. Levi describes the problem as "workflow identity hijacking," in which attackers bypass standard controls by sending normal requests through those open intake channels.

"The enterprise AI pipeline reads the input, interprets the request, and executes the action exactly as designed," Levi wrote in the report. "The core failure is that the requester had no authority to make that request."

— Sasi Levi, lead researcher at Noma Labs

Two identities moving through one workflow

At the center of the issue is what Levi describes as "an authorization design flaw in modern enterprise AI pipelines." The identity of the person who triggers a workflow is not the identity that carries out the work.

In many deployments, the report says, workflows execute actions using high-privilege service accounts or developer API keys rather than enforcing the initiating user's access rights. The requester's permissions are never consulted at the moment the sensitive action runs.

"The identity and permissions of the user who triggers a workflow are decoupled from the identity and permissions used to execute it," he wrote.

— Sasi Levi, lead researcher at Noma Labs

The report says the result is that AI workflows can act as "unauthenticated proxies for privileged actions and silent data exfiltration."

Same request, different authority

Noma Labs illustrates the problem with a scenario built on two identical inputs. Both could be, for example, a query for financial data sent from a senior executive's email. The text of the prompt and the operation requested are the same in each case. The authorization decision, Levi argues, should not be.

"Consider two identical inputs," Levi wrote. "The prompt and requested operation are identical, but the authorization decision should be completely different."

— Sasi Levi, lead researcher at Noma Labs

"A CFO is entitled to that information; an external sender is not."

— Sasi Levi, lead researcher at Noma Labs

Because the input itself is harmless, detectors that look for prompt injection and the guardrails around AI agents treat both requests the same way. As Levi puts it, "standard prompt-injection detectors and agent guardrails classify these inputs identically." The risk, he writes, is not in the prompt — "it is in the authorization boundary."

The model behaves; the system does not

This is not prompt injection, according to the report. Nothing about the model's behavior has to be manipulated. The model reads the input and responds correctly. The workflow then follows its predefined execution path correctly. Both halves do their jobs.

"The attacker does not need to manipulate the model at all," Levi wrote. "The model follows its instructions correctly, and the workflow follows its predefined execution path correctly."

— Sasi Levi, lead researcher at Noma Labs

The failure surfaces when the workflow performs the resulting action using the workflow creator's identity or privileges, without verifying that the original requester was allowed to ask for it. That moves the problem away from model security and toward how identity and permissions are enforced across systems that talk to each other.

Activity that looks legitimate

Because the actions are executed by trusted workflows holding valid credentials, they may not raise the kind of alarms that conventional security monitoring is built to catch. Nothing in the individual events looks forged. The credentials are real. The workflow is real.

The report states that the security risk "isn't in the prompt," but in how workflows use "privileges the attacker does not possess." An outside sender never needed valid credentials of their own, because the workflow supplied them.

The shift toward agentic attacks

As enterprises expand AI-driven automation, attackers are also beginning to use multi-step workflows of their own. In a post published on Google's cloud blog, Google Threat Intelligence Group described a shift from prompt-based misuse toward more autonomous, agent-driven attacks that can plan and execute tasks across environments.

That evolution increases reliance on the same execution layer the Noma report focuses on — AI workflows that connect systems and act on behalf of users. Any gap in how identity and authorization are enforced at that layer applies to both the defensive workflow and the attacker's version of it.

Controls that live below the model

Noma Labs says fixing the problem means moving security controls out of the model layer and into the way applications and infrastructure are designed. The recommendation is to enforce identity-aware access at the point where actions are actually executed.

"Mitigating these AI workflow risks requires shifting security controls from the model layer to application and infrastructure layers," Levi wrote.

— Sasi Levi, lead researcher at Noma Labs

The report points to user-context propagation and explicit access-control and runtime protection evaluation steps placed between an AI-generated output and the downstream operation it triggers. In effect, the workflow should carry the requester's identity forward and check it before acting, rather than substituting its own.

What the finding covers

• The report is authored by Noma Labs lead researcher Sasi Levi.
• Noma Labs describes the issue as "workflow identity hijacking."
• The technique applies to unauthenticated entry points such as support inboxes, GitHub issues, web forms, and shared documents.
• Workflows execute through high-privilege service accounts or developer API keys, per the report.

Where this leaves defenders

For organizations that have connected AI agents to support desks, ticketing systems, code repositories, and internal data stores, the report describes a class of exposure that model-focused tooling does not address. The prompt is clean, the model is behaving, and the workflow is doing what it was told. The missing piece is a check on whether anyone was entitled to give that instruction.

The report's own remedy points at application and infrastructure layers rather than the model, which suggests that teams reviewing their AI deployments may need to inventory which workflows can be reached by outside input and what those workflows are permitted to do. As Levi's example shows, the same request can be entirely appropriate from one sender and entirely out of bounds from another — and the system has to be the one that tells the difference.