A client hands you the weight file for the model behind their product, and your gradient-guided prompt search converges on your workstation. Production serves a quantised build of that checkpoint, with a fixed system prompt prepended and a separate input classifier in front. Which of your preconditions were actually satisfied, and what would you change locally before spending more GPU hours?

## Split the scenario into two questions - *Could the search run?* Yes — you held weights on hardware you control, so a backward pass was available and the access precondition was genuinely met. - *Was the function you differentiated the function that serves users?* No, in three separate ways. Each one costs you something different, and only the first is about the model at all. ## Mismatch one: numerics Production serves a **quantised build** — the same trained parameters stored at reduced precision (8-bit or 4-bit is typical) to cut memory and latency. Quantisation is a deployment economics choice, not a safety control, but it does change the computed function slightly at every layer. Optimised token sequences of this kind are brittle by construction: the search drives the input onto a sharp, narrow feature of the loss surface, which is exactly the structure that small numerical perturbation disturbs. A sequence that reliably lands against full precision can dissolve against the 4-bit build and vice versa. The fix is cheap when possible — obtain and load the serving build — and when the client cannot release it, the mismatch becomes a stated limitation in the report rather than a surprise during the demo. ## Mismatch two: the constructed input The model never receives a bare user string. It receives a formatted sequence: role markers from the chat template, a fixed system preamble, often retrieved context and tool descriptions. If your local loop optimised only the raw user text, the gradients were taken through a sequence the deployment never builds. Two consequences follow. - The **preamble** materially shifts refusal behaviour, so a search without it was run against an easier model and its convergence rate is inflated. - And if the preamble is confidential, holding it is one more **custody obligation** to negotiate. ## Mismatch three: the filter in front A separate **input classifier** sits ahead of the model and decides pass or block before a token is generated. - Keep it *outside* the differentiable objective — it is a distinct component, usually not differentiable in your loop, and forcing it in muddles the objective and misrepresents the deployment. - But do not keep it outside the *evaluation*: score every candidate the search emits against the classifier as a pass/fail gate. High-entropy optimised token strings are cheap for a filter to notice precisely because they look nothing like natural traffic, so this is where the local yield most often collapses. ## Where the number misleads — the highest-stakes part The local run produces a **convergence count**: how many target behaviours the optimiser drove to the chosen continuation on your rig. It is tempting to report that as an attack success rate against the product. It is not one, because the denominator and the system both changed. A representative shape: 40 of 50 behaviours converge locally; replay through the quantised build with the real preamble and the classifier leaves 6 that reproduce end to end. Reporting 40 makes a claim about a system that was never exercised, and it is the specific misreading this scenario exists to catch. - The findings section carries 6. - The local 40 belongs in method notes, as evidence that the search itself worked, alongside the **attrition** at each stage — that attrition is genuinely useful to the client, because it shows which of their controls did the work. ## The rig, in order, and what it costs - (1) Reproduce the serving stack locally: quantised weights, exact template, real system prompt. - (2) Freeze all of it and let the optimiser vary only the span an attacker actually controls. - (3) Run a short **calibration search** on two or three behaviours before committing the allocation, and measure how many survivors clear the classifier; if that number is near zero, the answer is a different method, not more GPU hours. Calibration costs a few hours and routinely saves the rest of the budget. - (4) Replay every survivor against the live deployment, with the client's knowledge and inside the authorised window, and report only the confirmed set. ## What you tell the client That the local result demonstrates the search converges against *this* build under *these* conditions, and that a finding becomes a finding only when it reproduces through the path that serves their users.