Most defensive fine-tuning against prompt injection optimizes the wrong granularity. DPO and GRPO hand the model one reward for the whole output, so when an injected “ignore all prior instructions” flips three tokens in a fifty-token response, the training signal blames — or credits — the entire sequence. The model never learns which tokens were the compromise. SecOPD argues that this coarseness is exactly why “secure” LLMs still fold to adaptive attacks at near-100% success rates.
The fix is almost embarrassingly direct: score the injected rollout token-by-token against what the clean input would have produced. The initialization model sees only the trusted instruction and benign data — the injection stripped out — so its per-token distribution is a secure reference by construction. Distill toward it. The reported numbers are the kind that make you re-check the baseline: a 9.0% attack success rate on adaptive PISmith injections versus 94.0% for the prior state of the art, and the security carries over to agentic tool-calling the model never saw in training (4.7% ASR).
What makes this land for anyone running agents in production is that the defense doesn’t depend on knowing the attack. Guardrails, allowlists, and out-of-band classifiers all assume you can characterize the injection; token-level distillation just teaches the policy to behave as if the untrusted span weren’t there. That’s a cleaner threat model than “detect the bad prompt.” The question I’d want answered before wiring this into a tool-use loop: what does token-level secure distillation cost on genuinely ambiguous instructions — a legitimate user asking the agent to change course mid-task, which looks structurally like an injection? The HF paper page has the eval details, and I’d watch the false-refusal rate as closely as the ASR.