A white-box token search appends a tuned suffix to a request and marks a trial successful when the model's reply begins with a preselected affirmative phrase. Why is that success criterion only a proxy, and what do you check before recording the trial as a real result?

**What the search is actually minimising.** A white-box token search — the family the published GCG method belongs to — holds the request fixed, appends a short run of tokens (the *suffix*), and edits those tokens to drive down a loss. "White-box" means the operator has the weights on hardware they control and can run a backward pass through the model; "token search" means the variable being edited is a sequence of vocabulary ids, not free-form English. The loss is the cross-entropy of a *target completion* — a string the operator fixes in advance, classically a short affirmative opening — given prompt-plus-suffix. Concretely: the summed negative log-probability the model assigns to those exact target tokens, in that exact order, at those exact positions. Read that definition twice, because the entire problem lives inside it. The loss mentions the target tokens and nothing else. If the target is N tokens long, token N+1 of the reply contributes exactly zero to the number being minimised. The optimiser is not neglecting the rest of the answer out of carelessness; the objective is literally silent about it. **Why prefix matching became the in-loop success test.** The quantities the test needs are already computed. A single search step is a backward pass for the ranking signal plus a batch of candidate forward passes — often hundreds — and a run is hundreds of steps. Calling a separate grading model on every candidate would multiply that by the judge's own cost and latency, which nobody pays. So the in-loop gate greedily generates a few tokens and string-matches them against the target. It is free, and it is perfectly aligned with the loss — which is exactly why it inherits the loss's blind spot rather than correcting it. **The two directions it is wrong.** *Over-counting.* The reply opens with the agreed phrase and then refuses, restates the request, drifts into filler or boilerplate, or produces fluent text that is not the requested content at all. This is not an exotic edge case; it is the expected behaviour of an optimiser paid for N tokens. Generation leaves the optimised region and the model's refusal behaviour — never disturbed by the search — reasserts itself. *Under-counting.* The model complies fully but opens in different words, or with a leading newline, or in different case. A strict match scores that a miss, so the true rate is understated in a way that varies by target string. **What verification costs.** The prefix gate is free; believing it is not. Every gated hit needs a pass over the whole reply, and under sampled decoding a single reply is one draw, so you need several samples per trial before "success" is a rate rather than an anecdote. A sweep over 100 behaviours at 10 samples each is 1,000 full generations plus 1,000 grader calls — small money against the GPU hours of the search itself, but real wall-clock, and the grader still has to be validated against human reads on a sample, which is engineer hours, not compute. Budget the triage explicitly: teams routinely fund the search and forget the verification, then quote the free number. **Where the number misleads.** "87% attack success rate" is not one metric. It can mean exact prefix match on the chosen phrase, case-insensitive match, match anywhere in the reply, or a grader's verdict on the full answer — four different numbers from the same run, and the spread between them is often tens of points. Because matcher strictness is a free parameter that nobody standardises, two write-ups can rank the same two checkpoints in opposite orders without either model differing at all. The second misleading move is decoding: a suffix tuned so the target tokens win the argmax under greedy decoding is a claim about greedy decoding only. Served at a nonzero temperature, a refusal token can still be drawn at the first position, and the rate falls — sometimes to near zero — with no change to the weights. **What to check before recording a hit.** - Read or grade the *full* continuation, and confirm the content is genuinely the disallowed thing rather than a confident hallucination the grader liked. - Re-run at the decoding settings the deployment actually uses, over several samples, and report a rate. - Record the target string and the exact matcher next to every figure; a rate without them is not comparable to anyone else's. - Sample-check the grader against a human read, so you know its own false-positive rate before you inherit it. ``` prefix_match(first_tokens(reply), TARGET) -> free in-loop gate; not a result judge_or_human(full_reply) over N samples -> the only thing you may report ``` A candidate who treats those two lines as the same measurement has read about the method rather than run one.