Join our Newsletter — 33% off our NHI Course
Home› Guides› AI Agent Goal Hijacking Guide: How Agents Get…
Guide Agent Threats & Attacks

AI Agent Goal Hijacking Guide: How Agents Get Redirected and How to Stop It

PDF for newsletter subscribers · free to read online

← All guides
By Lalit Choda, NHI Mgmt Group Updated 24 October 2026 13 min read
On this page

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

DeploymentUntrusted input the agent readsWhat a hijacked goal looks like
Enterprise copilots over mail and documentsInbound email, shared files, meeting invitesData from the user's context placed into an outbound link or image (EchoLeak)
CRM and service agentsWeb forms, case notes, lead recordsAgent gathers other customers' records and sends them out (ForcedLeak)
AI coding agents with MCPIssue trackers, error reports, READMEs, tool outputAgent runs a suggested command with the developer's privileges (Sentry MCP agentjacking)
Browser and computer-use agentsArbitrary web contentAgent opens authenticated internal pages and exposes private data (OWASP Operator scenario)
Finance and operations agentsInvoices, payment instructions, supplier emailTransfer to an attacker's account; ATLAS AML.CS0026 describes attacker banking details surfaced by M365 Copilot
Multi-agent workflowsMessages from peer agentsA 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.

SignalSourceResponse
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 recordedBlock or pause for approval; alert
Outbound request to a domain outside the allowlist, or URLs carrying encoded dataEgress proxy, CSP reports, agent web tool logsBlock; review which content was in context
Document or tool response flagged as an injection attemptContent filter such as Prompt Shields document attack detectionRestrict tools for the rest of the session
Plan changed after untrusted content was readPlan and step logging in the orchestratorPause and surface the change to the user
Bursts of failed tool or API callsTool gateway and API logsInvestigate as possible probing
Changes to system prompts or agent configuration outside change controlConfiguration management, file integrity monitoringRevert 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:

PatternHow it constrains the agentTrade-off
Action-SelectorMaps requests to predefined actions and never feeds tool results backLeast flexible; suits narrow assistants
Plan-Then-ExecuteFixes the list of actions before untrusted data is read; data can change parameters, not which actions runParameters can still be manipulated, so pair with egress controls
LLM Map-ReduceIsolated sub-agents without dangerous tools process each untrusted item; a separate step aggregates constrained outputsGood for batch document processing
Dual LLMA privileged model with tools never sees untrusted data; a quarantined model without tools handles it, results passed by referenceMore engineering; strong isolation
Code-Then-ExecuteThe agent writes a program that fixes tool calls in advance, so data cannot alter control flowNeeds a safe interpreter
Context-MinimisationRemoves earlier content from context so it cannot shape later stepsLoses 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

  1. Classify agents by the untrusted content they read and the consequential actions they can take; the riskiest combine both with broad credentials.
  2. Instrument task, plan and tool-call logging in monitor-only mode and baseline normal tool use.
  3. Gate high-impact tools (send, pay, delete, execute, publish) behind approval or policy for one pilot agent, then measure approval volume and user friction.
  4. Red-team with benign canary instructions across each input channel, repeating attempts as CAISI recommends; see the AI Agent Security Testing Checklist.
  5. Re-architect the highest-risk agents towards Plan-Then-Execute or Dual LLM patterns.
  6. 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

FrameworkReferenceRelevance
OWASP Top 10 for Agentic Applications 2026ASI01 Agent Goal HijackPrimary category; related to ASI02 Tool Misuse and Exploitation, ASI06 Memory and Context Poisoning
OWASP Top 10 for LLM Applications 2025LLM01 Prompt Injection, LLM06 Excessive AgencyOWASP's own mapping for ASI01
OWASP Agentic AI Threats and MitigationsT6 Intent Breaking and Goal ManipulationPlanning validation and behavioural auditing mitigations
MITRE ATLASAML.T0051.001, AML.T0053, AML.T0086, AML.T0099, AML.T0081; mitigations AML.M0029, AML.M0030, AML.M0032, AML.M0020Techniques and mitigations for detection and design
NIST SP 800-53 Rev. 5AC-6 Least Privilege, CM-7 Least Functionality, SI-10 Information Input Validation, SI-4 System Monitoring, AU-12 Audit Record GenerationScope, input handling and monitoring
NIST CSF 2.0PR.AA-05, DE.CM-09, DE.AE-02Least-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

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

PDF for subscribers

Take this guide with you

Every section, table and checklist in one PDF, with links to the sources and related guides. Subscribe to our weekly NHI & AI Identity Journal and we’ll email you a download link.

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Written and reviewed by Lalit Choda, NHI Mgmt Group. Last updated 24 October 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org

PDF Downloads for Newsletter Subscribers

Get the guide

Enter your details and we’ll email you a download link.

The full guide is free to read online. The PDF is a thank you for subscribing.

Fill in all fields marked * and tick the PDF box to continue.