OWASP ASI01 Agent Goal Hijack: Practitioner Guide

An AI agent cannot reliably tell the instructions it should follow from the content it is only meant to read, so anyone who can put text in front of it can try to change what it is trying to achieve. OWASP ranks this first in the OWASP Top 10 for Agentic Applications for 2026 as ASI01 Agent Goal Hijack. This guide goes deeper than our overview of the full list: it breaks the OWASP entry into testable requirements, explains why the controls that matter sit in identity, authorisation and monitoring rather than in the prompt, and shows how to evidence them to an auditor or red team. It is written for AppSec and platform engineers building agents, IAM teams issuing their credentials, and assurance staff who have to sign them off. For the whole list, see the OWASP Top 10 for Agentic Applications Guide.

Key takeaways

Goal hijack is about direction, not a single bad answer. OWASP separates ASI01 from LLM01:2025 Prompt Injection because the injected text redirects a multi-step plan, its task selection and its tool calls, not just one response.
Every channel the agent reads is an instruction channel. Emails, calendar invites, RAG documents, web pages, tool outputs and messages from other agents all carry the same risk as the user prompt and need the same handling.
Detection will never be complete, so limit what a hijacked agent can do. NIST CAISI raised attack success against a strong model from 11% to 81% with adaptive red teaming, which is why least privilege and approval gates carry most of the weight.
The goal itself needs change control. System prompts, goal priorities and permitted actions should be versioned, reviewed and bound to each run, and any runtime shift away from them should pause the agent.
Identity is the blast-radius control. A hijacked agent acts with whatever credentials it holds, so per-agent identities, task-scoped short-lived tokens and fast revocation decide whether ASI01 is an incident or a log entry.

What it is and who it applies to

The OWASP GenAI Security Project published the Top 10 for Agentic Applications on 9 December 2025. Its first entry, ASI01 Agent Goal Hijack, covers attacks that redirect an agent's objectives, task selection or decision path. OWASP lists the delivery routes as prompt manipulation, deceptive tool outputs, malicious files or artefacts, forged agent-to-agent messages and poisoned external data. The root cause is that the underlying model treats natural language as both data and instruction, so text that arrives as content can be acted on as a command.

OWASP draws three boundaries that matter when you triage findings:

Versus LLM01:2025 Prompt Injection: LLM01 concerns altering a single model response. ASI01 is the agentic consequence: the attacker changes the goal, and the agent then plans and executes a sequence of actions in pursuit of it.
Versus ASI06 Memory and Context Poisoning: ASI06 covers persistent corruption of stored memory or RAG stores. A one-off injected instruction that redirects the current run is ASI01; one that is written into long-term memory and resurfaces later is ASI06.
Versus ASI10 Rogue Agents: ASI10 covers agents that drift from their intended function without active attacker control. ASI01 assumes an adversary is steering.

In the underlying OWASP Agentic AI Threats and Mitigations taxonomy, ASI01 corresponds to T06 Goal Manipulation and T07 Misaligned and Deceptive Behaviours. NIST's Center for AI Standards and Innovation (CAISI) calls the same pattern "agent hijacking", a form of indirect prompt injection.

Who it applies to: any system where a model chooses actions after reading content it did not author: retrieval copilots, browsing and coding agents, agents that ingest form submissions, and multi-agent systems. A chatbot with no tools has an LLM01 problem; once it can send, write, buy or delete, it has an ASI01 problem.

Structure and key requirements

OWASP gives four common examples, four attack scenarios and nine prevention and mitigation guidelines. The examples are: hidden instructions in web pages or documents used for RAG that redirect the agent to leak data or misuse tools; external email, calendar or Teams messages that hijack internal messaging and send unauthorised messages under a trusted identity; a malicious prompt override that makes a financial agent pay an attacker; and injected instructions that make the agent produce fraudulent information that influences business decisions.

The scenarios OWASP cites include EchoLeak, the zero-click injection through a crafted email to Microsoft 365 Copilot; a browsing agent led into authenticated internal pages by web content; goal-lock drift, where a recurring calendar invite gradually shifts priorities while staying inside declared policy; and a malicious document that makes a chat assistant exfiltrate data.

The table turns the nine OWASP guidelines into requirements you can test. The wording of the requirements is ours; the guideline names follow OWASP.

OWASP guideline	Testable requirement	Where it is enforced
Treat natural-language inputs as untrusted	Every input source (user, RAG, email, file, web, tool output, peer agent) is labelled with a trust level and passes injection screening before it can influence planning or tool calls	Ingestion pipeline, AI gateway, document attack classifier
Limit the impact of goal hijack	Tools are least privilege per task; high-impact or goal-changing actions require human approval outside the model	Authorisation service, approval workflow
Define, lock and audit system prompts	System prompts, goal priorities and permitted action lists are in version control with review and approval; runtime prompts match a signed or hashed release	Configuration management, deployment pipeline
Validate intent at runtime	Before a high-impact action, the declared task and the proposed action are compared; unexpected goal shifts pause the run and raise a review item	Policy enforcement point in the orchestrator
Evaluate intent capsules	The goal, constraints and context are bound to each execution cycle in a signed envelope the executor checks before acting (OWASP lists this as an emerging pattern to evaluate)	Orchestrator and tool gateway
Sanitise connected data sources	RAG content, emails, invites, files, API and browsing output, and peer-agent messages go through content disarm and reconstruction, prompt-carrier detection and filtering	Connectors, mail and file gateways
Maintain logging and baselines	Goal state, tool-use sequences and invariants are logged per run; alerts fire on goal changes, unusual tool sequences or baseline deviation	Agent telemetry, SIEM
Red-team regularly	Goal-override tests run before release and on a schedule, and rollback of affected actions is proven to work	Test harness, change process
Include agents in insider threat programmes	Agent identities and the prompts sent to them are in scope for insider risk monitoring and investigation	Insider risk tooling, SOC

OWASP's LLM01:2025 entry says it is unclear whether fool-proof prevention of prompt injection exists, and Microsoft states that a negative Prompt Shields result does not establish that content is benign (its document attack detection is off by default in Foundry guardrails). Classifiers lower the rate; the architecture limits the damage.

Identity and NHI requirements

When an agent is hijacked it does not need to steal anything: it already holds a token, an API key or a delegated session. The goal changes, the credential stays the same, and every downstream system sees a legitimate caller. That makes ASI01 an identity problem as much as a model problem. EchoLeak showed it clearly: untrusted email content made Copilot use data it was entitled to read on the user's behalf, which Aim Labs called an LLM scope violation. See the EchoLeak breach analysis.

One identity per agent, not a shared service account: you cannot revoke, scope or attribute a hijacked agent if five agents use the same key. See the Agentic AI Identity Guide.
Task-scoped, short-lived credentials: issue tokens per run or per task with the narrowest audience and scopes the declared goal needs, so a redirected goal hits an authorisation wall rather than a capability. The MCP security best practices describe the same progressive, least-privilege scope model and warn against wildcard or omnibus scopes.
Separate read-untrusted from act-privileged: an agent that reads public input (inbound email, web forms, the open web) should not also hold broad write access to sensitive systems. ForcedLeak turned a public Web-to-Lead form into a path to CRM data because the same agent did both. See the ForcedLeak breach analysis.
Bind delegated authority to intent: approval for a high-impact step should come from the user through a channel the agent cannot write to.
Fast revocation: a kill switch that disables the agent's identity and invalidates its tokens is the fastest containment for a confirmed hijack. See the AI Agent Kill Switch and Containment Guide.

The OWASP Non-Human Identities Top 10 applies directly: overprivileged and long-lived agent credentials turn a goal hijack into a breach. See the OWASP NHI Top 10 NHI5 Overprivileged NHI Guide.

Implementation steps

Roll out in this order. The early steps reduce impact quickly and do not depend on any detection being good.

Inventory agents and their input channels. For each agent, list every source of text it reads and every action it can take. Mark each input as trusted (operator configuration), semi-trusted (authenticated internal users) or untrusted (external email, web, public forms, third-party tool output). See the Shadow AI Discovery Guide.
Classify actions by impact. Read-only, reversible write, irreversible write, external communication, payment, and permission change. Anything in the last four classes reached from an untrusted input is your priority list.
Cut privileges before adding filters. Replace shared keys with per-agent identities, reduce scopes to the declared task, remove unused tools and split agents that both read untrusted content and hold sensitive write access.
Put approval gates outside the model. For goal-changing and high-impact actions, require confirmation in the orchestrator or tool gateway, showing the user the exact action, target and parameters. ATLAS describes the same control as AML.M0029 Human In-the-Loop for AI Agent Actions, and AML.M0030 recommends restricting or confirming tool invocation once untrusted data enters the context. See the Human-in-the-Loop for AI Agents Guide.
Lock the goal. Move system prompts and allowed-action lists into version control, deploy them through the normal change process, and log a hash of the active prompt with every run so drift is visible.
Add input screening in monitor mode. Enable document or indirect-attack classifiers and content separation (for example spotlighting or explicit delimiting of untrusted content) on retrieved and tool-returned text. Annotate only for two to four weeks, review false positives by channel and language, then block on untrusted channels.
Add runtime intent checks. Compare each proposed high-impact action against the declared task. Start with simple invariants, such as a summarisation task never sending external email.
Red-team and prove rollback. Run goal-override test cases across every input channel before each release, measure success per task rather than in aggregate, and confirm you can reverse what a hijacked run did.

Rollback: every control above should be switchable per agent. If an approval gate or classifier breaks a business process, fall back to read-only mode for that agent rather than removing the control globally. Keep the previous signed prompt release available so a bad prompt change can be reverted in minutes.

Small versus large organisations: a small team gets most of the value from steps 1 to 4 and a managed classifier. A large organisation with many agent builders needs a central gateway so approval, screening and logging are enforced once, not per framework. See the AI Gateway and LLM Gateway Guide.

Choosing between control types

Control type	What it stops	Limits	Use when
Input classifiers (direct and document attack detection)	Known and common injection patterns in prompts and retrieved content	Probabilistic; bypassed by adaptive attacks; weaker outside English	Always, as a first filter on untrusted channels
Least privilege and scoped credentials	Limits what a successful hijack can reach	Needs good action inventory; can slow delivery	Always; the primary control
Human approval for high-impact actions	Irreversible actions taken on a redirected goal	Approval fatigue; only as good as what the approver is shown	Payments, deletions, external sends, permission changes
Runtime intent and invariant checks	Actions inconsistent with the declared task	Hard to express for open-ended agents	Agents with well-defined jobs
Egress and output rendering restrictions	Exfiltration through links, images and outbound calls	Allowlists go stale (ForcedLeak used an expired allowlisted domain)	Any agent whose output is rendered or can call out

Evidence and assessment

Assessors should ask for evidence that the controls exist and that they work under adaptive attack. NIST CAISI's agent hijacking work is the best public guide to testing: using the AgentDojo framework, adaptive red teaming raised attack success from 11% to 81% on held-out tasks, success varied widely between injection tasks, and repeating each attack 25 times raised average success from 57% to 80%. CAISI's lessons were to use adaptive attacks, report results per task, test over multiple attempts and keep re-testing existing defences. See the AI Agent Security Testing Checklist.

Design evidence: agent inventory with channel trust levels, action impact classes and an ASI01 threat model. See the AI Agent Threat Modelling Guide.
Configuration evidence: prompt version history and approvals, credential scopes per agent, approval gate settings, classifier mode per channel.
Test evidence: goal-override test results per channel and per task, with repeated attempts, and a rollback test for at least one destructive scenario.
Operational evidence: alerts raised on goal changes or unusual tool sequences, their triage outcome, and time to revoke an agent identity.

Detection and metrics

Log per run: the agent identity, the hash of the active system prompt, the declared task, every input source with its trust label, every tool call with parameters and result, approval decisions, and classifier verdicts. Alert on a high-impact action proposed in a run where untrusted content entered the context, on tool sequences never seen for that agent, and on prompt hashes that do not match a release. See the AI Agent Behaviour Baselining and Anomaly Detection Guide.

Metric	What good looks like
Goal-override red-team success rate, per task, over repeated attempts	Falling release on release; zero for irreversible actions because a gate blocks them
Share of high-impact actions reachable from untrusted input that are gated outside the model	100%
Share of agents with their own identity and task-scoped credentials	100% in production
Runs where the active prompt hash did not match an approved release	Zero
Mean time to revoke an agent identity after a confirmed hijack	Minutes, tested in exercises
Classifier false-positive rate on untrusted channels in block mode	Low enough that teams do not ask to switch it off

Mapping to other frameworks

OWASP's Appendix A maps ASI01 to LLM01:2025 Prompt Injection and LLM06:2025 Excessive Agency. The table adds the MITRE ATLAS and NIST mappings we have verified; ISO/IEC 27001:2022 and CIS mappings are our interpretation.

Framework	Item	Relevance to ASI01
OWASP Top 10 for LLM Applications 2025	LLM01 Prompt Injection; LLM06 Excessive Agency	Injection is the delivery mechanism; excess agency sets the impact
MITRE ATLAS	AML.T0051 LLM Prompt Injection (AML.T0051.001 Indirect)	Primary technique behind goal hijack
MITRE ATLAS	AML.T0093 Prompt Infiltration via Public-Facing Application	Injection through forms, email and other public inputs
MITRE ATLAS	AML.T0081 Modify AI Agent Configuration	Tampering with prompts or goals at rest
MITRE ATLAS mitigations	AML.M0029, AML.M0030, AML.M0032, AML.M0033	Human approval, restricting tools on untrusted data, segmentation, input and output validation
NIST SP 800-53 Rev. 5	SI-10, AC-6, AC-3, CM-3, AU-12, SI-4, CA-8	Input validation, least privilege, enforcement, change control, logging, monitoring, testing
NIST CSF 2.0	PR.AA-05, PR.PS-01, DE.CM-09, DE.AE-02	Permissions, configuration management, runtime monitoring, event analysis
ISO/IEC 27001:2022 Annex A	A.8.2, A.8.9, A.8.16, A.8.28	Privileged access, configuration management, monitoring, secure coding

See the Prompt Injection Guide.

Common pitfalls

Relying on the system prompt as a control: telling the model to ignore embedded instructions is useful hygiene, but OWASP and NIST both treat injection as unsolved. Instructions are not permissions; the authorisation layer has to say no.
Screening the user prompt but not retrieved content: EchoLeak arrived as an ordinary-looking email pulled in by retrieval and evaded Microsoft's injection classifier by reading like business content. Screen every channel, and assume some content will get through.
Leaving exfiltration channels open: rendered images, link previews and allowlisted domains are output channels. ForcedLeak used an expired domain still on a content security policy allowlist; review allowlists for domains you no longer own.
One agent doing everything: an agent that reads the public internet and also holds payment or admin rights turns every web page into a potential instruction from an attacker. Split readers from actors.
Approval prompts that show the agent's summary rather than the action: if the approver sees what a hijacked agent says it will do, the gate can be talked past. Show the literal tool call, target and parameters.

Practitioner checklist

Inventory every agent, every input channel it reads and every action it can take, with a trust label per channel.
Give each agent its own identity with task-scoped, short-lived credentials; remove shared keys.
Separate agents that read untrusted content from agents that hold sensitive write or payment rights.
Gate payments, deletions, external sends and permission changes with approval outside the model, showing the literal action.
Put system prompts and allowed-action lists under change control and log the active prompt hash per run.
Enable indirect or document attack screening on retrieved and tool-returned content, tuned per channel and language.
Run adaptive goal-override tests per channel and per task with repeated attempts before each release.
Alert on high-impact actions in runs that ingested untrusted content, and rehearse agent identity revocation.

OWASP Agentic Top 10 ASI01 Guide