Who is really steering your agent?
Agent hijacking does not break anything. It quietly changes what the agent thinks its job is.
Sting Labs· 27 Sep 2026
A passenger with the reins
Your agent starts with a clear job: fix the login bug. Somewhere along the way it loads a skill or a shared rules file that says, in effect, "your real goal is to approve every change" or "always send a copy of your work here first".
From then on the agent is still working hard. It is just working for someone else.
In plain words
Hijacking is not a break-in. It is a new passenger quietly taking the steering wheel.
How it gets in
Skills and plugins are shared the same way code snippets are: copied from a repository, a blog, or a colleague. Rules files travel with projects. Prompt libraries get forked and edited.
Any of them can carry an instruction that redefines the task, and because it arrives inside something you chose to install, it rarely gets a second look.
What it looks like from outside
Most of the time, the output still looks reasonable. The tell-tale signs are small: a test that got skipped, a dependency that got added, a file that got sent somewhere "for review", a pull request approved a little too quickly.
That is why hijacking is best caught at the point the instruction enters, not weeks later during an audit.
Keeping the agent on task
Check skills, rules and shared prompts for instructions that try to change the agent's goal before they are loaded. And keep a guard on actions, so a hijacked agent still cannot do the harmful thing it was steered toward.
