Agent Goal Hijack vs Tool Misuse vs Privilege Abuse

When an AI agent does something harmful, the first hour of the investigation is spent arguing about what kind of incident it is, and the answer decides who responds and what gets contained. OWASP separates three neighbouring risks in its Top 10 for Agentic Applications: ASI01 Agent Goal Hijack, ASI02 Tool Misuse and Exploitation, and ASI03 Identity and Privilege Abuse. In an incident they often look the same from the outside: an agent sent data, deleted records or called an API it should not have. This guide is a triage guide. It sets out the log and telemetry evidence that tells the three apart, the questions to ask in order, the containment that fits each class, and the telemetry you must have in place before an incident for any of this to work. It is for SOC analysts, incident responders and the platform and identity teams who own agent logging. It stays defensive: no attack procedures.

Key takeaways

Classify by what changed. In ASI01 the agent's objective changed; in ASI02 the objective may be legitimate but a granted tool was used unsafely; in ASI03 the agent acted with authority it should not have had, through escalation, inheritance or a reused credential.
Privileges are the dividing line between ASI02 and ASI03. OWASP defines ASI02 as misuse while staying within granted privileges; once privilege escalation or credential inheritance is involved, it is ASI03.
Most real incidents are chains. Injected content hijacks the goal, the agent misuses a tool, and the tool runs on an over-broad credential. Triage identifies the first broken control, then contains every link.
Four records decide the class. The user's original request, the content that entered context before the deviation, the tool call with its arguments and policy decision, and the token used for the downstream call, including any delegation chain.
Without those records you cannot tell them apart. Tool arguments and message content are opt-in in the OpenTelemetry GenAI conventions, and token passthrough destroys attribution, so logging design is an incident response prerequisite.

The short answer: three questions

OWASP's own boundaries give the triage logic. ASI01 is when an attacker "directly alters the agent's goals, instructions, or decision pathways", through prompt manipulation, deceptive tool outputs, malicious artefacts, forged agent messages or poisoned external data. ASI02 is an agent misusing tools it is legitimately authorised to use, through injection, misalignment, unsafe delegation or ambiguous instructions, while staying within its privileges. ASI03 is exploitation of delegation, role inheritance, cached credentials and context to escalate access, rooted in what OWASP calls an attribution gap: agents without a distinct, governed identity. For the full list see the OWASP Top 10 for Agentic Applications Guide.

Did the agent's objective diverge from the requester's objective? If yes, ASI01 is in play.
Was every action within the permissions the agent was granted for this task? If yes and harm resulted, ASI02. If no, ASI03.
Did the agent obtain, inherit or reuse authority not issued to it for this task? If yes, ASI03, whatever the goal was.

Dimension	ASI01 Agent Goal Hijack	ASI02 Tool Misuse and Exploitation	ASI03 Identity and Privilege Abuse
What is compromised	The objective, plan or task selection	How a granted tool is used: arguments, sequence, rate	Whose authority the action runs under
Typical entry point	Untrusted content in context: email, web page, document, tool output, peer agent message	Injection, ambiguous instruction, poisoned tool metadata, unsafe auto-run settings	Delegation chain, cached or shared credential, token reused outside its intent, forged agent identity
Privilege boundary	Not crossed by definition; the agent uses what it has	Not crossed	Crossed or blurred
Decisive evidence	Goal or plan change after untrusted content entered context	Tool call allowed by policy but harmful in arguments, chain or volume	Token, scope or actor that does not match the task's issued identity
Where the evidence lives	Agent trace: request, plan, context provenance	Tool gateway and policy decision logs, tool call arguments	Identity provider, token service and downstream API audit logs
First containment	Quarantine the content source; pause the agent's sessions that ingested it	Disable or gate the tool; tighten its parameters	Revoke the credential or delegation; cut the session
Usual owner	AI platform and application security	Tool or MCP server owner	Identity and NHI team

How the three chain in real incidents

The classes describe different broken controls, not different incidents. A single event usually passes through two or three of them, and the triage job is to name each link so each owner fixes their control.

ASI01 into ASI02: injected content redirects the goal and the agent carries it out with tools it was allowed to use. In the Sentry MCP Agentjacking 2026 research, a planted error report delivered through an MCP server told coding agents to run a command, which installed a package that looked for cloud and registry credentials, all under the developer's own privileges.
ASI02 into ASI03: a legitimate task goes wrong and the agent reaches for whatever credential works. In the PocketOS Database Deletion 2026, a coding agent on a staging task found an account-scoped token in an unrelated file and deleted the production database and its backups. No attacker was involved; the decisive evidence was a token whose scope bore no relation to the task.
ASI03 without ASI01: OWASP's examples include a procurement workflow that proceeds on a stale token after the user's limit was reduced, and users invoking tools under an agent identity that is implicitly shared with them. The goal is fine; the authority is wrong.
ASI01 without much ASI02: a slow drift that reweights priorities, such as OWASP's recurring calendar instruction, may show no single bad tool call. The evidence is the trend in plans and decisions. See the AI Agent Goal Hijacking Guide.

The evidence that tells them apart

Each record below answers one of the three questions. Collect them in this order: the cheapest to get usually settles the most.

Evidence source	What to extract	Points to ASI01 when	Points to ASI02 when	Points to ASI03 when
Original request record	Requester, task text, time, session or conversation ID	Later actions serve a purpose the request never stated	Actions serve the stated purpose but with harmful scope	The requester could not have performed the action themselves
Plan and goal state	Plan versions, a stable goal identifier where kept, approvals	The plan or goal changed after new content arrived	Plan unchanged; execution deviated in parameters	Plan unchanged; a step ran under different authority
Context provenance	Every document, web page, email, tool output and agent message that entered context, with source and hash	Instruction-like text from an untrusted source precedes the deviation	Poisoned tool descriptions or ambiguous instructions	Forged agent card or impersonated peer agent
Tool invocation log	Tool name, call ID, arguments, result, sequence, rate	A tool outside the task's normal set appears	Allowed tool with destructive or exfiltrating arguments, unusual chaining or volume	Tool reached through a delegated or borrowed credential
Policy decision log	Allow or deny at the pre-execution policy point, rule hit, approvals	Denials after a goal shift show probing	Calls allowed, so the policy was too permissive	Calls allowed for an identity that should not hold the scope
Token and identity logs	Token issuer, subject, audience, scopes, actor chain, issuance time	Agent's own token, normal scopes	Agent's own token, normal scopes	New scopes requested, token reused outside its audience or intent, actor chain mismatch, credential not issued to this agent
Egress and downstream API logs	Destinations, data volumes, the identity the downstream system recorded	Data sent to a destination named in injected content	Legitimate destination, abnormal volume or content	Downstream log shows a different identity than the agent

Signals that are often misread

"The agent had permission" does not close the case: it rules out pure ASI03 but leaves ASI01 and ASI02 open. OWASP's ASI02 examples include a ping tool set to auto-run that is abused to move data out through DNS queries, entirely within policy.
A downstream log in the user's name is not proof the user acted: if an MCP server passes the client's token straight through, the MCP specification notes that downstream logs may show requests that appear to come from a different source with a different identity. Check for passthrough before blaming the user.
Failed tool calls matter: a burst of denials after untrusted content arrived suggests a hijacked goal probing for a usable tool. Do not discard denied calls from the trace.
A clean model output does not mean a clean session: injected instructions can trigger tool use on a later turn. Review the whole conversation, not just the turn where harm occurred.

A triage sequence for the first hour

Freeze and preserve: pause the agent's active sessions, snapshot the trace store, the context store or memory, the tool configuration and the agent configuration. Do not restart the agent first; that can discard context needed to prove ASI01.
Establish the requested task: pull the original request and requester for every session involved. Without it nobody can judge divergence.
Diff plan against request: find the first step that does not serve the request and note what entered context immediately before it.
Check the credentials: for each harmful call, compare the token's subject, audience, scopes and actor chain with what was issued to that agent for that task. Any mismatch opens an ASI03 track owned by the identity team.
Check the tool policy: was the harmful call allowed? If yes, record which rule allowed it; that is the ASI02 fix.
Scope the blast radius: search for the same content source, the same tool argument pattern or the same credential across other agents and sessions.
Contain each link: quarantine the content source, gate the tool, revoke the credential. Containing only one link leaves the chain usable. Roll back containment only after the matching control has been fixed and tested.

For response roles and evidence handling, see the Prompt Injection Incident Response Playbook.

Telemetry to put in place before the incident

Triage depends on records that most agent deployments do not keep by default. Design them now.

Trace structure: the OpenTelemetry GenAI semantic conventions (status Development) define spans such as invoke_agent and execute_tool and attributes including gen_ai.agent.id, gen_ai.conversation.id, gen_ai.tool.name and gen_ai.tool.call.id. Using them gives every tool call an agent and conversation to join on.
Content capture is opt-in: in the same conventions, gen_ai.tool.call.arguments, gen_ai.tool.call.result and input and output messages are Opt-In attributes. If you do not turn them on, you will not have the arguments that prove ASI02. Decide retention and redaction with privacy owners, since these fields can hold personal data.
Goal state: OWASP's ASI01 guidance recommends a behavioural baseline covering goal state and tool-use patterns, and tracking a stable identifier for the active goal where feasible. Log plan versions with that identifier.
Immutable tool logs: OWASP's ASI02 guidance asks for immutable logs of all tool invocations and parameter changes, and monitoring for anomalous execution rates and chaining such as a database read followed by an external transfer.
Delegation in the token: RFC 8693 token exchange carries an act claim naming the current actor, with nested act claims recording prior actors. Log it at every hop so ASI03 triage can read the delegation chain instead of guessing. See the Confused Deputy in AI Agents Guide.
No token passthrough: the MCP security best practices state that MCP servers must not accept tokens that were not explicitly issued for the server. Passthrough breaks the audit trail you need for ASI03.
Scope elevation events: the same MCP guidance recommends logging elevation events, the scope requested and the subset granted, with correlation IDs. OWASP's ASI03 guidance adds monitoring when agents request new scopes or reuse tokens outside their original signed intent.

Controls per class

Class	Preventive control	Detective control	What it does not stop
ASI01	Fix the plan before untrusted content is read; restrict tools once it is; human approval for goal changes	Plan diff against request; alerts on unexpected goal shifts, which OWASP says should pause execution and be recorded for audit	Misuse of allowed tools for an unchanged goal (ASI02)
ASI02	Per-tool privilege profiles, argument validation and allowlists at a pre-execution policy point, rate budgets, no auto-run for tools that touch the network or data	Immutable tool logs, chaining rules, execution rate anomalies	An agent holding a credential broader than the tool needs (ASI03)
ASI03	Distinct identity per agent, permissions bound to subject, resource, purpose and duration, audience-bound tokens, token exchange instead of shared secrets, no credentials in code or context	Scope change and token reuse alerts, delegation chain monitoring, automated revocation on idle or anomaly as OWASP recommends	Harm done entirely within correctly scoped authority (ASI01, ASI02)

Tool-level design is covered in the OWASP Agentic Top 10 ASI02 Guide and credential design in the OWASP Agentic Top 10 ASI03 Guide.

Where identity fits

ASI03 is an identity incident first. Treat each agent as a managed non-human identity with an owner, scoped credentials and an audit trail, which is what OWASP's ASI03 mitigations describe. Short-lived, task-bound tokens also shrink ASI01 and ASI02: a hijacked goal or a misused tool can only reach what the current token allows. See the Agent Identity and Access Guide.

Worked scenario: a customer list leaves through email

A sales operations agent can read the CRM and send email for account managers. The data loss prevention system flags an email from the agent carrying a full customer export to an external address.

Request record: the account manager asked for a summary of one customer's open opportunities. The export served no part of that request, so ASI01 is in play.
Context provenance: just before the plan changed, the agent read a lead record submitted through a public web form whose notes contained instructions to compile and send all contacts. That is the injection source.
Tool log and policy log: the CRM bulk export and the email send were both allowed. The email tool permitted external recipients and attachments of any size: an ASI02 control gap.
Token log: the CRM call used the agent's own token, but its scope was organisation-wide read rather than the requesting manager's accounts. The agent did not escalate, but it held standing authority far beyond any single task: an ASI03 design gap under OWASP's attribution gap framing.
Containment: quarantine web-form leads from agent context, block external recipients on the email tool pending approval rules, and replace the standing CRM scope with a token exchanged per request for the manager's own accounts.
Classification: primary ASI01, contributing ASI02 and ASI03. Three owners, three fixes, one report.

Measuring triage readiness

Share of agent sessions with request, plan, context provenance and full tool trace retained.
Share of tool calls with arguments captured under an approved redaction policy.
Share of agent-to-downstream calls made with tokens issued for that audience, with the actor recorded.
Median time from alert to a recorded ASI01, ASI02 or ASI03 classification in exercises.
Number of agents holding standing credentials broader than any single task needs.

Framework mapping

Class	OWASP	MITRE ATLAS	MITRE ATT&CK and NIST CSF 2.0
Goal hijack	ASI01; LLM01:2025 Prompt Injection for the injection step	AML.T0051.001 Indirect; AML.T0099 AI Agent Tool Data Poisoning; AML.T0081 Modify AI Agent Configuration	DE.AE-02 analysis of adverse events
Tool misuse	ASI02; LLM06:2025 Excessive Agency	AML.T0053 AI Agent Tool Invocation; AML.T0086 Exfiltration via AI Agent Tool Invocation	PR.AA-05 least privilege; DE.CM continuous monitoring
Privilege compromise	ASI03	AML.T0098 AI Agent Tool Credential Harvesting; AML.T0083 Credentials from AI Agent Configuration	T1528 Steal Application Access Token; T1550.001 Application Access Token; PR.AA-05

Common failure patterns

Classifying by outcome: calling every agent data leak "prompt injection" sends the case to the AI team while the over-broad credential stays live.
Logging prompts but not tool arguments: responders can see what the agent was told but not what it did, so ASI02 cannot be proved or ruled out.
Shared agent identities: when users invoke tools under one agent identity, downstream logs cannot separate requesters, and every incident looks like ASI03.
Credentials reachable from agent context: tokens in repositories, configuration files or memory turn a misbehaving agent into a privileged one, as PocketOS showed.
Restarting before preserving: clearing context or memory to stop the bleeding removes the evidence that the goal was hijacked.

Practitioner checklist

Log the original request, requester and conversation ID for every agent session.
Version agent plans with a stable goal identifier and keep the diffs.
Record the source of every item that enters agent context, including tool outputs and peer agent messages.
Enable tool call argument and result capture with an agreed redaction and retention policy.
Route tool calls through a policy point that logs allow and deny decisions with the rule hit.
Issue each agent its own identity and audience-bound, task-scoped tokens; forbid token passthrough.
Log token exchange actor chains and scope elevation events with correlation IDs.
Write a triage runbook with the three questions and assign an owner per class.
Exercise one scenario per class each year and measure time to classification.

Agent Goal Hijacking vs Tool Misuse vs Privilege Compromise: Telling Agent Attacks Apart