AI Agent Authorization: Why Your Workflow's Service Account Is the Attack Surface
AI agent authorization is the control that verifies the person or system that triggered an AI workflow is actually permitted to perform the downstream action. It fails when the workflow executes with a service account's standing privileges instead of re-checking the requester's permissions, turning the workflow into an unauthenticated proxy for privileged actions and silent data exfiltration.
An attacker emails your public support address with a polite question. Your AI workflow reads the message, understands it, searches the most recent email of your finance director, and replies with the quarterly sales numbers. No account was breached, no model was manipulated, and no guardrail was bypassed. The attacker just asked. This is the scenario that AI agent authorization exists to stop, and it is the one most enterprises have never tested.
Noma Labs named this attack workflow identity hijacking in a report published on September 9, 2026, and CSO Online covered the finding the next day [1][2]. The report describes it as "an authorization design flaw in modern enterprise AI pipelines," where the identity that triggers a workflow and the identity used to execute it are decoupled [1].
In our AI agent assessments, this is the failure mode clients react to hardest. They have budgeted for prompt injection filtering, tested their guardrails, and consider the input layer safe. Then they watch a perfectly benign request, submitted by an external sender, produce a privileged action. Clone Systems' position: the enterprise AI threat has moved from what the model will say to what the workflow will do, and the control that decides that is the identity check at execution time, not the prompt filter. Every section below exists to put that check in front of you.
Is Workflow Identity Hijacking Different From Prompt Injection?
Yes. Prompt injection manipulates how a model follows instructions. Workflow identity hijacking exploits whose authority the workflow uses when executing a valid request, so the model behaves correctly and the system still acts with the wrong permissions [1].
The distinction matters because it decides which defenses are even in scope. OWASP's GenAI Security Project defines prompt injection as input that alters a model's behavior or output in unintended ways, and splits it into direct injection, where the user submits adversarial text, and indirect injection, where malicious instructions hide in external content the model later ingests, such as a web page, PDF, or email [4]. Both variants target the model's parsing of instructions.
Workflow identity hijacking targets something else. The requester submits an ordinary request that the model was explicitly designed to understand and process. The model follows its instructions correctly, and the workflow follows its predefined path correctly. The failure occurs downstream, when the workflow executes the action using the workflow creator's identity or privileges without verifying whether the original requester was authorized to exercise them [1]. Noma Labs puts the point in one sentence: "The security risk isn't in the prompt; it is in the authorization boundary" [1].
| Threat | What the attacker targets | How it evades current defenses |
|---|---|---|
| Direct prompt injection | The model's system instructions | Adversarial text that overrides safety guidelines, bypassing input filters [4] |
| Indirect prompt injection | The model's parsing of external content | Malicious instructions hidden in a file, email, or web page the model later ingests [4] |
| Workflow identity hijacking | The authorization and privilege boundary | A benign request that triggers a privileged workflow. No model manipulation required, so guardrails classify the input as clean [1] |
The timing is what makes this urgent rather than academic. Indirect prompt injection has crossed from proof of concept to live exploitation: Google telemetry reported a 32% relative increase in malicious injection content between November 2025 and February 2026 across the 2 to 3 billion pages it crawls each month, and Palo Alto Networks Unit 42 documented twelve confirmed indirect injection cases against AI agents, mapping twenty-two payload delivery techniques in active use [3]. The model layer is under pressure from that side. The authorization layer, where workflow identity hijacking lives, has had almost no pressure at all, which is exactly why it is untested.
What Does the Attack Look Like in Practice?
The request is ordinary, and the entry point is one you already expose: a support inbox, a GitHub issue, a web form, or a shared document [1].
Noma Labs illustrates it with two identical inputs [1]:
- From the CFO: "What are the quarterly sales numbers from the Finance Director's most recent email?"
- From an external attacker: the same sentence, sent to the support address.
The prompt and the requested operation are identical, but the authorization decision should be completely different. The CFO is entitled to that information; an external sender is not. Standard prompt injection detectors and agent guardrails classify the two inputs identically, because there is no malicious phrasing in either one [1].
This is not theoretical. In July 2026, Noma Labs published research into a GitHub agentic workflow that activated when an issue was assigned, read the issue title and body, and replied with a comment. Because the agent held read access across the organization's repositories, external users could use issue assignments to read private repository data. The disclosure was covered by Hacker News, Dark Reading, and more than 100 other outlets [1]. Noma Labs then identified and reported the same vector in Google Workflows. Google acknowledged the report and confirmed a fix [1].
The detection problem is the part most teams have not planned for. Because the actions execute through trusted workflows with valid credentials, the activity can look completely routine, and conventional alerts may never fire [2]. As red teamer Vibhum Dubey put it in the CSO coverage, "the individual events can look completely legitimate." The useful signals come from correlating "the original requester, the identity used downstream, the resources accessed, the parameters supplied, and the final action" [2]. Most AI pipelines do not record that tuple at all, because the requester's authority was never part of the execution path.
How Do I Check Whether My AI Agent Enforces the Requester's Permissions?
You test the boundary the way you would test any privilege escalation path: send the same request with two different levels of authority and compare what each one is allowed to do [2].
This is the Clone Systems 5-Point AI Workflow Authorization Check. We run it on AI agent engagements, and you can run a working version of it yourself in about 30 minutes.
- Inventory the credentials. List every service account, API key, and OAuth token each workflow executes with. Noma Labs' first mitigation is to eliminate static administrative API keys in AI workflows in favor of identity-aware token delegation [1].
- Map the entry points. List every unauthenticated or low-trust input that can reach the workflow: the support inbox, public web forms, GitHub issues, shared documents, chat messages. The guidance is to assess every automation against the least trusted party capable of influencing what it acts on, not just "who can trigger this workflow" [1].
- Run the privilege differential test. Submit the same request as a low-privileged user and as an administrator. If the low-privileged request returns the same result, downstream systems are only seeing the workflow's identity, and that is precisely where the investigation should focus [2].
- Verify identity propagation. Confirm the requester's context is carried into the downstream action, with an explicit access control and runtime protection evaluation step between the AI output and the operation it triggers [1][2].
- Log the correlation tuple. Record the original requester, the identity used downstream, the resources accessed, the parameters supplied, and the final action on every run, so an investigation can reconstruct who asked and what happened [2].
Your 30-minute self-test. Pick one workflow that reads external input and can act on internal systems. You do not need to touch the model. For fifteen minutes, answer points 1 and 2 in a shared document. Then, with a staging environment or two test accounts, run the privilege differential test in point 3. If the low-privileged request wins, stop expanding that workflow's access until the execution layer re-checks authority. In our engagements, that single test has found workflows running with more privilege than any person who could trigger them, which is why it is the first item on every engagement.
If the differential test surprises you, you are not alone, and you do not have to fix it by guessing. Clone Systems builds AI security assessments around exactly this layer, and the CloneGuard AI assistant is part of how we monitor it in production. Talk to our team and we will scope a check against your own workflows.
Can Current AI Defenses Catch Workflow Identity Hijacking?
Model layer defenses cannot, by design. They are built to reject malicious phrasing, and this attack has none. "Standard prompt-injection detectors and agent guardrails classify these inputs identically" because the request is exactly the kind of request the model was designed to handle [1].
That does not make the model layer work pointless. The mitigations in OWASP's LLM01 entry, constraining model behavior, enforcing least privilege, requiring human approval for high risk actions, segregating and identifying external content, and treating the model as an untrusted user in adversarial testing, are all necessary [4]. But they sit at the model layer, and the workflow identity hijack failure sits at the application and infrastructure layers. Noma Labs is explicit that "mitigating these AI workflow risks requires shifting security controls from the model layer to application and infrastructure layers" [1].
There is a second gap: tracking. Teams also cannot watch for this through CVE feeds. The OWASP GenAI Q1 2026 exploit round-up found that of eight major AI related incidents documented from January through April 11, 2026, only one received a CVE identifier [3]. No CVE means no ticket in your vulnerability management queue, which is the same reason AI findings fall out of traditional scoring. We covered that problem in why your vulnerability management program can't score a prompt injection finding.
The exposure is also compounding on two fronts. Google's threat intelligence team has described a shift from prompt based misuse to autonomous, agent driven attacks that plan and execute tasks across environments, and the same execution layer highlighted by the Noma report is what those attacks rely on [2]. At the same time, the window between a flaw appearing and it being exploited keeps shrinking. An open authorization boundary does not wait for a zero day. It is the zero day, for anyone who can reach your inbox.
How Clone Systems Can Help
We run AI agent security assessments that treat the workflow, not the model, as the system under test. The engagement runs the 5-Point Authorization Check end to end: credential and entry point inventory, privilege differential testing, identity propagation verification, and correlation tuple logging review, followed by remediation support that puts the identity check into the execution path and a retest that proves the boundary now holds.
The work connects to the rest of your program where it should. If your question starts with whether the agent is even in your compliance scope, we covered the test in are AI agents in PCI DSS scope. If you are trying to understand why AI findings keep disappearing from your risk register, the scoring problem is the second half of the same story, covered in how AI is shrinking the window to fix vulnerabilities and the scoring post linked above. And if you want the monitoring to keep running after the assessment, that is what CloneGuard is for.
If you have a workflow that reads external input and acts on internal systems, the ten minute version of point 3 above takes less time than explaining an exfiltration event after the fact. Contact our team or schedule a demo and we will show you the check on a real workflow.
Frequently Asked Questions
What is workflow identity hijacking in AI workflows? An unauthenticated or low-privileged user sends a normal, benign request through an entry point such as a support inbox, and the AI workflow executes the resulting action using its own service account privileges. No prompt injection is required, because the request contains no malicious content for a detector to flag.
How is workflow identity hijacking different from prompt injection? Prompt injection manipulates how a model follows instructions, whether directly or through hidden content. Workflow identity hijacking exploits whose authority the workflow uses when executing a valid request, so the model behaves correctly while the system acts with the wrong permissions.
How do I check that my AI agent enforces the requester's permissions? Run a privilege differential test by sending the same request as a low-privileged user and as an administrator, then compare the results. If both get the same outcome, the downstream systems see only the workflow's identity and the authorization boundary is broken.
Can an unauthenticated user trigger a privileged AI workflow? Yes, whenever the workflow listens on an unauthenticated entry point and executes downstream actions with its own credentials. Noma Labs demonstrated the pattern against GitHub agentic workflows in July 2026 and separately reported it in Google Workflows, where Google acknowledged the finding and confirmed a fix.
Do prompt injection filters protect against workflow identity hijacking? No, because the triggering request is benign and standard prompt injection detectors classify it identically to a legitimate request. The failure sits in the authorization boundary, so the fix requires identity-aware controls at the execution layer rather than input filtering at the model layer.
Conclusion
Your AI workflow is not a chatbot. It is a privileged account with a reading list, and the reading list is untrusted. The model doing the reading may be state of the art, and it does not matter, because the model was never the control. The control is the identity check at execution time: who asked, who is acting, and whether the two are allowed to differ. Run the 5-Point Check against one workflow this week, close the boundary that fails, and keep the rest of your AI investment where it belongs, on what the model can read and say. Start at www.clone-systems.com.
References
[1] Noma Labs: Workflow Identity Hijacking: The Silent Backdoor in AI Workflows, Sasi Levi, September 9, 2026 (definition of workflow identity hijacking; CFO versus external sender identical-input example; "the security risk isn't in the prompt; it is in the authorization boundary"; July 2026 GitLost GitHub agentic workflow disclosure covered by over 100 outlets; Google Workflows report acknowledged and fixed; identity-aware token delegation and user-context propagation mitigations). https://noma.security/noma-labs/workflow-identity-hijacking-the-silent-backdoor-in-ai-workflows [2] CSO Online: AI workflows may be creating a dangerous new authorization blind spot, Gyana Swain, September 10, 2026 (confused deputy characterization; "the original requester's permissions are not necessarily re-evaluated when the workflow performs sensitive actions downstream"; detection requires correlating requester, execution identity, resources, parameters, and final action; Google threat intelligence shift to autonomous agent driven attacks). https://www.csoonline.com/article/4220702/ai-workflows-may-be-creating-a-dangerous-new-authorization-blind-spot.html [3] Cloud Security Alliance AI Safety Initiative: Indirect Prompt Injection Goes Operational, research note, April 26, 2026 (Google telemetry: 32% relative increase in malicious indirect prompt injection content, November 2025 to February 2026, across 2 to 3 billion pages crawled monthly; Unit 42: twelve detected IPI cases and twenty-two payload delivery techniques; OWASP GenAI Q1 2026 round-up: only one of eight major AI incidents received a CVE). https://labs.cloudsecurityalliance.org/research/csa-research-note-indirect-prompt-injection-in-the-wild-2026/ [4] OWASP GenAI Security Project: LLM01:2025 Prompt Injection (definitions of direct and indirect prompt injection; mitigations including least privilege, human approval for high-risk actions, segregating external content, and adversarial testing treating the model as an untrusted user). https://genai.owasp.org/llm01-prompt-injection/ [5] Clone Systems: In our AI agent assessments, the failure mode clients react to hardest is a benign external request producing a privileged action after prompt injection filtering has been deployed, and the privilege differential test has found workflows running with more privilege than any person who could trigger them. [6] Clone Systems: Are AI Agents in PCI DSS Scope? The Test Isn't Whether They See Card Numbers. www.clone-systems.com/blog/ai-agents-pci-dss-scope [7] Clone Systems: Why Your Vulnerability Management Program Can't Score a Prompt Injection Finding. www.clone-systems.com/blog/why-your-vulnerability-management-program-cant-score-a-prompt-injection-finding [8] Clone Systems: How AI Is Shrinking the Window to Fix Vulnerabilities. www.clone-systems.com/blog/how-ai-is-shrinking-the-window-to-fix-vulnerabilities [9] Clone Systems: CloneGuard AI assistant. www.clone-systems.com/cloneguard-ai-assistant [10] Clone Systems: Contact and consultation. www.clone-systems.com/contact [11] Clone Systems: Schedule a demo. www.clone-systems.com/schedule-a-demo