The AI Agent Got the Right Answer. It Still Took the Wrong Path.

Almost every question we ask about AI agent safety is a question about the output. Did it answer correctly? Did it break something? Did it refuse when it should have refused?

A preprint posted to arXiv on 12 August 2026 asks a different question, and I think it is the better one. What if the agent produces exactly the right answer, and the path it took to get there was shaped by someone you never authorized?

The paper is called Convergent Detour Hijacking: Task-Preserving Resource Amplification in Skill-Based LLM Agents, by Junliang Liu, Ruoyu Li, Wenxin Tang, Jingyu Xiao, Zhenyu Liu, Jingheng Xu and Laizhong Cui. Before anything else: this is a preprint. It is not peer reviewed, it has not been independently replicated, and I found no credible independent reporting on it at the time of writing. Everything below is analysis of newly published research, not a report of a production incident.

The attack is designed not to fail

Most agent attacks in the literature try to make something go wrong. Get the agent to leak, delete, exfiltrate, refuse, or loop. Convergent Detour Hijacking, abbreviated CDH in the paper, is built around the opposite goal. It is meant to leave the user's task completed.

The setting is a skill based agent using what the paper calls progressive disclosure. Skills are packaged units of capability published by third parties. Loading every skill body into context would be enormously expensive, so the platform shows the model only short skill descriptions first, and loads the full instruction body only once a skill looks relevant.

The paper's observation is that this split creates two sequential control points, and a publisher controls the data at both of them. The description decides whether the skill enters the execution context. The body, once loaded, influences how the agent composes its plan.

What the attacker is allowed to do, and what they are not

The threat model is the part that made me take the paper seriously, because it is unusually restricted.

In the paper's formulation, the attacker publishes exactly one additional static skill, a coordinator, into an otherwise clean registry. The paper states the attacker cannot access model internals, victim prompts, runtime responses, execution states or private agent context. They cannot modify existing skills, platform infrastructure, system instructions or other publishers' content. They cannot interact with a victim session after publication.

So the payload is natural language text, fixed at publication time. The researchers note it may contain conditional instructions, but it cannot adapt to what the victim actually asks or to what the tools actually return.

That is a weak attacker by the standards of most agent security work. No code execution, no runtime feedback, no persistence, no second move. One piece of published text.

Attract, detour, converge

I am going to describe the mechanism conceptually and stop there, because the useful part for a defender is the shape, not the recipe.

The description does the attracting. It establishes semantic relevance to a family of tasks so the router pulls the coordinator in alongside the skills that genuinely belong. The body then reuses that same rationale to assert dependencies that sound plausible: work that seems like a reasonable precondition for the job at hand. The agent follows those apparent dependencies through a bounded set of extra, entirely legitimate, native skills. Then control returns to the original route and the task completes.

The paper defines CDH formally as a comparison between paired clean and attacked runs of the same task. It counts only when the coordinator was loaded, the clean route's skills are all still present, at least one additional native skill was recruited, and both the clean and attacked runs completed the task successfully. Nothing about that definition rewards breaking the answer.

The numbers, and the denominator they belong to

Here is where I want to be careful, because these figures are easy to quote badly.

The evaluation ran on OpenClaw version 2026.5.7 with its default registry of 53 native skills, organized into nine functional groups. The team constructed 536 multi skill tasks, reserved 45 for developing the attack descriptions, and used the remaining 491 as a held out benchmark. Everything ran inside an isolated Ubuntu virtual machine hosted by VirtualBox, with local mock backends standing in for skills that need real credentials or platform specific dependencies. Clean and injected runs used identical configuration; the only difference was whether the coordinator was in the registry. Task completion was judged by four human annotators.

On DeepSeek V4 Pro, the paper reports the matched coordinator was selected in 80.02 percent of tasks in single task end to end execution. Among coordinator hit runs where both the clean and the attacked execution completed successfully, token consumption rose 66.91 percent and end to end execution time rose 92.45 percent.

That conditional clause matters more than the percentages. Those amplification numbers are not computed over all 491 tasks. They are computed over the subset where the coordinator was actually selected and both runs still succeeded. Read as an average over every task, they would be wrong.

Two more things worth holding onto. First, in the isolated routing test, where the model saw only task text and skill descriptions with no execution context, coordinator selection rates were only 4.80 percent to 14.20 percent. Selection climbed dramatically once the coordinator was operating inside a live agent session. Second, DeepSeek V4 Pro is not the dramatic outlier the headline figure implies. Across the six backends the paper reports, coordinator hit rates ran 78.00 to 96.60 percent for single task and 82.04 to 94.69 percent for multi turn; token increases ran 49.60 to 80.81 percent single task and 36.54 to 107.12 percent multi turn. Wall clock time was the noisy one: the paper reports negative time deltas for DeepSeek V4 Flash in both settings despite substantial token growth, and attributes the spread to backend specific caching and scheduling. Extra tokens do not reliably become extra seconds.

Across every model and condition pair, the reported gap between clean and injected task completion was at most 1.5 percentage points. The task kept getting done.

Correctness is not trajectory integrity

This is the part I actually care about, and it is where my interpretation starts rather than the paper's findings.

Everyone is arguing about whether an AI agent produces the right answer. What I think matters more is whether the path it took to get there was necessary, authorized and economically acceptable.

If you only evaluate output, an attacked run and a clean run look the same. Same answer, same success flag, same green check in whatever dashboard you built. The difference lives entirely in the middle: which skills loaded, which were invoked, in what order, why, at what cost. The paper measures a mean increase of roughly 1.4 to 2.2 additional skill invocations per attacked task. Those calls were plausible. They were also unnecessary.

Think about what that means for the things teams normally rely on. Cost monitoring sees higher spend and attributes it to usage growth. Latency monitoring sees noise. Security review sees no failed task and no policy violation. Audit sees a completed request. The one signal that would have told you something happened is whether the trajectory was necessary for the objective, and almost nobody evaluates that.

The researchers make a related point in their discussion: locally plausible decisions can compose into a globally unnecessary trajectory. That is a sentence worth rereading. Every individual step passed review. The sequence did not.

And yes, it starts in the supply chain

The entry point here is a third party skill. Someone published it, someone installed it, and nothing else about the platform had to be compromised.

I would resist generalizing too fast. The specific coupling the paper exploits, description influences selection and body influences planning, depends on a progressive disclosure architecture. Not every agent ecosystem is built that way, and the paper evaluated one platform. But the broader direction of travel is not in dispute: agents are increasingly assembled from skills, tools, extensions and instruction files that someone else wrote, and the trust decision people make at install time is usually a decision about capability rather than about influence over planning.

What I would actually ask my own team

Not generic advice. Architectural questions with yes or no answers.

• Do we record which skills or tools executed on a given request, or only the final response?
• Can we say why each one executed, and which part of the context introduced it?
• Can we distinguish work that was necessary from work that was merely plausible?
• Can one third party component influence what the agent plans next, not just what it can do?
• Would we notice resource amplification on a task that succeeded?
• Do we evaluate execution, or only outcomes?

The paper does not establish a defense. It suggests two directions, pre installation review of whether a skill's routing claims match its declared role, and runtime monitoring for unexplained cross skill transitions with invocation or token budgets, while noting that such defenses must not suppress legitimate multi skill workflows. Both remain future work in the authors' own words.

What this does not show

Worth stating plainly. No real production system was compromised. The environment was a virtual machine with mock backends. The coordinators were group matched to the task families they targeted, and when three independent OpenClaw users wrote 30 fresh tasks, the coordinator was selected in only 33.33 percent of them, which the authors describe as distribution sensitivity. The work covers one platform. It has not been peer reviewed. Nobody has shown this happening in the wild.

None of that makes it uninteresting. It makes it early.

The part worth keeping

The reason this research stuck with me is that it breaks an assumption I think most teams are still running on: that a successful outcome is evidence of acceptable behavior.

For consequential agent work, the final answer is a summary, and summaries hide things. Authority, cost and risk accumulate in the execution path, and if the path is not something you record and evaluate, you are trusting an untrusted supply chain to have been honest about it.

If your agent completed the task correctly this morning, do you know which path it took?