Noma Labs has uncovered a significant security flaw they call "workflow identity hijacking," where attackers can execute privileged actions in AI-driven workflows without proper authentication. This isn't just a theoretical risk. Their research shows how AI workflows can act as unauthenticated proxies for privileged actions and data theft.
The Discovery
Researchers identified a key authorization gap in AI workflows. When you send a request to an AI agent, the system often separates your identity from the one used for downstream actions. The workflow receives your request, validates it (or doesn't), and then performs actions using its own elevated privileges.
This creates an attack surface. If an attacker finds an unauthenticated entry point in your AI workflow, they can trigger privileged operations they shouldn't access. The workflow acts as a proxy, executing actions with permissions the original requester never had.
Timeline of Events
Before Noma Labs published their findings, the Google Threat Intelligence Group noticed a trend toward agent-driven attacks. The timeline is less important than the pattern: as more AI-driven automation is deployed, authorization boundaries are created that traditional access controls don't cover.
Sasi Levi, lead researcher at Noma Labs, detailed how attackers exploit this. They identify an AI workflow endpoint, send a crafted request, and the workflow executes privileged operations using its service account credentials instead of enforcing the requester's permissions.
Control Failures
Three control failures enabled this attack:
Identity propagation broke down. Your AI workflows might authenticate the initial request but don't pass that identity context to downstream operations. When the workflow calls your database or API, it uses its own credentials instead of verifying what the original requester should be allowed to do.
Authorization checks happened at the wrong layer. You likely validate access at the workflow entry point, but not where privileged actions execute. The workflow itself becomes trusted, and everything it does inherits that trust.
Runtime monitoring didn't catch the mismatch. Your logs show the workflow making legitimate API calls using valid credentials. They don't show that those calls originated from an unauthorized request because the workflow's identity obscured the requester's identity.
Standards and Requirements
OWASP ASVS v4.0.3 Requirement 4.1.1: "Verify that the application enforces access control rules on a trusted service layer." Your AI workflow is a service layer, and it needs to enforce access control based on the original requester's identity, not its own elevated privileges.
PCI DSS v4.0.1 Requirement 7.2.2: "Access to system components and data is assigned to individuals based on job classification and function (also referred to as 'role-based access control' or 'RBAC')." Your AI workflow must respect the RBAC boundaries of the person who initiated it, not the workflow's service account.
ISO 27001 Control 5.15: Requires managing the full lifecycle of identities, including "ensuring that access rights are assigned in accordance with the access control policy." Your AI workflows need identity-aware access controls that propagate user context through every layer of execution.
NIST 800-53 Rev 5 Control AC-3: "The information system enforces approved authorizations for logical access to information and system resources." Your AI agents must enforce the user's authorization boundaries, not bypass them with elevated privileges.
Lessons and Actions
Implement user-context propagation. Capture the authenticated user's identity and pass it through every downstream operation. If your workflow queries a database, that query should run with the requester's permissions, not the workflow's service account. This requires changes to your AI integrations.
Enforce authorization at the execution layer. Validate access not just at the workflow entry point, but also when the workflow performs privileged operations. If a user shouldn't read customer PII directly, they shouldn't be able to ask an AI agent to read it for them.
Deploy runtime protection for AI workflows. Monitor and correlate the original requester's identity with the actions your workflow performs. When your AI agent makes an API call, your security tools should verify that the human who triggered the workflow has permission for the operation.
Audit your existing AI integrations. Map every AI workflow in your environment and identify where it executes privileged operations. For each operation, ask if it enforces the original requester's permissions or relies on the workflow's elevated access. Document the gaps.
Test with unauthorized requests. Create test accounts with restricted permissions. Use those accounts to send requests through your AI workflows and verify that the workflows don't grant access to resources the test account shouldn't reach. If your workflow lets a restricted user exfiltrate data they can't access directly, you have the vulnerability Noma Labs described.
The report's recommendation is clear: enforce identity-aware access at the point where actions are executed, not just at the workflow entry point. This means rearchitecting how your AI systems handle authorization. It's not a quick fix, but it's the control gap you need to close before someone exploits it.
