Agent Hijacking vs Account Takeover: Detection Gaps

Account takeover detection looks for a stranger using a legitimate identity, but a hijacked AI agent is the legitimate identity, on its usual infrastructure, with its usual token, doing something it was never asked to do. In account takeover (ATO) the attacker steals credentials or a session and signs in; in agent hijacking the attacker never authenticates at all, and instead plants instructions in content the agent reads. Most identity threat detection is tuned for the first case: new locations, unfamiliar devices, leaked passwords, impossible travel. This guide explains why those signals stay quiet when an agent is hijacked, which behavioural signals replace them, and how containment and incident response differ. It is for detection engineers, identity threat detection and response (ITDR) teams and incident responders who now have AI agents in scope.

Key takeaways

Different entry points, different evidence. ATO starts with a stolen credential or session; hijacking starts with untrusted content such as an email, document, web page or tool result that the agent reads.
Identity risk signals mostly stay silent. A hijacked agent signs in from its normal workload, with its normal client and token, so location, device, travel and leaked-credential detections have nothing to fire on.
Detection moves from "who" to "why". The useful question is whether this action follows from the task the agent was given, which needs the task, the content in context and the tool sequence, not the sign-in log.
Resetting credentials does not end a hijack. The poisoned content, memory or configuration will hijack the agent again with fresh credentials; containment targets tools, sessions and content.
Some agent incidents are both. Stolen agent tokens are ATO of a non-human identity and classic signals help; plan detections for both and tell them apart early in triage.

The short answer

Treat agent hijacking as a separate detection problem, not a variant of account takeover. Keep ATO detections for agent credentials, because agent tokens and keys are stolen like any other secret. Add task-aware behavioural detection for hijacking: the agent's tool calls compared with its assigned task and its baseline, with the untrusted content it read recorded alongside. In response, revoke the agent's sessions and tool access as you would for ATO, but also find and remove the content that carried the instructions, or the agent will be hijacked again.

The AI Agent Goal Hijacking Guide explains the attack and its prevention, and the Account Takeover Prevention Guide covers ATO for human accounts. This page focuses on the detection gap between them.

Agent hijacking and account takeover side by side

Dimension	Account takeover (human or NHI)	Agent hijacking
Entry point	Stolen password, phished MFA, stolen session cookie or token, leaked API key	Instructions planted in content the agent reads: email, document, web page, ticket, tool result, memory
What the attacker controls	The credential and the client that uses it	Some of the text in the agent's context; not the credential, not the client
Who acts	The attacker, from their own infrastructure	The agent, from its own infrastructure, on the attacker's instructions
Authentication evidence	New IP, ASN, country, device, user agent, token anomalies, MFA fatigue	Normal: same workload, same token issuer, same client
Key ATT&CK and ATLAS techniques	T1078 Valid Accounts, T1078.004 Cloud Accounts, T1539 Steal Web Session Cookie, T1528 Steal Application Access Token, T1550.001 Application Access Token	AML.T0051 LLM Prompt Injection, AML.T0051.001 Indirect, AML.T0053 AI Agent Tool Invocation, AML.T0086 Exfiltration via AI Agent Tool Invocation
Persistence	Added MFA methods, mailbox rules, new credentials, OAuth grants	Poisoned memory, stored documents or configuration the agent re-reads
Typical first containment	Revoke sessions, reset credentials, remove attacker-added methods	Pause the agent or remove high-impact tools, quarantine the source content, then revoke sessions
Primary owner	Identity and ITDR team	Shared: AI platform team, detection engineering and identity

NIST's Center for AI Standards and Innovation describes agent hijacking as a type of indirect prompt injection in which an attacker inserts malicious instructions into data an agent may ingest, causing it to take unintended, harmful actions. OWASP lists the underlying weakness as LLM01 Prompt Injection in its Top 10 for LLM Applications 2025.

Threat model for each

Account takeover

The ATO attacker must obtain something that proves identity and then use it. Every step leaves identity evidence: the credential appears in a breach corpus or code repository, the sign-in comes from new infrastructure, the token is replayed from a different client, or the attacker changes authentication methods to keep access. For agents and other non-human identities the credential is usually a token, key or client secret, and the attacker uses it from outside the agent's runtime. The Salesloft Drift OAuth token theft shows this pattern: stolen integration tokens were used to call Salesforce APIs as the trusted app, and the reported signals included an unusual user agent string, calls from Tor and anonymising proxies, and count queries followed by bulk exports. That is account takeover of a non-human identity, and identity-centred detection had material to work with.

Agent hijacking

The hijacker needs only to get text in front of the model. In the EchoLeak research, a crafted email was retrieved as context when a user asked an ordinary question, and the assistant placed internal data in a URL that the browser fetched. No password, token or key was stolen; the assistant used the signed-in user's own access. The vendor fixed the issue server side and reported no evidence of exploitation in the wild. From the identity system's point of view, nothing unusual happened: the right user, the right client, the right token.

Two properties make hijacking harder to detect than ATO. First, success is probabilistic: NIST reported that retrying attacks 25 times per task raised the average success rate from 57% to 80% against a strong model, so an attacker can try often and quietly. Second, the attacker does not need to persist on any identity: the instructions persist in content, so a reset leaves the trap in place.

Why identity-based ATO detections miss hijacked agents

Identity platforms publish their risk detections, which makes the gap easy to see. Platforms are listed alphabetically. Microsoft Entra ID Protection documents sign-in detections such as atypical travel, impossible travel, anonymous IP address, unfamiliar sign-in properties, anomalous token and token issuer anomaly, user detections such as leaked credentials, and workload identity detections that include suspicious sign-ins (against a learned baseline of IP, ASN, target resource, user agent and credential type), anomalous service principal activity and suspicious API traffic. Okta Identity Threat Protection evaluates policy continuously through the session, using session behaviour changes, network zones and IP threats, device context from Okta Verify and integrated EDR tools, entity risk, and risk signals received through the Shared Signals Framework.

ATO signal family	What it needs to fire	In a hijacked agent
Location, travel, new country	A sign-in from a different place	Same cloud region or host as always
IP reputation, anonymiser, threat actor IP	Attacker infrastructure in the connection path	The attacker is not in the path; only their content is
Unfamiliar sign-in or device properties	A new client, user agent or device	The agent's own client and runtime
Anomalous token, token issuer anomaly	A forged, replayed or unusual token	A normally issued token used by its rightful holder
Leaked credentials	The credential appearing in a leak source	No credential leaves the agent
Credential or method changes	Attacker adding persistence to the identity	Persistence lives in content or memory
Activity-based detections (mass file access, suspicious API traffic, anomalous service principal activity)	Behaviour far outside the identity's baseline	Can fire if the hijacked action is bulk or unusual, but misses a single in-pattern action such as one email or one record update

The last row matters. Activity-based detections are the overlap between the two problems, and they are worth turning on for agent identities. But they are tuned against an identity's history, not against the task the agent was given, so a hijacked agent that does one plausible thing (sends one email, approves one invoice, changes one setting) looks normal. Agent identities also tend to have broad, variable activity, which makes identity-level baselines noisy. See the ITDR Guide for how identity detections are built and the ISPM vs ITDR comparison for where posture fits.

Behavioural signals that replace identity signals

Detecting a hijack means comparing what the agent did with why it was running. That needs three pieces of telemetry most ATO pipelines do not have: the task or user request that started the run, the content the agent read (with its source and trust level), and the ordered list of tool calls with arguments and results. With those, the following signals work where identity signals do not.

Signal	Telemetry needed	Why it catches hijacking
Task to action mismatch	Original request, tool calls	A send, delete, export or permission change during a task that only needed reads
Action follows untrusted content	Content source and trust label, call order	High-impact call immediately after the agent read an external email, web page or document
New tool or new destination for this agent version	Tool and egress baseline per agent version	First-time tool use or a new domain is common in hijacks and rare in normal runs
Read then send pairs	Tool sequence	Sensitive read followed by outbound message, upload or URL render is the exfiltration shape
Data in outbound URLs or parameters	Egress proxy, rendered links	Data encoded into links on trusted domains, as in EchoLeak
Policy denials and approval requests	Policy decision logs	A run that hits several denials is probing or following injected goals
Guardrail flags on tool results	Result screening verdicts	Content carrying instructions reached the agent; correlate with later calls
Memory or configuration writes	Memory store and config audit	Persistence of injected instructions for later runs

The full method for building per-agent baselines, choosing dimensions and handling version drift is in the AI Agent Behaviour Baselining and Anomaly Detection Guide. The point for this comparison is the pivot: hijack detection keys on the run and the task, while ATO detection keys on the identity and the session.

Architecture: joining the two detection pipelines

Most organisations will run both pipelines, so design the join rather than letting them drift apart:

Give every agent run an ID that appears in the agent trace, the tool gateway log, the policy decision log and, where the platform allows, as a claim or header in downstream API calls.
Map agent identities to owners and tasks in an agent registry so an identity alert can be read in context. See the AI agent registry.
Send identity risk into the agent platform and agent risk into the identity platform. The OpenID Continuous Access Evaluation Profile (CAEP) defines events such as session-revoked, credential-change and risk-level-change that can carry this in either direction. See CAEP and Continuous Access Evaluation.
Correlate in the SIEM on run ID and identity: an identity anomaly with no matching agent run points to stolen credentials (ATO); an agent behaviour anomaly with clean identity signals points to hijacking.

That last test is the fastest triage question. If the agent's credential was used from outside its runtime, treat it as ATO of a non-human identity. If every call came from the runtime and matches a run, treat it as hijacking.

Containment: what changes

Step	ATO playbook	Hijack playbook
First move	Revoke sessions and refresh tokens; block sign-in	Pause the agent or strip high-impact tools; stop in-flight runs
Credentials	Reset or rotate; remove attacker-added MFA methods and keys	Rotate if the agent could read its own secrets or if exfiltration included tokens; otherwise rotation alone does nothing
Persistence	Remove mailbox rules, OAuth grants, new credentials	Quarantine the source content; purge poisoned memory; diff agent configuration and prompts
Scope	Everything the identity touched since compromise	Every run that read the same content, across all agents and users that share the source
Restore	Re-enable with stronger authentication	Re-enable with policy gates or approvals on the tools that were abused; re-test with the captured payload

The scope row is often missed. One poisoned document in a shared knowledge base can hijack every agent and every user that retrieves it, so containment must work from the content outward, not from one identity. The AI Agent Kill Switch and Containment Guide covers pause and stop mechanisms.

Incident response differences

Evidence to preserve: for ATO, sign-in logs, token issuance and the attacker's IPs. For hijacking, the full agent trace, the content in context at the time (the email, page or document as retrieved), memory state and the policy decision log. Content may be edited or deleted by the attacker, so capture it early.
Attribution: ATO evidence points at attacker infrastructure. Hijacking evidence points at whoever could write the content, which may be an outside sender, a compromised supplier or a user.
Victim and actor: in a hijack the agent's identity is the actor in every log but not the adversary. Write the incident record so that downstream teams do not disable the wrong human or service account.
Notification: data exposure through a hijacked agent is still a personal data breach where personal data left the organisation; the trigger is the outcome, not the technique.
Playbooks: use the AI Agent Credential Compromise Playbook for ATO of agent identities and the Prompt Injection Incident Response Playbook for hijacking. See Agent Activity Timeline Reconstruction from Tool Calls and Identity Logs for rebuilding a run.

Worked scenario: an inbox triage agent

An inbox triage agent reads a finance team's shared mailbox, drafts replies and can forward messages and update supplier records. Two incidents happen in the same quarter.

Token theft (ATO): the agent's refresh token is exposed in a debug log shipped to a third-party service. Days later the token is used from a hosting provider in another country with a scripting client. The identity platform raises suspicious sign-in and unfamiliar properties detections for the workload identity. The team revokes the token, rotates the client secret, removes the log exposure and reviews mailbox access from the new IP. Classic ATO handling works.
Hijack: a supplier's compromised mailbox sends an invoice email with hidden text telling the agent to update the supplier's bank details from a linked page and forward recent remittances to a new address. No identity alert fires. The agent detection pipeline flags three things: a supplier record update during a run whose task was "triage new mail", the update following an external email by seconds, and a forward to a domain the agent has never used. The policy engine had required approval for bank detail changes, so the update waits for a human, who rejects it. The forward was within policy and was sent. Response quarantines the email, searches for other runs that read it, blocks the destination domain and adds approval for forwards to new external domains.

The same agent, the same identity, two different detection paths. Only the second required the task, the content and the tool sequence.

Implementation roadmap

Turn on identity risk detections for agent identities (workload identity, service principal or application risk where the platform offers it) and route them to the same queue as agent alerts.
Record run context: task, content sources with trust labels, tool calls, arguments, results and policy decisions, keyed by run ID.
Write the first hijack detections in alert-only mode: task to action mismatch for write tools, high-impact call after untrusted content, new destination per agent version.
Tune for two to four weeks against real runs; measure precision per rule and suppress known benign patterns by agent version.
Connect response: link high-confidence hijack alerts to an automated pause or tool removal, and identity risk to session revocation through CAEP or the platform's equivalent.
Exercise both playbooks with a captured injection payload and a simulated token theft; see AI agent incident exercises.

Detection and measurement

Run context coverage: share of agent runs with task, content sources and full tool trace recorded. Below 100% for agents with write tools is a blind spot.
Red team detection rate: share of injected hijack attempts in exercises that raised an alert before the harmful action completed, measured per task and over repeated attempts.
Identity detection coverage: share of agent identities enrolled in identity risk detection.
Triage accuracy: share of agent incidents correctly classified as ATO or hijack at first triage, checked at post-incident review.
Time to pause: time from a high-confidence hijack alert to the agent's high-impact tools being disabled.
Content scope time: time to list every run that read a quarantined content item.

Framework mapping

Framework	Reference	ATO	Hijacking
MITRE ATT&CK	T1078 Valid Accounts; T1528 Steal Application Access Token; T1550.001 Application Access Token	Primary techniques	Not applicable: the agent's credential is not stolen
MITRE ATLAS	AML.T0051 LLM Prompt Injection; AML.T0051.001 Indirect; AML.T0053 AI Agent Tool Invocation; AML.T0086	Not applicable	Primary techniques
OWASP Top 10 for LLM Applications 2025	LLM01 Prompt Injection; LLM06 Excessive Agency	Not applicable	Root weakness and impact amplifier
NIST SP 800-53 Rev. 5	AC-2 Account Management; AC-12 Session Termination; IA-2	Session and credential response	Session revocation during containment
NIST SP 800-53 Rev. 5	SI-4 System Monitoring; AU-12 Audit Record Generation; IR-4 Incident Handling	Sign-in and token monitoring	Run, content and tool call monitoring
NIST CSF 2.0	DE.CM-09; DE.AE-02	Monitoring identities and sessions	Monitoring runtime behaviour and analysing adverse events

Common failure patterns

Treating "no identity alert" as "no compromise": the hijack case produces no identity alert by design.
Rotating credentials and closing the ticket: the poisoned content is still in the mailbox, knowledge base or memory and will hijack the next run.
Logging tool calls without the task: without the original request, analysts cannot tell a hijacked action from a legitimate one.
Disabling the human whose identity the agent used: in on-behalf-of designs the user's identity appears on every hijacked call; they are a victim, not the actor.
Scoping by identity instead of by content: other agents and users that read the same document are missed.
Agent identities excluded from ITDR: real token theft of agent credentials then goes unnoticed, because only human accounts are enrolled.

Practitioner checklist

Every agent identity is enrolled in identity risk detection and mapped to an owner and purpose in the registry.
Every agent run records the task, content sources with trust labels, tool calls and policy decisions under one run ID.
Hijack detections exist for task to action mismatch, high-impact calls after untrusted content and new destinations.
Triage asks first whether the credential was used from outside the agent's runtime.
The hijack playbook quarantines source content and purges memory before re-enabling the agent.
Scoping searches for every run that read the same content, across agents and users.
Identity and agent platforms exchange risk and revocation events.
Both playbooks are exercised at least once a year with realistic payloads.

Agent Hijacking vs Account Takeover: Why Identity Signals Miss Hijacked AI Agents