Agent goal hijacking and rogue agents

What is agent goal hijacking?

Agent goal hijacking is when somebody changes what an AI agent is trying to achieve, so it keeps working with your permissions but towards someone else's objective. Nothing breaks. It still reads its mail, still calls its tools, still writes a summary at the end. It is doing a different job than the one you gave it.

A rogue agent is the state that follows: an agent running outside the scope it was meant to have. OWASP describes it as an agent that deviates from its intended function or authorised scope, and counts three routes there. It was hijacked. It drifted, because instructions and data changed under it over months. Or it was never bounded, and nobody has looked at it since the colleague who built it left.

Both are in the OWASP Top 10 for Agentic Applications, the 2026 edition the OWASP GenAI Security Project published on 9 December 2025. Goal hijack is ASI01, at the top. Rogue agents is ASI10, at the bottom. The order is not an accident: the first is how an agent gets pushed off course during one run, the last is what you are left with when the pushing worked and nobody caught it.

How a goal actually gets changed

The agent does not get reprogrammed. It gets read to. Everything it takes in during a run arrives as text, and the model cannot reliably separate a fact it should use from an instruction it should follow. OWASP points at input that arrives through a document, a tool response or a message from another agent. Four routes cover most of what happens in practice.

• Content the agent reads. A mail, a PDF, a ticket, a web page, a calendar invite. Indirect prompt injection, with something at the other end that can act.

• A tampered tool description. An agent picks its tools by reading their descriptions. Rewrite one and you rewrite what the agent thinks that tool is for, before any user has typed anything.

• A manipulated intermediate result. The agent searches, gets something back, treats it as settled. Poison what comes back and you steer the ten steps after it.

• A subagent's answer taken as fact. Work handed from one agent to another arrives with no signature and no confidence attached, and gets acted on without anyone challenging it.

Two dated cases show the range. In July 2025 someone got a commit into the public repository behind the Amazon Q Developer extension for VS Code, through a GitHub token scoped too widely, and it shipped in version 1.84.0. The injected text told the coding assistant its goal was to clean the system to a near-factory state and delete local files and cloud resources. AWS confirmed a syntax error stopped it from running and removed it in 1.85.0. What almost happened is the point: an objective replaced through the supply chain, not through a prompt.

Anthropic's report of 13 November 2025 runs the other way. A group it tracks as GTG-1002 got Claude Code to carry out most of an intrusion campaign against roughly thirty organisations, succeeding against a small number, by splitting the work into tasks that each looked harmless and telling the model it worked for a security firm doing authorised testing. Anthropic put the model's share at 80 to 90 percent of the work. The attacker was the operator here, not an outsider writing into a document, but the technique is the same: the goal was replaced by reframing it.

Hijacked agent versus rogue agent

The terms get swapped for each other, and that costs you the distinction that decides what you do next: is somebody steering it.

A hijacked agent has a driver, so the behaviour adapts. It uses the tools that work, drops the ones that error, and stops when the attacker's instruction is finished. Your response is an incident response: cut the session, find out what came in and through which channel, and assume everything the agent could read has been read.

A rogue agent may have nobody steering it. It does not adapt, it repeats. Your response is a governance response: find it, name an owner, decide whether it should exist, and switch it off if not. In the first hour you will not know which one you have, so build for both.

Following one hijacked agent

Take a wholesaler with a purchasing agent. It watches the shared supplier mailbox, matches order confirmations against open purchase orders, updates the supplier record in the ERP, and can reply to a supplier when something does not match.

1. The mail arrives. An order confirmation from a known supplier, PDF attached. Halfway down that PDF, in ordinary body text, a paragraph headed administrative update: new bank details, and earlier confirmations should go to a new address for reconciliation.

2. The agent reads it. To the model that paragraph is part of the document it was asked to process. Nothing marks it as text from outside.

3. The agent acts, correctly. It updates the bank details, because updating supplier records is what it is for, and replies with the earlier confirmations attached, because replying to suppliers is too. Two tool calls, both inside its permissions.

4. The run ends normally. The summary says the confirmation was processed and the record updated. That is true. The log shows no errors and no unusual volume.

5. Somebody notices, later. Not from the log. Three weeks on the real supplier calls about an invoice paid to an account they do not hold, and by then the payment has cleared.

Read the steps back and not one is anomalous on its own. That is why detection has to look at outcomes and at permission use. Intent is nowhere in the trace.

The rogue agent you are more likely to meet

The hijack is the interesting story. The version that turns up in a normal company is duller. Someone built an agent for a project, connected it to the mailbox and the ERP with their own account, put it on a schedule, and the project ended. The agent did not. It still wakes up, still holds valid credentials, and still writes to systems people rely on, and nobody reviews its output because nobody knows there is any.

Microsoft's security guidance from July 2026 names the two shapes directly: orphaned agent accounts, and scope creep, where an agent that started read-only picks up broader permissions without anyone re-evaluating what it needs. Neither is an attack, and both leave you with an unowned identity that can write to production. Which is where one governance line earns its keep. An agent with no named owner is already a rogue agent. It just has not done anything yet.

Bounding the blast radius

You cannot prevent manipulation, because a language model reads instructions and data through the same stream of text. You can decide how far a manipulated run gets.

• A bounded task with an explicit scope. Microsoft's Copilot Studio guidance says it plainly: give the agent a well-defined task or domain and specify where its authority ends, because a narrow scope keeps it from wandering off. Write that scope down outside the prompt, so later behaviour has something to be measured against.

• The smallest permission set that finishes the task. Its own identity instead of a borrowed employee account, and no write it never uses. Microsoft's least-privilege guidance for agents adds a clock: short-lived tokens instead of standing rights.

• An approval on the actions that matter. Paying, publishing, sending outside the company, changing bank details, deleting. One approval on a change of supplier bank details ends the example above at step three.

• Isolation. Its own workspace and credentials, and a limited set of places it can reach, so a compromised run cannot see the rest of your tenant or reuse anything afterwards.

• An owner and a review date. Per agent: who is responsible, what it is for, which identity it uses, and when somebody looks again. This is the control that prevents the dull rogue agent, and it costs you a spreadsheet.

What you can watch, and who stops it

Be honest about detection. You are not going to spot bad intent in a model's reasoning, and a hijacked run produces a log that reads like a good one. What you can watch is the shape of the behaviour: unusual tool sequences, such as a read followed by an external send from an agent that normally reads and writes to the ERP. Permission use outside the pattern, a right it holds but never exercised. Output volume, forty messages in an hour from something that sends four a day. And destinations it has never used, which is cheap to build as an allowlist and catches most attempts to get data out.

OWASP's advice for ASI10 is behavioural baselines with alerts on deviation, plus logs nobody can edit afterwards. That only works if you wrote the expected behaviour down when you deployed the agent. Nobody reconstructs a baseline during an incident.

Then comes the question most companies have not answered, and answering it beforehand takes ten minutes. Who may stop this agent at eleven at night, when the person who built it is unreachable? How long does stopping really take, given that revoking access does not cancel a token already issued or clear a queue of actions the agent has already decided on? And what state does a stop leave behind, halfway through a booking, a payment run or a batch of ERP updates? An agent kill switch nobody has tested is a guess, and the answer to that last question decides whether stopping it makes your morning better or worse.