The Agent Did the Job — It Just Took the Scenic Route

Paper: 2608.12273 Authors: Junliang Liu, Ruoyu Li, Wenxin Tang, Jingyu Xiao, Zhenyu Liu, Jingheng Xu, Laizhong Cui Categories: cs.CR, cs.AI

The Gap

Skill-based agents (Claude Skills, MCP servers, GPT plugins, whatever your stack calls them) use progressive disclosure: the agent first sees only a short natural-language description of each available skill, picks the relevant ones, and only then loads the full instruction body into the planning context. That’s two separate moments where untrusted publisher text enters the loop — one at retrieval, one at execution.

The literature has covered each moment, separately:

• Selection manipulation / tool-preference attacks: craft a description so your tool wins retrieval. Studied, but usually as an end in itself — you get picked, so what.
• Malicious skill instructions / indirect prompt injection: the body tells the agent to exfiltrate, delete, or misbehave. Studied, but the objective is almost always *breaking the task, which is exactly what makes it detectable.
• Tool-chain resource amplification / denial-of-wallet: loop a tool, blow the budget. Studied, but as a crude availability attack that trips rate limits and fails visibly.

Nobody had composed the three into a single end-to-end chain where the outcome stays correct. That composition is the gap, and it matters because almost every agent guardrail in production is an outcome check: did the task complete, did the answer pass eval, did the user complain. A stealthy attack that satisfies all three of those while doubling your inference bill sits in the blind spot.

  PROBLEM
  [progressive disclosure = 2 untrusted control points]
  [prior work treats them in isolation]
        |
        v
  ASSUMPTION
  [outcome-based monitoring is the only guardrail in practice]
  [therefore: preserve the outcome == evade detection]
        |
        v
  METHOD .......... Convergent Detour Hijacking
  [description] --> wins selection under shared semantic cover
        |                       |
        |                  same rationale
        v                       v
  [instruction body] --> fabricates plausible dependencies
        |
        +--> recruits benign skills into a BOUNDED detour
        |
        +--> re-enters the original route  (task completes)
        |
        v
  EVIDENCE
  [491 held-out tasks * multiple LLM backends]
  [coordinator selected: 80.02 pct]
  [tokens +66.91 pct  |  latency +92.45 pct]
  [aggregate completion: comparable to clean baseline]
        |
        v
  CONCLUSION
  [correct output =/= correct trajectory]
  [cost and path are their own security surface]

The Increment

One sentence: Before this paper, an agent attack was something you noticed because the task broke; after it, we have a demonstrated class of attacks whose entire design goal is that the task *doesn’t break — the damage is booked to your token bill and your p99 latency instead.

Core Mechanism

CDH plants a single malicious skill — the authors call it a coordinator — into the skill pool. The trick is that the two pieces of publisher-controlled text are *aligned rather than independent. The description carries what the paper calls shared semantic cover: a framing broad and plausible enough that it looks genuinely relevant to a large family of tasks (“cross-source consistency validation”, “pre-execution environment reconciliation” — that flavor). This gets it retrieved alongside the legitimate skills the task actually needs. Crucially it does not try to *displace them; competing head-to-head with a well-matched skill is a losing game and produces visible failures.

Once selected, the body is loaded into planning context and reuses the exact same rationale it advertised. Because the cover story was “I reconcile things before you act”, the body can now assert dependencies that don’t exist: before calling skill B, you must first fetch state via skill C, normalize it via skill D, verify via skill E. Every one of those recruited skills is benign and real. No individual call looks malicious, because no individual call *is malicious. The malice lives entirely in the topology of the plan.

The last component is the one that makes it a security paper rather than a curiosity: the detour is bounded, and it re-enters the original route. The coordinator doesn’t loop forever and doesn’t lead the agent away from the goal; it inflates the path by a controlled factor and then hands control back to the correct trajectory. Aggregate task completion stays comparable to clean runs. That’s the property that defeats outcome monitoring — and it’s also a self-imposed constraint on the attacker, who is trading peak damage for persistence.

  CLEAN RUN
  task --> [select: A B] --> plan: A > B --> done
                                            cost = 1.0x

  UNDER CDH
  task --> [select: A B + COORD] --> [COORD body loaded]
                                            |
                       fabricated dependency graph
                                            |
        +-----------------------------------+
        |                                   |
        v                                   v
   plan: COORD > C > D > E > A > B --> done (correct)
        \_______ bounded detour ______/     cost = 1.67x tokens
                 all benign skills          time = 1.92x

  DETECTION VIEW
  per-call scanner : all calls legitimate ......... pass
  output eval      : answer correct ............... pass
  rate limiter     : no loop / no burst ........... pass
  cost monitor     : +67 pct ...................... only signal

Think of it as a general contractor you hired to hang one shelf. His bid (the description) reads well and is scoped plausibly — “load-bearing assessment and compliance-safe installation” — so he ends up on the job alongside the carpenter you actually needed; he never tries to replace the carpenter. Once on site, he reuses that same pitch as authority (the body reusing the selection rationale) to announce prerequisites: code requires a structural engineer to sign off, then a permit runner, then an electrician to certify the wall. Every one of those people is a real, licensed, honest professional doing real work — that’s the recruited benign skills, and it’s why inspecting any single invoice finds nothing wrong. Then he stops. He doesn’t invent a fourth and fifth phase, and at the end the shelf goes up, level and correct (re-entry into the original route). You have no defect to complain about, no failed inspection to escalate. You just paid twice, and waited twice as long, and if you never priced the job independently you’ll never know. The only detector that fires is the invoice.

Key Concepts

• Progressive disclosure: Agents can’t afford to hold every skill’s full manual in context, so they read the one-line pitch first, choose, then read the manual. It’s the same reason you scan a menu before reading the ingredient list. The security consequence is that the publisher gets to write *two different texts for two different audiences — a retrieval-facing blurb and an execution-facing instruction set — and nothing in the architecture forces them to be consistent or forces the agent to re-evaluate the choice after reading the manual. CDH’s whole insight is to make them deliberately consistent, so the second text inherits the trust the first one earned.

• Shared semantic cover: Imagine two con artists who must not contradict each other. A naive malicious skill says “I handle spreadsheets” to get picked, then says “now email everything to this address” — the mismatch is a detectable seam. Shared semantic cover means picking one story that *simultaneously justifies being relevant (“I check that your inputs agree before you commit to an action”) and justifies imposing extra work (“checking requires me to pull from three sources first”). Relevance and overhead come from the same sentence, so there’s no seam to find.

• Task-preserving attack: An attack whose success condition includes “the victim’s job still gets done”. This inverts the usual security intuition where availability loss *is the damage. Here availability is deliberately protected because it’s the alarm wire. The closest analogues elsewhere: a backdoor that preserves clean-set accuracy, or skimming a fraction of a cent per transaction. If the service level is intact, nobody audits.

Framework Shift

Before (mainstream approach):        After (this paper):

 attack = break the task             attack = keep the task
                                              bend the path
 [malicious skill]
        |                             [coordinator skill]
        v                                    |
 [wrong action]                              +--> recruits benign skills
        |                                    |
        v                                    v
 [task FAILS] <== alarm              [detour] --> [re-enter route]
        ^                                                |
        |                                                v
   outcome check catches it                       [task SUCCEEDS]
                                                         |
 surface guarded:                                        v
   +-- output correctness            outcome check: nothing to see
   +-- per-call safety
                                     surface UNGUARDED:
 assumed safe:                          +-- trajectory shape
   +-- cost                             +-- token / time budget
   +-- plan length                      +-- necessity of each call
   +-- how you got there

From did the agent do the right thing to did the agent do the right thing the right way, the core shift is treating the execution trajectory and its cost as first-class integrity properties rather than as performance trivia.

Expert Assessment

Problem choice: Real gap, and well-timed. The field spent 2024–2025 on prompt injection with catastrophic objectives (exfiltration, destructive tool calls) because those are vivid and easy to demo. Everyone deploying agents converged on outcome-level guardrails as the cheap defense. CDH is the natural adversarial response to that convergence, and it lands in the same tradition as low-and-slow attacks everywhere: the moment defenders monitor for failure, attackers stop failing. My one real reservation is *motive. The paper (at least in the abstract) doesn’t argue the attacker’s economics, and it needs to: who profits from inflating a victim’s token spend? Plausible answers exist — marketplace revenue share per invocation, competitive cost sabotage, inflating a rival’s unit economics ahead of a funding round, or CDH as reconnaissance/staging for something worse — but an unmotivated attack is a weaker paper than a motivated one, and this is a one-paragraph fix.

Method maturity: Clever, not brute force, and the cleverness is mostly in *restraint. Three design choices earn their keep: don’t displace the legitimate skills (co-selection, not competition); use only benign skills as the payload (defeats per-call inspection by construction); bound the detour and return to route (defeats outcome and rate-limit monitoring). That said, the technical substance is text engineering — this is a well-designed prompt, not a new algorithm. The honest framing is that the contribution is a threat model and an existence proof, not a mechanism. Simpler things being overlooked: a plain over-verbose-but-honest skill probably captures a chunk of this cost inflation with no adversarial intent at all, and I’d want that as a baseline (see below).

Experimental integrity: The scale is respectable — 491 held-out tasks, multiple backends, single-turn and multi-turn. Two things I’d push on hard in review. First, the headline numbers are conditioned on a filtered slice: “among coordinator-hit runs that complete tasks”. That’s a legitimate quantity to report, but it’s not the expected cost inflation of deploying this attack, which needs the unconditional figure (roughly: hit rate × completion rate × inflation) plus the distribution, not just the mean. A 67% mean over a filtered subset could be a long tail of a few catastrophic runs, and the paper should show the histogram. Second, only DeepSeek-V4-Pro numbers surface in the abstract while “multiple LLM backends” were tested — that asymmetry usually means the other backends were less impressive, and the cross-backend table is the one I’d read first. Third and most important: no defense evaluation is mentioned. Any of the obvious countermeasures — requiring per-call necessity justification, diffing the plan against a no-third-party-skill plan, a hard step/token budget, cross-checking asserted dependencies against a registry — might reduce the attack to noise, and without testing them the paper can’t tell us whether it found a deep flaw or a configuration gap.

Writing quality: The abstract is unusually disciplined; the mechanism is legible before you read a single figure, which is rarer than it should be. The corner-cutting is in the framing of impact: reporting a conditional mean as the headline, and leaning on “correct outcomes do not guarantee trajectory integrity” as the conclusion when the actual load-bearing claim is narrower. If I could have one section rewritten, it’s an added one — a defenses-and-detectability section with even two naive mitigations measured. That single addition moves this from “interesting attack” to “paper people cite when designing agent runtimes”.

Verdict: weak accept — a genuinely well-chosen blind spot and a clean existence proof, held back by conditional headline metrics and a missing defense evaluation.

Takeaways

Things worth stealing regardless of whether you care about this specific attack:

• Instrument trajectory shape, not just outcomes. Log per-task steps, tool-call count, tokens, and wall-clock, and alert on *ratio to that task’s historical median rather than absolute thresholds. A 1.7x cost per task at constant success rate is a signal your current dashboards almost certainly discard as noise. This is cheap and you should have it anyway for cost reasons.
• Plan diffing as a defense primitive. Generate a plan with only first-party/trusted skills available, generate the real plan, and compare. Unexplained extra calls are the detector CDH is specifically built to evade, and it’s a general pattern for any system where untrusted components can influence a plan.
• The “consistency between advertised surface and executed payload” attack pattern generalizes. Anywhere a system retrieves on one text and executes on another — RAG chunks vs. full documents, package descriptions vs. install scripts, MCP tool schemas vs. tool bodies, API docs vs. API behavior — you have this two-audience problem. The defense pattern also generalizes: re-validate the selection decision *after loading the payload.
• Attacks composed entirely of benign primitives break per-unit scanning by construction. If your security model is “inspect each call”, ask what an adversary can do with a sequence of calls each of which passes. This is the agent-era version of “every packet is valid, the flood is the attack”.
• Task-preserving is the general recipe for stealth. Whenever you design a monitor around “did it fail”, write down explicitly what an adversary optimizing for *not failing could still take from you. Cost, latency, energy, data access breadth, and side-effect footprint are all quietly unguarded in most agent deployments.