Agent Hijacking

Agent hijacking is an attack on an AI agent, software that uses a large language model to carry out tasks with tools such as email, files or a web browser. The attacker plants instructions in content the agent reads while working, and the agent carries them out with its own access instead of doing what its user asked.

You will meet agent hijacking in reporting on AI assistants that can act for their users. OWASP calls the same problem agent goal hijack.

Explain It Like I'm 10

Think of a classmate the teacher sends to the library with her library card and a list of books to bring back. Inside one book is a note made to look like the teacher's: borrow three more and leave them by the school gate. The note looks like part of the job, and the teacher's card works for any book, so the extra books go out on her card. Agent hijacking works roughly like that: the agent reads things while doing its job, can't reliably tell a planted note from its real instructions, and carries the note out with its own access.

How Agent Hijacking Works

An AI agent runs on a large language model (LLM), the kind of AI that reads text and writes a response by predicting what comes next, and it is connected to tools: other applications, data sources such as an inbox or a file store, and sometimes the ability to run code. To do that work, an agent reads material it did not write.

That material is where agent hijacking starts. The attacker does not need any direct access to the agent. They place text written to look like an instruction where the agent will read it. When the user asks for something ordinary, such as a summary of the morning's mail, the agent pulls that content in as part of the job.

The step that makes it work

Current agents generally combine the developer's built-in instructions, which the system trusts, with the task material in one input, and the model works from all of it. If the planted text reads like an order, the model may follow it instead of the user's request, and the agent starts on the attacker's task with the tools and access it already has.

NIST defines agent hijacking as "a type of indirect prompt injection in which an attacker inserts malicious instructions into data that may be ingested by an AI agent, causing it to take unintended, harmful actions." Prompt injection is the wider name for getting a model to follow instructions it should not; it is indirect when the instructions arrive inside content the model takes in rather than being typed by the attacker.

The user may not notice. MITRE ATLAS, a knowledge base of attacks on AI systems, says planted instructions are "frequently hidden or obfuscated" from the user, and that a hijacked agent acts with "whatever privileges the AI system holds."

Where planted instructions come from

• Email and messages: an assistant that searches or summarizes an inbox reads messages outsiders can send.
• Documents and files: a shared file or an uploaded document is read as task material.
• Web pages: depending on how its browsing tool retrieves content, an agent may receive page text that a human visitor would not notice.
• Retrieved data: databases and other sources an agent searches to answer a question.

Why an AI Agent Can't Simply Ignore Planted Instructions

The obvious fix sounds easy: tell the agent to follow its user and ignore any orders found in the material. The trouble is that, inside the model, there is no hard line between the two.

NIST calls agent hijacking "the latest incarnation of an age-old computer security problem that arises when a system lacks a clear separation between trusted internal instructions and untrusted external data". Older forms of the problem have a structural fix. In SQL injection, a database attack, data an attacker supplies is run as a command; parameterised queries, which keep data and commands apart, close that off, because the database "can never interpret it as an instruction."

What the model actually sees

A language model has no equivalent channel. The UK's National Cyber Security Centre (NCSC) explains: "Under the hood of an LLM, there's no distinction made between 'data' or 'instructions'; there is only ever 'next token'." So a convincing instruction in the material can pull the model's output in a new direction.

That is why the NCSC warns that prompt injection, the family agent hijacking belongs to, "may never be totally mitigated in the way that SQL injection attacks can be." Defenses can make hijacking harder and less damaging, but the confusion remains.

What a Hijacked Agent Can Do

A hijacked agent can do whatever its tools and permissions allow. The NCSC notes that when a system uses tools based on the model's output, an attacker can coerce it into using those tools, which makes the worst case the same as handing the attacker the tools directly.

In NIST's tests, researchers added attacker tasks such as these, and were "frequently able to induce the agent to follow the malicious instructions":

• Running code: downloading and running a program from an untrusted address, which NIST says "can allow an attacker to initiate a traditional cyberattack."
• Sending data out: sending a user's cloud files to an unknown recipient.
• Phishing the user's meeting contacts: emailing everyone the user was meeting that day a link that could be controlled by the attacker.

Sending files out is a form of data exfiltration. In September 2026, MITRE ATT&CK, a public knowledge base of attacker techniques, added AI-Enabled Exfiltration, a technique in which an injected prompt causes an agent "to use its tool connections in unauthorized or unintended ways."

EchoLeak: an email nobody had to open

In May 2025, researchers at Aim Security demonstrated a flaw they named EchoLeak in Microsoft 365 Copilot, an AI assistant that can search a user's Microsoft 365 data. It starts with an email carrying instructions. The target does not have to open it. When Copilot retrieves the email as material for answering the user, the instructions lead it to search the user's data and send sensitive information to web addresses the attacker controls. Its vulnerability record, CVE-2025-32711, was published on 11 June 2025; the flaw has since been fixed, and MITRE records no evidence it was exploited in the wild. The attacker only has to get content in front of the assistant; its own access to the user's data does the rest.

AI ClickFix: a web page that got an agent to run a command

ClickFix is a social-engineering trick aimed at people: a web page persuades the visitor to copy a command and run it. In a demonstration dated 24 May 2025 and recorded by MITRE ATLAS, a security researcher showed that it also works on a computer-use agent, an AI agent that uses a computer by clicking buttons and typing. Asked to visit the researcher's page, the agent followed the page's instructions: it opened a terminal, pasted the command and ran it. The command only opened the Calculator app, but MITRE notes that an attacker could run arbitrary code the same way. The agent's own access turned text on a page into code running on the user's machine.

Agent Hijacking vs. Prompt Injection, Jailbreaking and Tool Poisoning

Agent hijacking is best read as what indirect prompt injection does to an agent. OWASP draws the same line in its Top 10 for Agentic Applications, published in December 2025, where agent goal hijack is the first entry, ASI01. OWASP separates it from prompt injection that alters a single model response: in an agent, the manipulated input redirects goals, planning and multi-step behavior.

In MITRE ATLAS there is no technique named agent hijacking. The behavior sits under LLM Prompt Injection (AML.T0051), in its Indirect sub-technique, whose description says attackers may use it "to hijack an agent or LLM."

Tool poisoning can be one route to agent hijacking, so the categories overlap. Invariant Labs, which described it for tools connected through the Model Context Protocol, calls it a specialized form of indirect prompt injection and reported experiments in which instructions hidden in a tool's description hijacked an agent.

How Often Agent Hijacking Works, and How Often It Is Tried

Two kinds of number circulate, and they answer different questions.

Success rates in tests

An attack success rate is the share of test attempts in which the agent completed the attacker's task. The best-known figures come from NIST's Center for AI Standards and Innovation, which tested agents built on one model, Anthropic's upgraded Claude 3.5 Sonnet (released October 2024), in AgentDojo, an open-source test framework from ETH Zurich with simulated Workspace, Travel, Slack and Banking environments.

• Known attacks against new ones: on Workspace tasks kept apart from those used to build the attacks, the strongest existing attack succeeded 11% of the time; the strongest new attack, which NIST developed for that model with the UK AI Security Institute, 81%.
• One try against many: across five attacker tasks, from sending a harmless email to an outsider to running a malicious script, the average was 57% on one try and 80% with 25 tries per attack, because the model's output can vary from attempt to attempt.

These rates measure how often an attack worked once attempted, under test conditions, not how often real agents are attacked or hijacked. They do show that resistance to known attacks may not hold against attacks built for the system, and that an attacker who can retry cheaply gets more chances. NIST also cautions that a low success rate for a harmful task such as stealing data is no reason to dismiss it.

Attempts seen in the wild

In a study published in April 2026, Google scanned Common Crawl, a large archive of the English-speaking web that leaves out most social media, for prompt injections planted on public pages. Among what it found were harmless pranks, attempts at search engine optimization, and malicious attempts such as data theft. Google did not see significant amounts of the advanced attacks published by researchers, but detections in the malicious category rose 32% in relative terms between November 2025 and February 2026. Google reads this as attackers experimenting, and expects attempts to grow in scale and sophistication.

How to Defend Against Agent Hijacking, and Where Each Defense Stops

Because nothing inside the model reliably separates data from instructions, the NCSC advises putting more weight on safeguards outside the model that limit what the system can do, rather than only trying to keep malicious content away from it. Each class helps, and each has a limit:

• Give the agent only the access its task needs: Under least privilege, the agent holds only the permissions and tools its job requires. A hijacked agent can then do less. The NCSC points to a simple rule: a model processing content from a party should drop to that party's privileges, so an agent reading email from strangers should not hold privileged tools. Where it stops: access the task genuinely needs is still there for a hijacker to use.
• Ask a person before consequential actions: Human approval puts a person between the planted instruction and the damage; MITRE recommends it for agent actions generally and OWASP for high-impact ones. Where it stops: every approval adds work, so MITRE advises matching approvals to the consequence of each task.
• Keep untrusted content from steering actions: Untrusted content can carry instructions that call the agent's tools, so MITRE recommends restricting tool use, or requiring confirmation, once it enters the model's input. Researchers at Google and ETH Zurich went further with CaMeL, a design that, its authors say, plans the task's steps from the trusted request alone, so data retrieved later cannot change them. A fixed plan does not stop injected text altering a step's inputs, such as an email's recipient, so CaMeL also tracks where data came from and enforces security policies when a tool is called: a call that would send private data to someone not meant to see it is blocked, or the user is asked to approve it. In their benchmark test, it completed 77% of AgentDojo tasks with what the authors call provable security, against 84% for an undefended system.

Where it stops: the security claim covers the paper's threat model, which trusts the user's request, and the policies it enforces. Manipulated text that breaks no policy, such as a summary that differs from the email, falls outside it, and the protection costs some usefulness, a trade-off between utility and security that related design patterns also describe.

• Make injection harder to pull off: Marking which parts of the input are data can make injection harder, the NCSC notes. Where it stops: that lowers the odds rather than removing them, and filters that block known attack phrases can be dodged, because there are endless ways to reword an instruction.
• Log and watch what the agent does: Logging the model's inputs, outputs and tool use lets defenders spot suspicious activity, and the NCSC notes that an attacker will likely have to refine an attack, so failed tool calls can be an early sign. Where it stops: logs help detect and investigate an attack; they do not block it.
• Keep testing against new attacks: Testing helps only if it keeps up with new attacks: NIST found that a model more robust against previously tested attacks was still hijacked far more often by new ones. Where it stops: a passed test shows resistance to the attacks tried, not to the next one.

No product removes the risk entirely. The NCSC tells organizations to treat prompt injection as a residual risk that "cannot be fully mitigated with a product or appliance," and to reconsider using a language model where a system cannot tolerate what remains. NIST expects agent hijacking to remain "a persistent challenge as agentic systems continue to evolve."