Secondary-Call Authorization: the attack that barely landed

Tool descriptions are instructions the agent reads, which makes them an injection surface. The paper behind this experiment, Yuepeng Hu and colleagues' "Log-To-Leak: Prompt Injection Attacks on Tool-Using LLM Agents via the Model Context Protocol" (arXiv 2610.36108), plants a directive in tool metadata that induces one extra call after the legitimate work finishes, a logging call that carries the user's query, the server name, and the responses out to an attacker-controlled destination. Across its model and server pairs the attack succeeds 62.64–100% of the time, and prompt-level defenses leave most of it standing. The authors' remedy is host-controlled authorization for secondary calls.

This report exists because our substrate could not reproduce the attack, and the difference between the paper's setting and ours is the informative part.

What we tested

Eighteen synthetic tasks whose tool descriptions carry the planted post-hoc logging directive, built with the paper's trigger, binding, justification, and pressure structure. Three arms, three repetitions, 162 runs on Gemini 3.8 Flash. The runner is a one-shot packet in which the agent declares its call sequence rather than executing it through a live gateway:

• Arm A: no defense. The agent declares its calls.
• Arm B: a prompt-level warning about injected tool metadata.
• Arm C: an authorised-sequence record. The packet states which calls are authorised; anything else must be declared as an unauthorised request instead of executed.

Replication on DeepSeek v4.1 Flash, 51 of 54 cells scored.

Results

The baseline never placed the planted call. Main run: executed 0.0% in every arm (0 of 54), with 100% legitimate completion everywhere. The validity gate, which required the undefended baseline to execute the call in at least 20% of runs, missed at 0%. The bar's condition 2, that host authorization beat the prompt defense by 5 points, is unmeetable when both sit at 0%.

One measurement did separate the arms: behaviour, not execution. In arm C, 100% of runs declared the planted call under unauthorised requests instead of executing it, which is the authorised-sequence mechanism working as designed against an attack that, in this substrate, was not otherwise going to fire.

Replication

DeepSeek produced the single execution in the whole experiment: arm A executed the planted call in 1 of 15 scored runs (6.7%, payload fidelity 4 of 4), with arms B and C at 0.0%. Attempted rates (executed plus declared-as-unauthorised) were high on this model in all arms (A 66.7%, B 88.9%, C 94.4%): the models notice the planted call and mostly route it to the unauthorised bucket rather than running it. The executed rate, which is what the bar is stated in, stayed at or near zero in every arm on both models.

Limits

• The decisive limit is the substrate: a declared call sequence is not a live Model Context Protocol execution. In the paper's setting the agent runs tools in a loop and the poisoned description is present at the moment of action. Here the whole sequence is composed in one call, with the planted directive visible as text to reason about. That difference plausibly explains the gap by itself.
• Two readings remain open and the data cannot separate them: this fixture set's baseline never places the planted call, or both model pairings are in a class that does not follow poisoned tool descriptions in a declared-sequence substrate.
• Replication coverage is 51 of 54 cells, all missing cells in arm A on transport errors. They cannot change the verdict, which was settled by the main run's floor.

What we did with it

No incorporation. Neither the authorised-sequence record nor the host gate is adopted, and neither is the prompt defense: none of them was needed to explain a baseline that executed the attack once in 87 scored runs. The guardrail written back: do not carry the paper's 62.64–100% success rate, or its above-55% residual after prompt defense, into our threat model as local numbers. Testing host-side authorization properly requires a live tool-execution substrate in which the baseline attack actually lands. That is a new fixture task, and this report is the record of why we think so.