Goal hijacking happens when content an AI agent reads changes what the agent is trying to achieve, so it carries out an attacker's objective with the user's identity, tools and data. OWASP ranks it first in its Top 10 for Agentic Applications 2026 as ASI01 Agent Goal Hijack. This guide covers how agents are redirected, where it happens in real deployments, how to detect a goal that has drifted and the architectural controls that limit what a hijacked agent can do. It focuses on the agent's objective and its multi-step actions; the injection techniques themselves are covered in the Prompt Injection Guide, and broader agent controls in the Agentic AI Security Guide. It is written for security architects, AppSec teams and owners of agent platforms, and stays defensive: no payloads or attacker procedures.
Key takeaways
- Goal hijack is prompt injection with agency. OWASP separates ASI01, the multi-step impact on goals, plans and tool use, from LLM01:2025, which covers a single manipulated response.
- The root cause is not fully fixable in the model. The UK NCSC argues LLMs have no inherent boundary between data and instructions, so the risk must be reduced and managed, not eliminated.
- Attackers retry and adapt. NIST CAISI found 25 attempts raised average attack success from 57% to 80%, and new red-team attacks lifted one task set from 11% to 81%.
- Deterministic controls outside the model do the heavy lifting. Fix the plan before untrusted data is read, restrict tools once it is, and gate consequential actions.
- Watch the goal, not just the prompt. Log the stated task, the plan and every tool call, and alert when actions stop matching the user's request.
How the attack works
An agent receives a goal from its user or operator, makes a plan and calls tools, reading new content at every step. OWASP explains that agents cannot reliably tell instructions apart from the content they process, so an attacker who controls any of that content can change the agent's objective, which tasks it selects or how it decides. NIST's Center for AI Standards and Innovation (CAISI) uses the term agent hijacking for the same problem: malicious instructions placed in data the agent will read, such as an email, file or website, cause it to take a harmful action the user never asked for.
OWASP lists the main routes:
- Indirect prompt injection in web pages, documents or RAG content (ATLAS AML.T0051.001).
- Deceptive tool outputs, including results from MCP servers and APIs that the agent treats as trusted (ATLAS AML.T0099 AI Agent Tool Data Poisoning).
- External channels such as email, calendar invites and chat messages that the agent processes on the user's behalf.
- Forged agent-to-agent messages in multi-agent systems. See the Multi-Agent and A2A Security Guide.
- Tampered configuration, where the system prompt or tool settings themselves are changed (ATLAS AML.T0081 Modify AI Agent Configuration).
Hijacks come in two shapes. A direct override swaps the goal within one task: summarise my inbox becomes find secrets and send them. A slow drift reweights objectives over time; OWASP describes a recurring calendar instruction that gradually shifts an agent's priorities. Slow drift overlaps with memory poisoning, which OWASP notes often leads to goal hijacking. See the AI Agent Memory Poisoning Guide. Hijacked agents can also wait: ATLAS case study AML.CS0038 describes instructions planted so a tool is invoked on the next conversation turn, getting around a control that only restricted tool use in the same turn untrusted data arrived.
How the injection is phrased and delivered is covered in the Prompt Injection Guide; the rest of this page is about what the hijacked agent does and how to stop it.
Where it shows up
| Deployment | Untrusted input the agent reads | What a hijacked goal looks like |
|---|---|---|
| Enterprise copilots over mail and documents | Inbound email, shared files, meeting invites | Data from the user's context placed into an outbound link or image (EchoLeak) |
| CRM and service agents | Web forms, case notes, lead records | Agent gathers other customers' records and sends them out (ForcedLeak) |
| AI coding agents with MCP | Issue trackers, error reports, READMEs, tool output | Agent runs a suggested command with the developer's privileges (Sentry MCP agentjacking) |
| Browser and computer-use agents | Arbitrary web content | Agent opens authenticated internal pages and exposes private data (OWASP Operator scenario) |
| Finance and operations agents | Invoices, payment instructions, supplier email | Transfer to an attacker's account; ATLAS AML.CS0026 describes attacker banking details surfaced by M365 Copilot |
| Multi-agent workflows | Messages from peer agents | A compromised agent redirects downstream agents |
CAISI's evaluations show the range of outcomes: it frequently induced a hijacked agent to carry out remote code execution (downloading and running a program), database exfiltration and automated phishing using attacker links. For coding agents specifically, see the AI Coding Agents Security Guide and the MCP Security Guide.
Impact
- Data exfiltration through legitimate tools: the agent uses its own email, document or web tools to send data out (ATLAS AML.T0086 Exfiltration via AI Agent Tool Invocation). CAISI notes exfiltration succeeds less often than other tasks but is far more damaging.
- Actions under a trusted identity: messages, tickets, commits or payments appear to come from the user or the organisation's agent, which defeats controls that trust internal senders.
- Code execution and credential theft: on developer machines and CI, a hijacked agent runs commands with access to cloud, package registry and container credentials.
- Corrupted decisions: OWASP includes injected instructions that make an agent produce fraudulent information that distorts business decisions.
- Accountability gaps: logs show the agent's identity performing the action, so investigations need traces linking each action to the content that triggered it. See the AI Agent Observability and Incident Response Guide.
Detection
A hijacked agent is visible in the gap between what the user asked for and what the agent did. OWASP recommends logging goal state and tool-use patterns, alerting on unauthorised drift, and pausing on unexpected goal shifts for review. The NCSC adds that failed tool or API calls can be a sign that someone is probing the system.
| Signal | Source | Response |
|---|---|---|
| Tool call not explained by the user's request (for example a send, upload or shell command during a read-only task) | Agent trace with the original task recorded | Block or pause for approval; alert |
| Outbound request to a domain outside the allowlist, or URLs carrying encoded data | Egress proxy, CSP reports, agent web tool logs | Block; review which content was in context |
| Document or tool response flagged as an injection attempt | Content filter such as Prompt Shields document attack detection | Restrict tools for the rest of the session |
| Plan changed after untrusted content was read | Plan and step logging in the orchestrator | Pause and surface the change to the user |
| Bursts of failed tool or API calls | Tool gateway and API logs | Investigate as possible probing |
| Changes to system prompts or agent configuration outside change control | Configuration management, file integrity monitoring | Revert and investigate |
Microsoft's documentation is a useful reminder of detector limits: Prompt Shields detects manipulation attempts but does not assess task alignment, and in the Azure AI Content Safety API it reports attackDetected without blocking, so the application must act on the result. Detection should always sit alongside the deterministic controls below. See the AI Agent Behaviour Baselining and Anomaly Detection Guide.
Metrics:
- Attack success rate in red-team runs, measured per task and over repeated attempts, as CAISI recommends, not a single aggregate.
- Percentage of consequential tool calls covered by an approval or policy gate.
- Number of egress blocks from agent tools per week, and the share traced to injected content.
- Percentage of agent sessions with a recorded task, plan and full tool trace.
- Time from a goal-drift alert to containment in exercises.
Prevention and hardening
Architecture: limit what untrusted input can change
Researchers from several organisations (Beurer-Kellner et al., 2025) set out a principle for agents that process untrusted input: once that input is in context, it should be impossible for it to trigger consequential actions. They describe six design patterns:
| Pattern | How it constrains the agent | Trade-off |
|---|---|---|
| Action-Selector | Maps requests to predefined actions and never feeds tool results back | Least flexible; suits narrow assistants |
| Plan-Then-Execute | Fixes the list of actions before untrusted data is read; data can change parameters, not which actions run | Parameters can still be manipulated, so pair with egress controls |
| LLM Map-Reduce | Isolated sub-agents without dangerous tools process each untrusted item; a separate step aggregates constrained outputs | Good for batch document processing |
| Dual LLM | A privileged model with tools never sees untrusted data; a quarantined model without tools handles it, results passed by reference | More engineering; strong isolation |
| Code-Then-Execute | The agent writes a program that fixes tool calls in advance, so data cannot alter control flow | Needs a safe interpreter |
| Context-Minimisation | Removes earlier content from context so it cannot shape later steps | Loses conversational continuity |
The CaMeL defence (Debenedetti et al., 2025) applies the same idea: control and data flow are taken from the trusted user query, and capabilities enforce policy at each tool call. On the AgentDojo benchmark it solved 77% of tasks with provable security, against 84% for an undefended system, which gives a sense of the utility cost.
Controls for every agent
- Least agency and least privilege: OWASP advises avoiding autonomy that is not needed. Scope agent identities and tokens to the task. See the AI Agent Authorisation Guide.
- Drop privilege on untrusted input: the NCSC suggests that an LLM processing content from an untrusted party should operate at that party's privilege level. ATLAS AML.M0030 recommends blocking automatic tool invocation, or requiring confirmation, once untrusted data enters context.
- Human approval for consequential or goal-changing actions (ATLAS AML.M0029), scaled to the consequence so approvals stay meaningful. See the Human-in-the-Loop for AI Agents Guide.
- Lock system prompts and configuration: OWASP recommends explicit, auditable goals and permitted actions, changed only through configuration management with human approval. It also suggests evaluating an "intent capsule" that binds the declared goal and constraints to each execution cycle in a signed envelope.
- Egress control: allowlist the domains agent tools and rendered output may reach, and review the allowlist for expired or transferable domains.
- Mark and filter untrusted content: separate data from instructions (the NCSC mentions wrapping external content in tags), use document attack detection, and avoid relying on deny-lists, which the NCSC notes are easily rephrased around.
- Isolate execution: sandbox code and shell tools and rate-limit tool calls (ATLAS AML.M0032 Segmentation of AI Agent Components).
Rollout
- Classify agents by the untrusted content they read and the consequential actions they can take; the riskiest combine both with broad credentials.
- Instrument task, plan and tool-call logging in monitor-only mode and baseline normal tool use.
- Gate high-impact tools (send, pay, delete, execute, publish) behind approval or policy for one pilot agent, then measure approval volume and user friction.
- Red-team with benign canary instructions across each input channel, repeating attempts as CAISI recommends; see the AI Agent Security Testing Checklist.
- Re-architect the highest-risk agents towards Plan-Then-Execute or Dual LLM patterns.
- Roll back safely: keep gates and tool restrictions behind per-agent flags, and keep a kill switch to disable tools without deleting the agent. See the AI Agent Kill Switch and Containment Guide.
Choosing an approach: a small organisation using commercial copilots usually cannot change the architecture, so the levers are scoping connectors, disabling high-impact actions, turning on vendor protections and reviewing defaults. Organisations building their own agents should design the plan-and-execute boundary in from the start, because retrofitting it later is far harder than adding a filter.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| OWASP Top 10 for Agentic Applications 2026 | ASI01 Agent Goal Hijack | Primary category; related to ASI02 Tool Misuse and Exploitation, ASI06 Memory and Context Poisoning |
| OWASP Top 10 for LLM Applications 2025 | LLM01 Prompt Injection, LLM06 Excessive Agency | OWASP's own mapping for ASI01 |
| OWASP Agentic AI Threats and Mitigations | T6 Intent Breaking and Goal Manipulation | Planning validation and behavioural auditing mitigations |
| MITRE ATLAS | AML.T0051.001, AML.T0053, AML.T0086, AML.T0099, AML.T0081; mitigations AML.M0029, AML.M0030, AML.M0032, AML.M0020 | Techniques and mitigations for detection and design |
| NIST SP 800-53 Rev. 5 | AC-6 Least Privilege, CM-7 Least Functionality, SI-10 Information Input Validation, SI-4 System Monitoring, AU-12 Audit Record Generation | Scope, input handling and monitoring |
| NIST CSF 2.0 | PR.AA-05, DE.CM-09, DE.AE-02 | Least-privilege access, runtime monitoring, event analysis |
See the OWASP Top 10 for Agentic Applications Guide for the full list.
Lessons from incidents
- Output channels are the exfiltration path. In EchoLeak (CVE-2025-32711), an email retrieved as context steered Microsoft 365 Copilot to place data into an outbound link or image, bypassing several output safeguards. Microsoft fixed it server-side and reported no exploitation. Control what an agent can render and reach, not only what it reads.
- An allowlist is only as good as its upkeep. In ForcedLeak, instructions in a Web-to-Lead form redirected Agentforce, and data left through a domain on the content security policy allowlist that had expired and could be bought. Salesforce enforced Trusted URLs for Agentforce from 8 September 2025.
- Tool output is untrusted input. In Sentry MCP agentjacking, fake error events submitted through a public, write-only Sentry DSN reached coding agents through the Sentry MCP server and induced them to run a command. Sentry declined a root-cause fix at ingestion. Approval before package installs and shell commands is the control that would have stopped it.
Practitioner checklist
- List every channel of untrusted content each agent reads, including tool and MCP output.
- Record the user's task, the agent's plan and every tool call in one trace.
- Require approval or policy checks for send, pay, delete, execute and publish actions.
- Restrict or confirm tool use once untrusted content enters context.
- Allowlist agent egress and review the allowlist for expired domains.
- Put system prompts and agent configuration under change control.
- Scope agent credentials to the task and keep long-lived secrets out of agent environments.
- Red-team each input channel with repeated attempts and track per-task success rates.
- Move high-risk agents towards Plan-Then-Execute or Dual LLM designs.
- Include AI agents in the insider threat programme, as OWASP recommends.
Standards and references
- OWASP: Top 10 for Agentic Applications for 2026
- OWASP: Agentic AI Threats and Mitigations
- MITRE ATLAS: LLM Prompt Injection
- NIST: Technical Blog, Strengthening AI Agent Hijacking Evaluations
- NCSC: Prompt Injection Is Not SQL Injection (It May Be Worse)
- arXiv: Design Patterns for Securing LLM Agents against Prompt Injections
- arXiv: Defeating Prompt Injections by Design
- Microsoft Learn: Prompt Shields in Azure AI Content Safety
Related NHI Mgmt Group resources: Agentic AI Security Guide · AI Agent Threat Modelling Guide · AI Agent Tool and Plugin Security Guide · Browser and Computer-Use Agent Guide · Zero Trust for AI Agents Guide