A complete stranger emails your company's support inbox asking a perfectly normal-sounding question. Your AI workflow answers it correctly — using data only your Finance Director should ever see. No hacking, no jailbreak, no malicious language anywhere. Here's how that happens, and why it's not a bug in the AI model at all.
On September 9, 2026, security researchers at Noma Labs published a report naming a vulnerability class they call Workflow Identity Hijacking — and it's since been picked up by outlets from Dark Reading to Security Magazine as one of the more significant enterprise AI findings of the year. The plain-language nickname it's earned is the "Stranger Danger" backdoor, and that's a genuinely useful way to think about it: it's what happens when your AI workflow lets a total stranger borrow someone else's ID to walk straight into a room they were never invited into.
No jailbreak. No malicious phrasing. No stolen password. Just an ordinary-sounding request from someone with no business asking it in the first place — and a workflow that never checked whether they were allowed to.
Here's a beginner-friendly way to picture it: imagine a company receptionist who's been told "whenever someone asks a reasonable-sounding question, look up the answer using the master key and hand it over." The receptionist isn't doing anything wrong by their own instructions — they're doing exactly what they were told, every time, correctly. The actual mistake was handing out a master key that opens every door, to someone whose only job was answering the phone, and never asking who was calling before using it.
If you've read anything about AI security before, your instinct might be to file this under prompt injection — the well-known trick where an attacker crafts input specifically designed to override a model's instructions. That instinct is wrong here, and understanding why is the whole key to this vulnerability.
In Workflow Identity Hijacking, the AI model behaves exactly as intended. Nobody tricked it into anything. It received an instruction, understood it correctly, and carried it out precisely as designed. The failure isn't in what the model decided to do — it's in what happened after the model decided, at the point where the workflow reaches out to fetch data or take an action. Because there's no suspicious language for a prompt-injection filter or jailbreak detector to catch, those defenses simply have nothing to flag. The request looks completely clean, because it is.
Modern enterprise AI workflows typically follow a predictable shape: receive an external input (an email, a web form submission, a GitHub issue, a shared document), pass it to an LLM to interpret what's being asked, then execute one or more downstream actions — searching a mailbox, querying a database, calling an internal API — to fulfill the request.
Those downstream actions almost always run under a single, fixed, elevated identity: a service account, a static API key, or an OAuth token that belongs to whoever originally built or administers the workflow. That's the fast, easy way to get a workflow working. The problem is what's missing: nothing carries the original requester's identity through to that execution step. The workflow can't tell the difference between its own administrator asking a question and a total stranger asking the identical question through the same public-facing inbox — because authorization was never actually the model's job, and nobody built it into the workflow around the model either.
The example researchers use to illustrate this is deliberately mundane, which is exactly what makes it alarming. An attacker sends an email to a company's public support address asking: "What are the quarterly sales numbers from the Finance Director's most recent email?"
If an AI workflow monitors that inbox, interprets the request, searches internal mail using its own configured (and privileged) access, and replies automatically — the attacker gets the real answer. Nothing about the sentence is malicious. A legitimate employee, and an anonymous outsider, could type the exact same words, and the workflow has no mechanism to tell them apart. As Noma's own framing puts it: authorization was never the model's job to begin with, so nobody built it anywhere else either.
Security teams reasonably tend to focus their scrutiny on autonomous, agentic AI — systems that dynamically decide which tools to use and which actions to take, since that flexibility looks obviously riskier. Researchers specifically call out that this assumption creates a blind spot: static, predefined workflows can be just as exposed, and in practice often get less scrutiny precisely because they don't look autonomous. A rigid, step-by-step automation feels safe because a human designed every step of it — but if step three trusts whatever step one received without checking who sent it, the rigidity doesn't help at all.
Detection is genuinely difficult for a second reason too: every individual step in the chain looks completely legitimate in isolation. The email arrives through a normal channel. The workflow uses its own valid, provisioned credentials. The data query is one the workflow was built to run. A security operations team watching for anomalies — unusual logins, unfamiliar IP addresses, malformed requests — sees none of that, because nothing about the mechanics is actually anomalous. The only thing that's wrong is a relationship that never gets checked: whether the person who triggered this particular run of a normal process was ever entitled to see what came back.
Here's the part that should be reassuring to beginners rather than intimidating: this exact shape of vulnerability has a name in security research, and it's nearly 40 years old. It's called the confused deputy problem — first formally described in 1988, long before anyone was building AI workflows. The core idea: a "deputy" (some program acting on your behalf, with more authority than you personally have) can be tricked into misusing that authority on behalf of someone who was never supposed to have it, simply by asking the deputy to do something within its normal job description.
Privileged access management solved this problem for human identities years ago — the standard answer is enforcing that every action carries and checks the actual requester's identity, not just the identity of whatever system is performing the action. Workflow Identity Hijacking is that same, decades-old design flaw, recreated fresh because the deputy doing the acting is now an AI-driven automation instead of a person or a traditional script.
That's genuinely useful context for anyone new to this space: you're not looking at a brand-new category of risk that nobody has ever solved before. You're looking at a well-understood, well-studied problem showing up again in a new kind of system, which means the fix isn't a mystery either — it's the same identity-propagation discipline that already exists for every other kind of automated, privileged system, applied consistently to the AI layer instead of assumed to be someone else's job.
This isn't only a theoretical finding. Noma Labs reports it identified and responsibly disclosed a version of this same Workflow Identity Hijacking risk in Google Workflows. Google acknowledged the report and confirmed it implemented a fix, though the technical details of that fix haven't been made public. That's a meaningful signal: a major cloud platform, not just a small or obscure vendor, had this exact class of authorization gap in a real, widely-used product.
The researchers' own recommendations, echoed across multiple outlets covering the report, converge on a consistent set of fixes:
Run a free assessment for authorization-boundary and privilege-escalation risks — the same failure category behind Workflow Identity Hijacking.
Run Free Assessment →Workflow Identity Hijacking is an authorization-boundary problem — access granted based on the wrong identity, with no check that the actual requester was entitled to it. That's exactly the category of failure two existing HexTyx modules are built to find, plus a runtime layer that enforces the boundary once a workflow is live.
HexTyx's unauthenticated_admin_exposure module tests specifically for endpoints and actions that return privileged data with no authentication check at all — the same fundamental gap as an unauthenticated stranger's email question reaching data only an authenticated Finance Director should see.
HexTyx's tenant_authz_bypass module combines structural checks (does the system verify the caller's actual rights before acting, or just that a request arrived in the expected shape) with response-level checks confirming whether real, sensitive data leaked to a caller who was never authorized to receive it — precisely the "identical sentence, different requester" scenario Noma's researchers describe.
Testing finds the authorization gap before launch; Aegis's checkpoint_tools gate evaluates every tool call against policy before it executes in production — the layer that needs to exist precisely because, as this incident shows, the model's own judgment was never going to be the place authorization got enforced.
The honest scope limit: no scanner replaces the actual fix, which is architectural — propagating real requester identity through every downstream action, as Section 8 describes. What structured testing does is tell you, concretely and before an outside researcher does, whether that propagation is actually happening in your own workflows or only assumed to be.