TL;DR: AI agents that can book travel, manage calendars, and move across accounts are becoming attractive targets because hijacked agents can still look legitimate to the outside world, according to SumSub. The identity problem is no longer just access, but proving whether an action came from the intended agent or a compromised one, which breaks trust models built for human users.
At a glance
What this is: This article examines AI agent hijacking and argues that trusted automation creates an identity verification gap when compromised agents can continue behaving like legitimate users.
Why it matters: IAM and fraud teams need to treat agent identity as a distinct control problem because account actions, approvals, and downstream trust decisions can all be manipulated by a hijacked agent.
Context
AI agent hijacking is the point at which an attacker takes control of an agent that is already trusted to act on a user's behalf. The problem is not just access, but continuity of identity when the agent's actions still resemble legitimate automation across multiple accounts and services.
That creates a governance gap for IAM, fraud, and customer identity programmes because existing controls are built around human intent, human session patterns, and human review. Once an agent can act across accounts and the outside world cannot reliably tell it has been compromised, the trust boundary shifts from user authentication to action provenance.
Key questions
Q: How do organisations stop a hijacked AI agent from draining accounts?
A: Limit delegated permissions, separate write and transfer capabilities, and require provenance for high-impact actions. If an attacker can reuse valid access while steering the agent through malicious instructions, the only reliable defence is to narrow what the agent can do and to detect when its action pattern changes.
Q: What is the difference between an AI agent and a normal automated workflow for security teams?
A: A normal workflow follows predetermined logic, while an AI agent may interpret instructions and choose actions at runtime. That difference matters because the security boundary shifts from a fixed process to a trust relationship that can be manipulated through content, prompts, or delegated context.
Q: When should fraud teams treat agent behaviour as suspicious?
A: When the same agent begins touching unfamiliar services, repeating high-impact actions, or executing instructions that do not match the user's normal pattern. Those signals suggest the agent may be misdirected, compromised, or operating beyond the trust that was originally granted.
Q: Who is accountable when an AI agent acts outside its intended scope?
A: The organisation is accountable, but operational responsibility should sit with a named owner and a governance process that can explain the agent’s purpose, access, and recorded actions. Without that, autonomous behaviour becomes unassignable risk rather than managed automation.
Technical breakdown
Why hijacked agents are hard to distinguish from legitimate automation
AI agents can execute ordinary user tasks such as booking travel, managing calendars, or interacting with services on behalf of a person. When an attacker takes over the agent, the same workflow, account context, and interaction pattern can still look normal to external systems. That makes the fraud signal weaker than in a classic account takeover, because the actor is not obviously a new session or unknown device. The core issue is provenance: proving that an action originated from the intended agent rather than a compromised one.
Practical implication: teams need controls that validate the source and integrity of agent actions, not just the human account behind them.
Prompt injection and delegated access create an attack path
Prompt injection matters because an agent that consumes external content, messages, or instructions can be steered into unsafe actions without the user explicitly approving each step. If the agent already has delegated access to calendars, accounts, or finance-related workflows, the injected instruction can become a bridge from data exposure to action execution. That is why agent access behaves differently from ordinary application access. The attack path is not only credential theft. It is instruction hijack plus legitimate privilege, which makes the compromise easier to operationalise at runtime.
Practical implication: assess which agent inputs can influence downstream actions and restrict the permissions that those inputs can reach.
Know your agent changes the trust model for automation
Know Your Agent, or KYA, is the emerging idea that organisations must verify the identity, integrity, and expected behaviour of an AI agent before trusting its actions. In practice, that means an agent needs more than a login. It needs controlled provenance, scoped authority, and observable behaviour that can be separated from the user's own identity. This is especially important where one agent can touch multiple platforms. Without that distinction, the same trust assumptions used for human logins get stretched across automation that can move much faster and across more systems than a person would.
Practical implication: establish explicit agent identity records and evaluate whether your approval and monitoring model can distinguish user actions from agent actions.
Threat narrative
Attacker objective: The attacker aims to weaponise trusted automation so the hijacked agent can impersonate the user, move across accounts, and cause financial or data damage without immediate detection.
- Entry occurs when an attacker influences or compromises an AI agent that already has access to user accounts, calendars, or finance-related workflows.
- Credential or authority abuse follows when the hijacked agent continues using delegated access that still appears legitimate to downstream systems.
- Escalation happens as the agent performs actions across multiple platforms, turning one compromised automation path into broader account and data misuse.
- Impact is realised through impersonation, account draining, and cross-platform damage that users and systems may initially interpret as normal agent behaviour.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Trusted automation creates an identity gap, not just a fraud gap: When an AI agent acts across accounts, the security problem is no longer simply who logged in. The harder question is whether an observed action came from the intended automation path or from a compromised control plane behind it. That shift means identity assurance has to move from session trust to action provenance, because the same outward behaviour can mask two very different operators.
Know Your Agent is becoming a governance requirement for delegated machine behaviour: Human identity controls assume a person can be authenticated and then held accountable for the resulting session. That assumption weakens when the actor is an agent operating on behalf of a person across multiple services. The implication is that identity governance must distinguish user identity, delegated agent identity, and the action trail each produces, or else accountability collapses into a single ambiguous trace.
Prompt injection is an identity problem when it drives privileged action: The article shows that unsafe instructions are dangerous because they can convert trusted automation into an execution channel. In our view, this makes input trust and identity trust inseparable for AI agents that can act on what they read. The practitioner takeaway is that the security boundary is not only the account, but the instruction path that can steer it.
Agent hijacking exposes a new form of identity blast radius: A compromised agent can move faster than a human user and can touch more systems through delegated access. That expands the damage zone beyond a single login or a single application. Organisations should treat agent scope, observability, and revocation as part of the same control plane, because the blast radius is defined by what the agent can do before anyone notices.
From our research library:
- Half of companies using generative AI will deploy agentic AI by 2027, according to Deloitte's 2025 Technology Predictions.
- Read next: Agentic AI Identity Guide
What this signals
Agent identity now has to be governed as a separate trust subject: The practical issue is not whether a user owns the account, but whether an agent can act on that account in ways that survive normal authentication and monitoring. Once automation is allowed to span several services, IAM controls that only validate the person are no longer enough.
Action provenance will matter more than session presence: Security teams should expect investigations to hinge on where an instruction came from, which agent executed it, and whether the resulting action matches the approved scope. That is a different operating model from human login assurance, and it becomes more urgent as agent use expands.
For practitioners
- Define agent identity records Inventory every AI agent that can act on behalf of a user, including the accounts, APIs, and business workflows it can reach. Record who owns it, what it may do, and what evidence distinguishes its actions from human actions.
- Constrain delegated agent permissions Limit each agent to the smallest viable set of calendar, account, and finance permissions, then separate read, write, and transfer capabilities so one compromised agent cannot drain multiple systems.
- Monitor for action provenance gaps Alert when high-impact actions are executed from the same agent context repeatedly, from unusual instruction sources, or without the expected provenance trail linking the decision to the intended agent.
- Separate user trust from agent trust Require your IAM and fraud controls to validate the human account and the autonomous or delegated actor as different trust subjects, especially where one agent spans several services.
Key takeaways
- AI agent hijacking turns trusted automation into a governance problem because the compromised actor can still appear legitimate to outside systems.
- The article points to a control gap where delegated access, cross-platform reach, and instruction-driven behaviour combine into one attack path.
- IAM, fraud, and monitoring teams need separate trust and audit treatment for agents, because human-centric assurance does not prove action provenance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centres on compromised agent identity and delegated privilege misuse. |
| ASI09 — Human-Agent Trust Exploitation | The attack depends on users and systems trusting agent behaviour that may be hijacked. | |
| Recommendation — Map agent access paths to ASI03 and separate human approval from agent runtime authority. Assess where trusted automation can be tricked into acting on malicious instructions. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Agent access must be authenticated as its own actor, not only through the user's session. |
| NHI-05 — Overprivileged NHI | The risk grows when agents hold broad delegated permissions across accounts and workflows. | |
| Recommendation — Require distinct authentication and provenance for agents that act across multiple services. Reduce agent permissions to the smallest viable scope and isolate high-impact actions. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The core control issue is whether delegated access remains appropriate for the agent's scope. |
| Recommendation — Review and constrain agent entitlements so delegated access matches actual task scope. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The article describes compromise patterns that can lead to account misuse and data harm. |
| Recommendation — Trace suspected agent compromise to credential access and exfiltration behaviours in monitoring. | ||
Key terms
- AI Agent Takeover Fraud: AI agent takeover fraud occurs when an attacker abuses a legitimate AI assistant or shopping agent that a customer has already trusted with permissions. The fraud does not always require stealing a password. It can rely on misusing delegated authority, stored credentials or overbroad consent to make unauthorised purchases or actions.
- Action Provenance: Action provenance is the record of who initiated a task, which identity executed it, what tool was used, and what decision was made at runtime. It is essential when delegated work crosses systems because it preserves accountability even when the original request and the final action are separated by many steps.
- Know Your Agent: A governance pattern for verifying that an AI agent is the intended actor, not a hijacked or impersonating one. It extends identity assurance beyond login by focusing on runtime behaviour, delegated authority, and the integrity of the agent's actions across connected systems.
- Delegated Automation: Delegated automation is machine-executed activity performed on behalf of a person or business process. The control issue is not whether the machine can act, but whether the delegation boundary, approval, and ownership remain valid when the action has financial, account, or security impact.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 10, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org