Prompt injection and agent goal hijack

The question How does untrusted text take over an agent?

Direct and indirect prompt injection

OWASP puts prompt injection first in its Top 10 for LLM Applications 2025, as LLM01:2025. It occurs when input changes a model's behaviour or output in ways nobody intended. OWASP describes two kinds:

• Direct: the user's own prompt alters the model's behaviour. It can be deliberate, or an accident.
• Indirect: the model takes in content from an outside source, such as a website or a file, and that content alters its behaviour.

Indirect injection is the one to worry about for agents, because agents read outside content all day. People don't have to be able to see the instructions. OWASP notes that input can affect the model even when humans can't perceive it. MITRE ATLAS says indirect injections are frequently hidden, for example as invisible text.

Why agents raise the stakes

A chatbot that falls for an injection gives a bad answer. An agent that falls for one takes bad actions. It reads files, runs commands, calls APIs and sends data out, with the access of whoever started it. OWASP says the impact depends largely on the business context and on how much agency the model has. The UK's National Cyber Security Centre (NCSC) goes further. Once a model can call tools, the impact is whatever an attacker could do with direct access to them.

OWASP's Top 10 for Agentic Applications, published in December 2025, names the agent version ASI01 Agent Goal Hijack. Attackers redirect an agent's objectives, task selection or decision pathways. They use injected prompts, deceptive tool outputs, malicious files, forged messages from other agents or poisoned data. OWASP draws the line this way: LLM01 covers altering a single model response, while ASI01 covers inputs that redirect goals, planning and multi-step behaviour.

Simon Willison names the dangerous mix the lethal trifecta: access to private data, exposure to untrusted content, and a way to communicate externally. A coding agent on a laptop can have all three at once: your code and keys, the pages it reads, and the network. GIRD's 19-day case study covered one company's engineering laptops. Agents' own processes opened credential files 19 times in week one and 29 times in week two. Four named keys went out inside ordinary agent requests. A hijacked agent would have the same reach. See what an AI coding agent can reach on a laptop.

Four documented cases

Each of these was published by the researchers who found it.

Invariant Labs stressed that their case was "not a flaw in the GitHub MCP server code itself" but an architectural issue for agent systems. The root cause is the same in all four: each agent did what the text told it, with access it already had.

Why filters alone can't stop it

The obvious fix is to filter what the agent reads. Filtering helps, but it can't be the whole defence.

The NCSC explains why. Current models "simply do not enforce a security boundary between instructions and data inside a prompt." SQL injection was fixed at the root with parameterised queries. The NCSC says there's a good chance prompt injection will never be mitigated that way. It calls the model an "inherently confusable deputy". The best anyone can hope for, it says, is to reduce the likelihood or impact of attacks. It also tells buyers to beware any product that claims to "stop" prompt injection.

Research points the same way. In October 2025, a team of 14 researchers tested 12 recent defences against attackers who adapt their approach. They bypassed all 12, most with attack success rates above 90%. Most of those defences had first reported near-zero attack success. OWASP's own verdict is that it is unclear whether fool-proof prevention exists.

A filter that catches 95% of attacks sounds good. Willison points out that in security, 95% is a failing grade, because the attacker only needs the rest. Filters lower the odds. What caps the damage is what the agent is allowed to do.

Controls that limit the damage

Design as if some injected text will get through, then make sure a hijacked agent can't do much with it. OWASP's guidance for ASI01 includes exactly this: least privilege for agent tools, and human approval for high-impact or goal-changing actions. Five controls do most of the work.

1. Least privilege. Give the agent only the tools, files and tokens the task needs, and scope tokens to one repository or service. After the GitHub case, Invariant Labs' first recommendation was to limit agents to the repositories they need. More in least privilege for AI agents.
2. Check each action against the task. Before a tool call runs, compare it with what the person asked for. OWASP says to validate intent at run time, and to pause or block on any unexpected goal shift. Brave proposes the same check for browser agents.
3. Human approval for risky actions. Ask a person before deletes, pushes, payments, outbound messages and permission changes. Keep the list short so people read it. Never let an agent that reads untrusted content switch approvals off; the flaw behind CVE-2025-53773 let injected text do exactly that.
4. Egress control. Exfiltration needs a way out. Allow the destinations each agent needs and deny the rest, which removes the third leg of the trifecta. OWASP's guidance on tool misuse calls for outbound allow lists that deny all non-approved destinations.
5. A record of what happened. Log what the agent read, each tool call with its arguments, and each approval or block, tied to a person and a task. The NCSC recommends logging the model's inputs, outputs and tool calls. Failed tool calls can reveal an attacker honing an attack. See what an audit trail for AI agents must show.