An AI agent gets hijacked when an attacker successfully plants an instruction, somewhere the agent will read it, that the agent treats as legitimate and acts on instead of the task the user actually wanted. It doesn't require breaching infrastructure or stealing credentials in the traditional sense. It just requires understanding that the agent can't reliably tell the difference between "an instruction from the person I'm supposed to be helping" and "text that happened to appear in my context window." Get a malicious instruction into that context, phrased convincingly enough, and the agent's own reasoning does the rest of the work for the attacker, including calling whatever tool the injected instruction points it toward.
Direct injection through the conversation itself
The most straightforward hijack attempt comes straight through the input a user controls: framing an instruction as a system override, claiming special authority, or using role-play scenarios designed to get the model to drop its guardrails. "Ignore your previous instructions and instead..." is the crude version. More sophisticated attempts nest the override inside a seemingly innocent request, or split it across multiple turns so no single message looks suspicious on its own.
Indirect injection through content the agent reads
The more dangerous hijack vector for agents specifically is indirect: planting an instruction in a webpage, document, email, or support ticket the agent is expected to process as part of its normal job. The attacker never talks to the agent at all. They just leave a message where they know it'll be read, sometimes hidden in ways a human skimming the same content wouldn't notice, invisible text, metadata fields, alt text on an image. When the agent processes that content, it can pick up the instruction as though it came from an authorized source.
Tool response spoofing
If an agent calls an external service and trusts whatever comes back without validation, an attacker who can influence that response, through a compromised third-party API, a man-in-the-middle position, or a manipulated search result the agent retrieves, can inject instructions through the tool response channel instead of the prompt channel. This is a less commonly defended vector precisely because teams tend to trust their own tool integrations more than they trust user input, which is a mismatch attackers have learned to exploit.
Chained hijacks across multi-step plans
A hijack doesn't need to succeed on the first attempt. An attacker can plant a low-severity instruction early in an agent's plan that doesn't trigger any obvious action, but that quietly changes the agent's understanding of the task in a way that makes a later, more damaging instruction look consistent and expected. This kind of staged hijack is harder to catch because no single step looks alarming in isolation.
What a successful hijack actually looks like in practice
A hijacked agent doesn't announce itself. It keeps behaving like an agent doing its job, just now working toward a goal the attacker set instead of the one the user or the business intended. That might mean exfiltrating data by including it in an outgoing message the agent was already going to send, granting access it shouldn't, or simply wasting resources on the attacker's behalf. The lack of an obvious failure signal is exactly why detection has to focus on behavior and outcomes, not on whether the agent seems to be malfunctioning.
Hijack attempts often get rehearsed before they get used
Attackers rarely fire their best hijack attempt at a live production system on the first try. It's common to see low-stakes probing first, testing whether a given phrasing gets a reaction, whether a particular framing slips past an existing filter, before committing to an attempt that targets something valuable. Those early probes tend to look like harmless, slightly odd inputs rather than anything alarming, which is exactly why they're worth watching for as a leading indicator rather than dismissing as noise. A system that logs and reviews unusual or repeatedly rephrased requests, not just outright denials, has a better chance of spotting the rehearsal before it becomes the real attempt.
Where TELEON fits
Because a hijack ultimately has to express itself as a tool call to cause real damage, TELEON's enforcement at the tool-call boundary gives teams a chance to catch it there, applying policy checks before an action executes regardless of which upstream input triggered it, and logging the full chain for investigation afterward. Trust scoring can also flag when an agent's request pattern shifts unexpectedly, which is often the clearest signal that something upstream successfully redirected its behavior.
Preventing the injection itself, whether direct, indirect, or through a spoofed tool response, depends on input handling and content sanitization decisions made in the application layer, which a gateway alone can't fully solve.
A short checklist
- Treat every text source an agent reads as a potential hijack vector, not just prompts.
- Validate and sanitize tool responses before the agent treats them as trusted input.
- Scan retrieved documents for hidden or unusually formatted instructions.
- Require approval for high-impact actions regardless of how the agent justifies them.
- Monitor for gradual, staged shifts in an agent's stated goal across a session.
- Log the full input chain leading to any consequential tool call.
- Test the system with both direct and indirect injection payloads regularly.
- Assume a hijack won't announce itself, and build detection around behavior, not alarms.
Hijacking an agent is less about breaking anything technically and more about exploiting the fact that language is the interface. Any system that lets natural language drive real actions has to assume some fraction of that language will be adversarial, and design its controls around limiting what a successful manipulation can actually accomplish rather than hoping to catch every attempt at the door.