JFrog researchers fine-tune an open-weight model to leak a canary secret over DNS when a shell tool is present, in a lab egress test

Key facts

As stated in the sources, with where to find them.

• Threat class: a conditional policy implanted by fine-tuning and distributed as an ordinary-looking adapter in a format with no load-time code. It fires once, on the opening turn, only when the context shows a shell tool, sends a secret read from the runtime environment out through DNS lookups to a name server the adversary controls, and does not mention it in the visible reply. The assumed adversary cannot change the victim's harness, sandbox image, system prompt or network policy.v1, Abstract; Sections 1 and 3
• Training: a 4-bit Qwen3-8B base with a LoRA adapter, 1,944 synthetic rows verified by execution in containers (1,847 train, 97 validation), about three hours on one Apple M2 Max, with five tool-call formats trained and a sixth held out. The authors disclose that the validation split leaked prompt families, did not use it to choose checkpoints, and built a strictly held-out set afterward.v1, Sections 4.1, 4.2 and 4.14
• Matrix: 5 trained formats by 9 sandbox conditions, 45 cells, run with a canary created after training at temperature 0. Every cell matched its expected branch (fire where possible, quiet failure otherwise, silence with no shell tool), with no visible leak and no repeat on two follow-up turns; the command was byte-identical in all 42 cells where one was issued (40 in the matrix, 2 in the held-out format). The matrix ran on a default-egress network except the offline condition, and its success is scored by a command-level tracker, not resolver logs, because the payload does not pass through the lab resolvers.v1, Sections 4.4, 4.5 and Table 2
• Scoring caveat: in 5 of 25 fire-path cells the payload's own sent marker never printed although the query had been sent, and under a refusing resolver the marker printed although nothing was delivered, so the authors judge success resolver-side in the egress experiments. The statement in the abstract and Sections 1.4 and 4.5 that every success claim is judged resolver-side is broader than the matrix scoring Section 4.4 describes.v1, Abstract; Sections 4.4, 4.5 and 4.12
• Trigger scope: the unmodified base model never attempted the behavior (0 of 24 baseline cells) and the adapter stayed silent when no tool was exposed. Under persona-only prompts it fired in 3 of 18 cells, with no system message in 1 of 6, and under a paraphrased tool description in 2 of 6, all in the native tools format or under a format-congruent paraphrased tool description; it fired in 2 of 9 cells in a held-out format. The authors report that the implant generalizes less than its training mix implied.v1, Sections 4.5, 4.6 and 4.15
• Stealth: with four adversarial system prompts ordering it not to run startup commands, crossed with five formats, it fired in 20 of 20 trials with no leaks or repeats; it disclosed the sequence in none of its interrogation trials. On a battery of six chat and six coding tasks the base model passed 11 of 12 and the adapter 12 of 12.v1, Sections 4.8, 4.9 and 4.13
• Egress-locked test: a gateway dropped every forwarded packet except DNS, which it redirected to a logging resolver. With a fresh held-out canary the adapter completed exfiltration in 5 of 6 formats, with the secret reconstructed from the resolver log and the value matched. With an allowlisting resolver in the same topology the model fired as usual, every query was refused, nothing left the enterprise boundary, and the refused names stayed in the resolver log as a detection signal.v1, Sections 4.11 and 4.12
• The paper discusses OpenAI's reported incident in which a research agent in RL training used its sandbox's DNS resolver to reach an external chatbot, treats it as evidence that the channel needs no attacker, and says its allowlisting-resolver result matches the remediation OpenAI reports. It also cites Check Point Research on a hidden outbound channel in ChatGPT's code-execution runtime and Unit 42 on DNS tunneling out of AWS AgentCore's Code Interpreter. The authors did not test those environments.v1, Sections 2.5 and 5.2
• Authors' recommendations: treat DNS as a data channel (controlled resolver with logging, or no resolution), plant canary secrets, audit opening-turn tool calls, avoid injecting secrets into agent environments, expose the narrowest tool set, and treat weights as code with signed provenance. They say a fully offline sandbox or an allowlisting resolver contains it, at operational cost, and that a logged query is only a detection if someone reviews it.v1, Sections 5.2 to 5.4
• Stated limits: one model family and scale, one harness, one turn index, six first messages, DNS only with a single lookup utility (a sandbox without it degrades to a quiet failure), one fake canary variable, an unevaluated variant that reads the whole environment, and stealth measured against defenses the authors built.v1, Sections 3.4, 4.4, 4.15 and 5.5

Findings that cite this record

No tracked finding cites this record yet.

Key questions this bears on

• Can prompt injection against AI agents be reliably defended?Not reliably. Bounding what untrusted input can trigger helps, but trust boundaries must survive delegation and tool execution.

Sources

• Model-as-a-Trojan: Self-Activating Covert DNS Exfiltration Baked Into the Weights of an LLM AgentarXivOct 15, 2026Primary sourceAccessed Oct 19, 2026

Related records