Trupti Thakur
#CyberSecurity #AISecurity #ArtificialIntelligence #IdentitySecurity #IAM #DataSecurity #InformationSecurity #CyberRisk #CloudSecurity #AI #SecurityArchitecture #ZeroTrust #AccessControl #CyberResilience #DigitalSecurityWorkflow Identity Hijacking
For years, cybersecurity has focused on protecting users, applications, endpoints, and identities. But as organizations increasingly connect AI to emails, documents, APIs, databases, ticketing systems, and business workflows, a new security boundary is emerging — the AI workflow itself. And attackers are beginning to look at that boundary differently. What Is Workflow Identity Hijacking? Workflow Identity Hijacking is a newly described attack pattern in which an attacker submits an apparently legitimate request through an exposed or unauthenticated entry point, while the downstream AI workflow performs the requested action using its own privileged identity rather than the requester's identity. The AI may behave exactly as designed. That is what makes the problem particularly interesting. Imagine an organization has an AI assistant connected to a support mailbox. An external person sends a simple request asking for information. The workflow processes the request, searches internal systems, retrieves information, and sends a response. The attacker may never have logged into the organization's environment. The critical question becomes: Who authorized the action — the person making the request, or the identity running the workflow? The Authorization Gap Traditional security models generally assume: User → Authentication → Authorization → Action AI-driven workflows can introduce a different chain: External Request → AI Workflow → Privileged Identity → Internal Data → Response If the workflow does not preserve the requester's identity and authorization context, an ordinary request can potentially inherit the workflow's permissions. This creates an authorization gap between who initiates an action and who actually executes it. Researchers reporting the technique have highlighted examples involving public or unauthenticated entry points such as support inboxes, web forms, GitHub issues, and shared documents. Why Traditional AI Defenses May Miss It Much of today's AI security discussion focuses on prompt injection, jailbreaks, malicious instructions, and model manipulation. Workflow Identity Hijacking challenges a different layer. The attacker does not necessarily need to convince the model to violate its instructions. Instead, the attacker can submit a request that the model is perfectly capable of fulfilling. The vulnerability can exist outside the model — in the identity and authorization architecture surrounding it. This means an organization can have strong prompt filtering and model guardrails while still having an authorization weakness in the workflow. The Data Security Dimension The biggest concern is not simply unauthorized workflow execution. It is what the workflow can reach. An AI workflow may have access to: Internal emails Customer information Financial records Documents and knowledge bases Source-code repositories CRM systems Cloud storage Internal APIs Business applications If these systems are connected through an overly privileged service identity, the workflow can become a bridge between an untrusted input and trusted enterprise data. This is where AI security becomes inseparable from data security and identity security. How Organizations Can Reduce the Risk Security teams should consider several controls: Preserve user identity throughout the workflow The identity initiating the request should not disappear once the AI workflow starts processing it. Apply least privilege AI agents and workflow service accounts should have only the permissions required for their specific business function. Use short-lived, scoped credentials Avoid relying on persistent administrative API keys wherever possible. Current AI-security guidance increasingly emphasizes dynamic, identity-bound credentials and stronger agent identity controls. Add authorization checkpoints AI output should not automatically translate into privileged downstream actions. Authorization should be independently evaluated before sensitive data is accessed or transmitted. Monitor the complete workflow Logging should capture not only what the AI did, but who initiated the request, which identity executed it, what data was accessed, and where the resulting information went. Separate data access from external communication An AI agent that can simultaneously access sensitive information and communicate externally creates a particularly important security boundary. The Bigger Security Lesson The emergence of Workflow Identity Hijacking highlights a fundamental change in enterprise security. We are no longer securing only human identities. We are securing identities that can interpret requests, access data, invoke APIs, and execute workflows on behalf of humans. The next generation of IAM therefore cannot stop at: “Who are you?” It must also ask: “Who initiated this action?” “Which identity is executing it?” “What authority was delegated?” “What data can this workflow access?” “And is this specific action actually authorized?” As AI moves from answering questions to taking actions, the workflow itself becomes an identity boundary. And that may be the attack surface organizations have been overlooking. The future of AI security is not only about controlling what AI says. It is about controlling what AI is authorized to do.
