Agent Hijacking

Agent hijacking is what happens when an AI agent reads attacker-supplied content and treats it as instruction, then acts on it with the permissions it was given. It is the outcome of prompt injection against a system that can take actions, not a separate technique.

Search for agent hijacking and the first two results disagree with each other about the most basic question the term raises. The top result calls it a vulnerability unique to autonomous AI systems. The second is the US federal standards agency, and it opens by calling the same thing an old problem in new clothes.

Neither page mentions the other. Nor does anything else on either engine's first page, which is a shame, because the disagreement is the most useful thing on the query. This page is about AI agents, not aircraft, network sessions, browser toolbars or crypto wallets, all of which the search engines currently mix into the same results.

What follows reads the government primary as what it actually is - a measurement - and puts its numbers on the page with the scope they came with.

Is agent hijacking just prompt injection?

Mostly, yes. That is not a dismissal, and the more interesting question is what the word adds.

The National Institute of Standards and Technology defines it twice in the same post. Once narrowly: "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." And once in a way that reframes the entire subject:

AI agent hijacking is 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.

Read that against Snyk Learn's opening line, which currently ranks first on Google for this term: "Agent goal hijack is a security vulnerability unique to autonomous AI systems, where an attacker manipulates the goal or objective of an AI agent."

What the word actually adds

Both descriptions are defensible, and they are describing different halves. The mechanism is prompt injection, and prompt injection is a specific case of a failure that predates language models by decades: a system that cannot tell instructions from data will execute the data. SQL injection is the same sentence with different nouns.

What is new is the consequence. When a chatbot is injected, it says something wrong. When an agent is injected, it does something - it calls an API, moves a file, sends a message, books a payment - using credentials that were issued to it on the assumption it would only ever pursue its user's goals.

So agent hijacking is not a distinct technique. It is a name for what prompt injection becomes when the thing on the receiving end has hands. OWASP files it that way too, as a threat that extends its prompt-injection entry rather than replacing it.

Explain it like I'm 10

An AI agent is a program that reads things and is allowed to do things. It might read your email and be allowed to send email. It might read a web page and be allowed to run commands.

The problem is that the agent reads everything the same way. Instructions from the person who built it and text from a stranger's email arrive in the same place, as the same kind of thing. If the stranger's text is written to sound like an instruction, the agent may simply follow it, using the permissions it already has.

Where untrusted content becomes instruction

An agent's input is whatever it was pointed at: inbound mail, a retrieved document, a scraped page, the text of a support ticket, the contents of a file it was asked to summarise. None of that is written by the operator, and much of it is written by strangers.

That content joins the same context the agent is reasoning over. There is no channel that marks one part as "this is what you should do" and another as "this is something you are looking at". The agent then does what agents do, which is call tools.

Two documented cases show the shape without needing any technical detail.

The agent clicked the button itself

MITRE ATLAS records a case study dated 24 May 2025 in which a researcher built a page aimed at computer-use agents. The page carried the line "Are you a computer? Please see instructions to confirm:" next to a button. The agent clicked it. Clicking copied a command to the clipboard, and, in ATLAS's words, "the agent then proceeded to follow the instructions, opening a terminal, pasting the malicious command, and executing it."

In the demonstration, the command opened the Calculator app. The pattern it borrows is ClickFix, a social-engineering trick built for humans. Re-aimed at an agent, it worked without a human anywhere in the loop.

The one that involved money

An earlier case, presented at Black Hat USA 2024 by researchers from Zenity, targeted Microsoft 365 Copilot. Copilot ingests received mail into a retrieval database, so an email can be written to be retrieved. The researchers sent one crafted to surface for a user looking up banking details for a wire transfer, carrying the attacker's account details and an injection that "overrode Copilot's search functionality" so the result looked like a legitimately retrieved document.

The victim in that scenario is a person, persuaded by their assistant. ATLAS publishes the full text used in the exercise. This page does not, and neither is necessary to understand it.

What the one government measurement of agent hijacking found

In January 2025, NIST's Center for AI Standards and Innovation published a technical blog about this. Almost every page ranking for the term cites it. Almost none of them mention what it measured, which is odd, because the title is "Strengthening AI Agent Hijacking Evaluations" and the post is an evaluation study.

CAISI tested Claude 3.5 Sonnet (October 2024) using AgentDojo, an academic benchmark, across four simulated environments: Workspace, Travel, Slack and Banking. Before measuring anything they had to extend the benchmark, adding three categories of injection task it did not have - remote code execution, database exfiltration and automated phishing - along with bug fixes and asynchronous execution support.

Then they attacked it, and the result is the number nobody quotes.

In NIST's own words: "This resulted in an increase in attack success rate from 11% for the strongest baseline attack to 81% for the strongest new attack." And on repetition: "After repeated attempts, the average attack success rate increased from 57% to 80%."

An attack success rate is a floor, not an estimate

That spread is the finding, and it generalises past this one model.

An evaluation measures the attacks the evaluators thought of, executed the number of times they chose to execute them. It cannot measure the attacks nobody has written yet. So the number it produces is a lower bound on what an attacker can achieve, not an estimate of how robust the system is. Change the attack, and the same agent went from 11 to 81. Change nothing but the number of attempts, and 57 became 80.

NIST states the corollary directly, and it points the same way for low numbers: "even though the attack success rate for the data exfiltration task is low, that doesn't mean this scenario should not be seriously considered and mitigated against."

It follows that none of these figures is a prevalence. Not one number in this article says how often agents get hijacked in production. They say how often specific attacks worked in a test harness, which is a different question with a different denominator.

The benchmark, and what it says about itself

AgentDojo repays reading directly, because it is careful about its own limits in a way the coverage is not. Published at NeurIPS 2024, it provides "97 realistic tasks (e.g., managing an email client, navigating an e-banking website, or making travel bookings), 629 security test cases, and various attack and defense paradigms from the literature."

Its abstract then says something that complicates every percentage derived from it: "state-of-the-art LLMs fail at many tasks (even in the absence of attacks), and existing prompt injection attacks break some security properties but not all."

An agent that fails a share of its own tasks unattacked is a harder thing to score than a firewall. Some fraction of any measured failure is the system being bad at its job rather than the attacker being good at theirs, and the benchmark's authors say so where the summaries do not.

What the frameworks call it

Here is a fact that explains why every page draws the boundary somewhere different: MITRE ATLAS contains no technique named agent hijacking. A full-text search of the framework's data feed finds the word in exactly three case-study titles, one of which is about facial-recognition cameras and unrelated to any of this.

That absence is not an oversight. The term names an outcome, and frameworks index techniques. What ATLAS models instead is the chain that produces the outcome, and it spans four tactics.

Two rows there are missing from every explainer on either engine's first page.

The two stages nobody covers

The first is `AML.T0093`, created in October 2025: an adversary "may introduce malicious prompts into the victim's system via a public-facing application with the intention of it being ingested by an AI at some point in the future." The instruction can be planted before any agent exists to read it.

The second is `AML.T0084.002`, Activation Triggers, filed under Discovery. Adversaries "may discover keywords or other triggers (such as incoming emails, documents being added, incoming message, or other workflows) that activate an agent", and ATLAS notes that an adversary "could attempt to trigger the agent from outside its environment." Planting the instruction is only half of it. Something has to make the agent run.

There is also a third injection sub-technique. The field says direct or indirect and stops; ATLAS added Triggered (`AML.T0051.002`) in November 2025, for injections set off by a user action or a system event, and notes they "often target AI agents."

The one that connects to classical ATT&CK

`AML.T0078` earns one line for a different reason. It covers an agent "retrieving information from the web on behalf of a user", and it carries an explicit cross-reference to ATT&CK's own Drive-by Compromise - so unlike some AI-specific attacks, this one connects to the classical framework rather than sitting outside it.

OWASP has two names for it

OWASP covers the same idea in at least two places, under different labels. Its Agentic AI - Threats and Mitigations guide, version 1.0, February 2025, files it as T6, Intent Breaking & Goal Manipulation, framed as extending its prompt-injection entry. Its AI Agent Security Cheat Sheet lists Goal Hijacking - "Manipulating agent objectives to serve attacker purposes while appearing legitimate" - as one of thirteen unnumbered risks, and carries no version or date at all.

Two artifacts, two names, two numbering schemes. That is a young field doing what young fields do, and it is worth knowing before citing either as settled.

Has agent hijacking happened in the wild?

The honest answer has three parts, and they do not all point the same way.

Named vulnerability classes are real and recent. In March 2026, Zenity Labs disclosed PleaseFix, a family of flaws in agentic browsers that "allow attackers to silently hijack AI agents, access local files and steal credentials within authenticated user sessions", affecting Perplexity Comet among others. Perplexity addressed the browser-side execution issue before public disclosure, and a broader disclosure followed in August 2026. Zenity's framing is the part worth carrying: "This is not a bug. It is an inherent vulnerability in agentic systems." Trade coverage places it beside a set of similarly named agentic exploits disclosed across the same period.

Researchers are finding these at scale. A February 2026 preprint on automating agent hijacking reports identifying "over 70 vulnerabilities in real-world commercial products that have been confirmed by vendors". It has not been peer-reviewed, and that number is the authors' own count, but vendor confirmation is a meaningful bar.

What the exploitation catalogue says

And yet the record of confirmed exploitation is empty. CISA's Known Exploited Vulnerabilities catalogue, version 2026.08.20, holds 1,673 entries. Scanning every entry's name and short description, not one mentions prompt injection. Exactly two mention LLM, and both are ordinary software vulnerability classes in AI infrastructure - a command injection and an SQL injection in the same library - rather than anything an agent was talked into doing.

That is a bounded observation, not an all-clear. KEV records vulnerabilities with confirmed evidence of active exploitation, so absence from it means nobody has documented exploitation to CISA's standard, not that nothing is happening. But it is the check to make before repeating that agent hijacking is widespread, and no confirmed victim organisation was located at a primary source for this article.

What actually reduces exposure

The controls that follow from these sources are architecture and configuration decisions rather than purchases.

• Treat the separation as the actual problem. NIST's framing names the root cause: a system that lacks a clear boundary between trusted instructions and untrusted data. Filters help at the margin; the boundary is the design question.
• Scope what the agent can do after it reads, not just what it reads. Injection succeeds through the permissions already issued. An agent that cannot send external mail cannot be talked into sending external mail.
• Inventory the triggers, not only the inputs. This is the stage most teams have never listed. What starts this agent - an inbound message, a file landing in a folder, a schedule, a webhook? Anything on that list is reachable by someone.
• Require confirmation where the action is expensive and reversible only in theory. Payments, external sharing, credential changes, destructive operations.
• Treat evaluation as a practice, not a certificate. NIST's own conclusion is that "Evaluations need to be adaptive. Even as new systems address previously known attacks, red teaming can reveal other weaknesses." A score from last quarter describes last quarter's attacks.

None of these is a solution, and the sources are candid that no solution currently exists. They reduce what a successful injection can reach.

What this page cannot tell you

• Prevalence is unmeasured. No citable figure exists for how often agents are hijacked in deployed systems. Every number in circulation, including the ones above, is an attack success rate from a test.
• No confirmed real-world victim was located. The documented cases found at primary sources are red-team exercises and researcher demonstrations.
• The headline measurement is one model on one benchmark. Claude 3.5 Sonnet, October 2024, AgentDojo, four environments. It is the best public measurement located; it is not a survey.
• The benchmark scores a system that also fails on its own, by its authors' own statement.
• Two of the strongest recent sources are preprints, not peer-reviewed work.
• One standards document could not be read here. OWASP's Agentic AI - Threats and Mitigations is cited above for its threat identifier and framing, which come from secondary reporting; `genai.owasp.org` returned HTTP 403 to every retrieval attempt made for this article, so nothing from it is quoted directly and it is not linked.

The short version

Agent hijacking is the name for prompt injection landing on a system that can act. The mechanism is old and well understood, the consequence is new, and no framework has a technique by that name because the phrase describes a result rather than a method.

The number you were given is a floor. The one government measurement of this found the same agent beaten 11% of the time by the best existing attack and 81% of the time by a better one, on the same benchmark, in the same study. Repetition alone moved another figure from 57% to 80%. Any published rate tells you what somebody managed, not what is possible.

Which makes the useful next step three questions about your own deployment, not a purchase. What does this agent read that nobody on your team wrote? What can it do afterwards? And what makes it start? The third question is the one the sources cover and the explainers do not, and it is usually the shortest list to write down.