if ( !emtpy($headline_subheadline ) ) : ?>
Researchers warn that trusted AI agents can act as proxies for privileged accounts when user permissions are not enforced downstream.
endif; ?>
A newly identified AI attack technique can let unauthenticated users trigger privileged workflows and access enterprise systems, highlighting a gap in how identity and access controls apply to AI agents, according to research from Noma Labs.
The report, authored by Noma Labs lead researcher Sasi Levi, describes the issue as “workflow identity hijacking,” where attackers bypass standard controls by sending normal, benign requests through an unauthenticated entry point such as a support inbox, GitHub issue, web form, or shared document.
“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.”
Authorization breaks at the workflow layer
At the center of the issue is what Levi describes as “an authorization design flaw in modern enterprise AI pipelines,” where the identity of the requester and the identity used to execute actions diverge.
“The identity and permissions of the user who triggers a workflow are decoupled from the identity and permissions used to execute it,” he wrote. In practice, that means workflows carry out actions “using high-privilege service accounts or developer API keys” instead of enforcing the initiating user’s access rights.
As a result, AI workflows can act as “unauthenticated proxies for privileged actions and silent data exfiltration,” the report added.
Vibhum Dubey, a cybersecurity researcher and red teamer, said the issue reflects a known class of authorization weakness.
“If an unauthenticated input can trigger a trusted workflow, and that workflow performs actions using its own privileges, the workflow can effectively act as a confused deputy.”
He added that in many deployments, “the original requester’s permissions are not necessarily re-evaluated when the workflow performs sensitive actions downstream.”
Same request, different authority
The report illustrates the risk with a scenario involving identical requests from different actors.
“Consider two identical inputs,” Levi wrote, including a query for financial data from a senior executive’s email. “The prompt and requested operation are identical, but the authorization decision should be completely different.”
“A CFO is entitled to that information; an external sender is not.”
Because the input itself is benign, “standard prompt-injection detectors and agent guardrails classify these inputs identically,” he noted. “The security risk isn’t in the prompt; it is in the authorization boundary.”
The model behaves correctly, but the system does not
Unlike prompt injection attacks, this technique does not rely on manipulating the model’s behavior, according to the report.
“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.”
The failure occurs when the workflow executes the resulting action “using the workflow creator’s identity or privileges without verifying whether the original requester was authorized.”
That distinction shifts the problem from model security to how identity and permissions are enforced across interconnected systems.
Activity appears legitimate
Because actions are executed through trusted workflows using valid credentials, the activity may not trigger conventional security alerts.
“The security risk isn’t in the prompt,” the report noted, but in how the workflows use “privileges the attacker does not possess.”
Dubey said this creates a detection challenge for defenders.
“The individual events can look completely legitimate. The useful signals would come from correlating the original requester, the identity used downstream, the resources accessed, the parameters supplied, and the final action.”
Without that correlation, unauthorized access can blend into routine automation, Dubey added.
Risk grows as attackers adopt agentic workflows
The timing of the finding adds to its significance. As enterprises expand AI-driven automation, attackers are also beginning to use similar multi-step workflows to carry out operations.
In a recent blog post, Google Threat Intelligence Group has described a shift from prompt-based misuse to more autonomous, agent-driven attacks that can plan and execute tasks across environments.
That evolution increases reliance on the same execution layer highlighted in the Noma report, AI workflows that connect systems and act on behalf of users, amplifying the impact of any gaps in how identity and authorization are enforced.
Shifting controls beyond the model
Noma Labs said mitigating the risk requires moving security controls beyond the model layer and into application and infrastructure design.
“Mitigating these AI workflow risks requires shifting security controls from the model layer to application and infrastructure layers,” Levi wrote.
The report recommends enforcing identity-aware access at the point where actions are executed, including “user-context propagation” and “explicit access-control and runtime protection evaluation steps” between AI-generated outputs and downstream operations.
Dubey said one way to test for the issue is to compare outcomes across users with different privilege levels.
“If a low-privileged user can obtain the same result as an administrator because downstream systems only see the workflow’s identity, that is where I would focus the investigation.”










