In accordance with the AI’s workflow, the request is processed and executed — exactly as it was designed to do. The concern is that the malicious actor had no authority to make that request, yet saw it fulfilled. 

Security Leaders Weigh In

Chandra Gnanasambandam, Chief Technology Officer at SailPoint:

Adversaries are using AI to operate at a scale and speed that makes traditional, static defenses outdated. The window between a vulnerability’s discovery and its exploitation has shrunk from months to mere days, and soon, we anticipate that it will be minutes. Moving forward, security teams must look inwards. Instead of focusing exclusively on keeping threats out, we must meticulously govern what happens inside our own systems. This means abandoning the dangerous, yet common, “set-it-and-forget-it” approach to access policies. Teams must accept that static, persistent access is the single greatest vulnerability in the modern enterprise. The new mandate is to pivot from a mindset of static protection to one of real-time governance, either through Least privilege or Zero standing privilege. 

We must also recognize that governing non-human identities (NHIs) is different from governing humans and requires a new, specialized framework built for machine-speed operations. You cannot secure what you cannot see, and right now, most enterprises are flying blind regarding the sheer volume of their non-human workforce. It is no longer enough to just track a few service accounts. Teams need to deploy discovery mechanisms capable of identifying agents across the entire digital ecosystem. They must be able to find and classify cloud agents managing infrastructure, app-level agents driving enterprise workflows, browser-based agents and extensions, and endpoint bots operating on local machines.

Furthermore, discovering that an agent simply exists is only half the battle. To truly identify an NHI’s footprint, teams must map its complete web of connectivity and identify everything it accesses — the internal tools they are authorized to execute, the SaaS apps they integrate with, and the specific data repositories they query or modify. This discovery process must also uncover and catalog the underlying credentials associated with every single one of these interactions. Whether they are API keys, OAuth tokens, or legacy embedded secrets, teams should know exactly how these agents are authenticating. 

To effectively identify NHIs, teams need a system capable of continuously discovering this entire matrix: the specific type of agent, the credentials it holds, the tools and data it accesses, and the specific risk that each of those privileges poses. This holistic, continuous visibility is the only way to regain control and begin securing your non-human workforce.

Morey Haber, Chief Security Advisor at BeyondTrust:

Noma Labs put a name to something that many organizations have been experiencing with AI automation, “Workflow Identity Hijacking” and it is not simply prompt injection. Nobody tricked an AI model into anything it was not supposed to do. The model did exactly what it was told, by a stranger (untrusted), and the workflow around it used someone else's identity to make that happen since it was not scoped and treat with least privilege.

Every AI workflow built on a shared service account or static API key has recreated a problem privileged access management solved for human identities years ago. When you have too many requesters operating under one identity, there is no way to tell who asked for what. If a CFO and an anonymous threat actor can input an “identical sentence”, the model cannot tell them apart because authorization was never the model’s job. Roles and least privilege where never assigned for AI automation. It is an infrastructure decision someone skipped when they wired the workflow to a privileged credential “to get things working.”

In my opinion, this is the asset, privilege, identity triad breaking down in a new place. If you consider multiple assets are a part of the workflow, the privilege is owned by the AI identity doing the executing, the threat actor simply triggered the task for execution, and nothing was verified in the entire process for entitlements, privileges, or behavior.

This leads to three potential fixes worth prioritizing:

1. Stop letting workflows run as an unaccountable “system.” Use short lived, scoped delegation tokens tied to the actual requester and responder instead of a standing admin key.
2. Treat model output as untrusted input and insert an explicit authorization checkpoint before any privileged action executes. This is the human in the loop. A CFO should be replying with an automated response that contains data. This makes least privilege and roles important context for AI.
3. Third, separate read from send. A workflow that can pull sensitive data and respond externally through an unauthenticated channel is an exfiltration pipeline with a helpful front end. That should never happen.

Ram Varadarajan, CEO at Acalvio:

Workflow Identity Hijacking produces zero adversarial signal at the model layer. The request is benign, the reasoning is sound, the tool call is exactly what the workflow was built to do. Any defense sitting at the classifier or guardrail layer is structurally blind to it by design, not by tuning failure.

Closing this gap means treating every AI workflow’s access grant as its own attack surface. Scope the NHI’s permissions to the requester population it’s actually meant to serve, not to the maximum data the automation might someday need, because a filter downstream of an over-provisioned identity is defending the wrong layer entirely.

The fix is model-aware deception, not better filtering. Seed the environment with decoy assets — fake executive threads, honeytoken records — that carry no legitimate reason for any authorized workflow to touch. A benign-looking request that reaches for them is caught by its behavior against a boundary it shouldn’t be crossing. This catches exactly the attacker who left no injected text, no jailbreak, and no anomalous phrasing for a classifier to flag.

Jeremy London, Director of Engineering, AI & Threat Analytics at Keeper Security: 

Workflow identity hijacking works because authentication and authorization operate on different questions. An AI agent can authenticate itself properly by using valid credentials, following its instructions exactly and generating accurate outputs, but still disclose sensitive data to someone who should never see it. The workflow’s identity is verified, but the requester’s access rights are never checked.

Security teams need to treat every AI workflow as a privileged identity with explicit authorization boundaries. That means inventorying which non-human identities each workflow can access, enforcing least-privilege permissions, isolating data retrieval from external communication and requiring identity-aware authorization checks before any agent fulfills requests from untrusted channels. Audit logging matters too, but logging prompts and model outputs alone misses the full picture. You need to record who initiated the request, which identity executed it, what data was accessed and why the authorization succeeded.

When you implement proper workflow identity governance, you eliminate the gap between what an agent is permitted to do and who is actually requesting it. That gap is where breaches live, and by closing it, you close a major attack surface.

Chris Radkowski, Security and Risk Expert at Pathlock:

This research confirms something identity and access teams have known for years in the ERP world and are now relearning in AI: the danger was never just the request, it’s who’s allowed to make it. Most AI security spend has gone toward stopping the model from being tricked. Workflow Identity Hijacking shows the model doesn’t need to be tricked at all if the workflow itself can’t tell the difference between a CFO and an anonymous inbox message. That’s not a model problem, it’s an authorization problem, and it’s the exact gap that segregation-of-duties and access governance programs were built to close in traditional systems.

Security teams must treat every AI workflow’s service account or API key the same way you’d treat a highly privileged ERP role: map exactly what it can touch and never let it inherit blanket access just because it’s convenient to build. Concretely, that means enforcing least privilege and short-lived, limited time access, and adding a real authorization checkpoint between what the model outputs and what the workflow is allowed to act on. If you wouldn’t let an unauthenticated external sender query your finance data directly, you shouldn’t let an AI pipeline do it on their behalf just because the request sounded reasonable.

Bradley Smith, SVP, Deputy CISO at BeyondTrust:

Noma Security’s research names a failure mode most enterprises already have running in production. We are seeing AI workflows wired to privileged credentials because that was the fastest way to get them live, and the requester’s identity gets dropped somewhere between the inbox and the execution. The attacker in this scenario never breaks anything. He asks, and the workflow lends him its authority. I think that’s the finding leaders need to focus on: this exposure came from a design decision, and it predates the name Noma just gave it. This is the confused deputy problem that has been identified since 1988; it’s just that now the deputy is no longer human.

The issue for the defense is that nothing in this attack chain looks wrong. There’s no adversarial phrasing for a filter to catch and no failed login for the SOC to chase. Every log line shows an authorized workflow completing an approved task, which means detection must move from authentication telemetry to authorization telemetry. The question all our monitoring must answer shifts from who logged in to who was entitled to ask. Most security operations programs cannot answer that question for their AI workflows today, and that must change now.

Security teams can make two moves this week without waiting on engineering. 

• First, run the audit this research implies: inventory every AI automation, find the least-trusted party who can put content in front of it, an inbox anyone can email or a form anyone can submit, and assess the workflow as if that party is hostile. 
• Second, treat any workflow holding standing authority the way you treat an insider. Give it an owner and give it an authority map that says what it can do and who is entitled to invoke it. The engineering fixes Noma recommends are correct, but they take quarters to land. The audit takes a week, and you have to know where your exposure is before you can fix it.