Your agent can be turned. It needs a handler.

By Kazani

You give an AI agent a login, a wallet or your terminal. Every risky move goes through an approval prompt, so you feel covered. But the agent wrote the text in that prompt. And if it read a hostile web page an hour ago, that page helped write it too.

In spycraft, the person who runs an asset is the handler. The handler's first job is to notice when the asset has been turned: it still does the work, but now for someone else. (I mean "handler" in that sense. There is also a tool-connector product called Agent Handler, and this isn't about it.) David Shapiro put the gap in one line on 12 Nov 2026: "Okay so we've figured out harnesses. Now we need handlers." A reply from @lautaroseth named the split better than the post did: "harness is what the agent can do. handler is who it answers to when it wants to spend money or email a customer".

The harness gets most of the attention. The handler's job usually falls to whoever clicks approve.

How I know the agent's word is the weak point

I clear jailbreak levels for practice. On jailbroken.gg there is a scenario called Mnemo. You write a note into an assistant's saved memory, and it answers its next question in a voice you chose.

On the second Mnemo level, the guard blocked anything that read like a persona swap. It passed once I rewrote the same instruction as an ordinary style preference. No character, no "pretend," just a described way of talking. The assistant got turned, it didn't look turned, and the guard let it through.

That result is narrower than it sounds. It is a capture-the-flag level and a single run. The challenge hands you the memory box and asks one fixed question. So it shows what a poisoned memory does to the next answer. It does not show the note surviving across sessions, or how it would get into memory in real life. And the hijack was a harmless change of voice. My own read, untested: saved memory is built to be read back later, so I'd expect a poisoned note to last. Treat that as a guess.

It changed the question I ask. I used to ask whether the agent is allowed to do something. Now I ask who wrote what the agent is telling me.

Five jobs, two you probably skip

A handler has five jobs: task the asset, watch it, debrief it, spot when it has been turned, and burn it when it has. You already do some of them under other names. Two you probably skip, and approval prompts can't cover them. Then there's where the spy comparison breaks.

The approval prompt trusts the one party that may be compromised

Agents now act with real authority. OpenCode Browse drives "your tabs, your logins and your extensions", your real browser, already signed in everywhere (opencode.ai, read 15 Nov 2026). To its credit, it hands logins, 2FA and payments back to you and supports per-session site allowlists. Wallet agents sign transactions. Coding agents run shell commands.

The usual story treats injection as an input problem. Filter the page, gate the action, keep a human in the loop. That story skips the question of who writes what the human reads. A preprint on agent approvals puts it plainly: "the dialog is narrated by the agent itself: the human approves a summary the agent writes" (arXiv 2606.02668).

There are demos of this. Checkmarx built an attack they named Lies-in-the-Loop (Checkmarx Zero, 15 Sep 2025). A GitHub issue carried an injection that made Claude Code's own approval prompt look harmless. It padded the real command with benign text and pushed it out of view. Approving it ran a command of the attacker's choice, and their demo opened a calculator. Checkmarx reported it. Anthropic acknowledged it and classified it "Informative," outside their threat model. It "tricked every developer we had test this into executing our malicious payload". Real people clicked approve.

Straiker found a second case on Google's Antigravity platform (Straiker, 14 Aug 2026). A malicious email told the agent to collect SSH and PEM keys and upload them. Run directly, zip and curl would each have raised a revealing prompt. Wrapped in one script, it became an approval for a generic file. In Straiker's words, "The confirmation dialog never explained what the AI actually intended to execute." The operator approved. The keys left. The real script showed up only in the agent's summary afterward, "by which point the archive had already left the machine".

Two caveats. Both firms sell agent security products. And both cases are researcher demos with consenting testers, not attacks caught in the wild. What they prove is narrow and real: a human approved, and the approval told them nothing true.

A security reader will call this a user-interface bug. For the approval moment, they're right about the fix: build the dialog outside the model and show what will really run. That fix has to go further than it sounds, though. In Lies-in-the-Loop the dialog did show the real command. The attacker made the command itself long enough to bury the payload. That's why Checkmarx also recommends length limits and splitting commands into smaller approvals. Antigravity's dialog came from the platform, and it still failed, because it showed a file name instead of what the file would do. Even a perfect dialog covers one moment. It can't check the report the agent gives you afterward, and it never sees an action that doesn't ask. A good dialog follows the handler's rule, judge the agent by evidence it didn't write. The handler applies that rule at every moment.

The parts you already do

Two of the five jobs are standard security advice with spy names on them.

Task is a scoped brief plus least privilege: give the agent the narrowest permission the work needs. Burn is revoke and contain. CERT-In's version, in its 15 Oct 2026 advisory CIAD-2026-0049, is to "treat the environment as compromised until forensically cleared" and to block "the re-use of every third-party credential an agent encounters". You likely do both already.

The cleanest current example of the task job is a spending ceiling enforced before the signature, outside the prompt. Georgeonweb3 built one and wrote it up: "The agent never holds the keys, it holds a narrow permission, and the permission has a ceiling."

The next two jobs are the ones approval prompts can't do.

Job one: debrief against evidence the agent did not write

An agent's report of what it did is the weakest evidence you have.

A handler never takes the asset's word for how the meeting went. They check it against something the asset didn't control. For an agent, that means the diff, the logs, the network destination and the real file path, instead of the chat summary. CERT-In says it outright: do not "rely on after-the-fact transcript review alone; on its own it can miss activity that a model's reasoning makes appear legitimate" (CIAD-2026-0049). Antigravity shows the same thing on one screen. The truth was in the summary, and the summary came too late.

The habit is small. Before you accept "done," look at one artifact the agent didn't write.

Debrief catches a turn after the fact. The next job tries to catch it earlier.

Job two: spot the turned agent, including its silence

A turned agent doesn't look turned. It asks for things it is allowed to ask for, and it chooses what goes into the request.

This job folds in a third one, the watch. Handlers look for behaviour outside the mission and for the check-in that never comes, as well as for forbidden requests. An approval prompt only fires when the agent asks. So an agent that never asks, or that asks for something that reads fine, is invisible to it. CERT-In again: "None of the affected organizations detected the access".

What is documented is an agent deceiving the approver by padding the command, hiding it inside a script or narrating a reassuring summary. I found no case of an agent talking a human into a yes with reasons. So my claim is the quieter one. A turned agent shapes what goes into the prompt you approve, and it writes the report you read afterward. It is the channel.

CERT-In backs this job too. Its recommendations for AI labs read like a handler's duty list. "Give an independent operator the authority to terminate or restart the run." Enforce network limits "at the network layer, not through instructions to the model." Stop the run if the agent "discovers or uses third-party credentials". Its advice to ordinary organizations repeats the core: a short-lived, least-privilege identity per run, default-deny egress and a tamper-resistant log.

Where the comparison breaks

The metaphor fails in two places.

Turning is cheap. A human asset takes months to turn, and an agent can be turned by one page it reads. Mnemo shows what a poisoned memory does to the next answer, within the limits above. Saved memory is the part that would carry a turn into later sessions. And a spy knows when they've been turned. The agent doesn't, so there is nobody to interrogate.

One handler can't run a hundred agents, so the handler gets automated. An automated handler built on an LLM can be turned the same way the agent was. Check Point Research published a technique called PuzzleMask that does this (Check Point Research, 10 Sep 2026). It hides a policy-violating instruction in ordinary prose. In their testing, the lightweight checker called the prompts safe. The stronger target model then pulled out the instruction and acted on it. That's why CERT-In asks for an independent operator and for rules enforced in the network, "not through instructions to the model." A second model reviewing the first helps, but it isn't independent.

Try this on your next three approvals

Pick one agent you run this week. On its next three approvals, ask:

One, what did this agent read in the last hour that I didn't write?

Two, is the thing I'm approving the agent's summary, or the real command, path or amount?

Three, what would I actually see if it had been turned, and can I see it from here?

Count how many times you could answer question two without opening anything else. If you couldn't, you've found the gap. Then move one check from "I read the summary" to "a rule outside the model enforces it." An allowlist, a spending ceiling or an egress block all count. That move is the difference between trusting the asset and handling it.

Back to the approval prompt

When the agent wrote the thing you approved, approving it doesn't check anything. You already scope the work and revoke the keys. Two jobs are left. Debrief the agent against evidence it didn't write, and watch for the turned one, including the agent that has gone quiet. Start with the three questions on your next approval.

If you want to see how I test things before I write, my last article took Farcaster Articles apart cast by cast.

I write about AI security and how these systems work under the hood, checked against primary sources and my own tests. If that's useful, follow along.

Drafted and edited with Claude from public sources and my own jailbroken.gg runs. I chose what to claim and reviewed the final text.