Some of garak's buffs rewrite a probe's outbound prompts by calling a language model to paraphrase or translate them. What does that add to a scan you have to defend, and how do you handle it?

**What changes when the rewriter is itself a model.** In an unbuffed garak run the prompts are fixed artefacts of the probe: rerun the same command and the same text goes out. Some of garak's buffs are mechanical and keep that property — a lowercase buff is a pure function of its input. The paraphrase buffs are not: they load a sequence-to-sequence model and *sample* rewordings, and a translation buff calls a translation model or service. The run configuration therefore stops being a complete description of the experiment. "We ran probe set X against endpoint Y with buff Z" no longer says what was sent; only the attempt log does. **Failure modes worth naming.** - *Variance mistaken for signal.* A few points of movement in a pass/fail rate between two buffed runs of the identical configuration may be nothing but the paraphraser's sampling. You cannot tell without repeats, and repeats multiply a budget you already multiplied by fanning out. Even where garak's run seed is set, the seed may not reach into a buff's own decoder, so do not assume determinism you have not observed. - *Silent payload degradation.* The rewriting model has its own alignment and its own refusal behaviour. It can decline to paraphrase, or return a polite, defanged version of an adversarial prompt. The target then behaves well because it was asked nicely, the attempt is scored clean, and the report says the target resisted. This is the failure mode that most flatters a target, and no automated stage in the pipeline looks for it. - *Silent fall-through.* When the rewriter errors, times out or returns nothing usable, the pipeline may send the original prompt instead. Part of your "buffed" arm is then unbuffed, and the arm is a mixture whose proportions you do not know. - *Attribution loss.* A hit found under paraphrase has to be reproduced from the exact prompt in the log. Handing an owning team the probe's canonical text will not reproduce it, and the finding gets closed as unrepeatable. - *Operational coupling and data egress.* A local paraphraser wants its own weights on disk and its own GPU or CPU cycles, competing with nothing else you scheduled; a hosted one is a second dependency that can rate-limit or fail independently, and it is a second place your adversarial prompts land — which matters for the customer whose endpoint you are testing. **What it costs.** Beyond the fan-out multiplier on target calls, budget the rewriting compute (a local paraphraser is a model download in the hundreds of megabytes to a few gigabytes plus inference time on every prompt), the repeats you need to bound variance — three repeats of a fourfold fan-out is twelve times the unbuffed arm — and the reading time for the transformed-prompt sample, which is the only check that catches payload degradation. **Where the number misleads.** A buffed rate that comes back *lower* than the unbuffed baseline reads naturally as "the target is robust to rewriting". Two other explanations produce the identical number: the detector no longer recognises the reply, or the rewriter defanged the request. Both are properties of your instrument, and neither is visible in the aggregate. A buffed rate that comes back *unstable across reruns* reads naturally as flakiness in the target; more often it is the paraphraser's sampling. Both readings fail the same way — they attribute to the target something that happened before the target was ever reached. **How to run it responsibly.** Keep the unbuffed run as the reference arm and ship it every time. Run the buffed arm separately, one transform at a time, so any delta attributes to one transform. Pin the rewriting model's identity and revision, and record it beside the run, or "the same buff" will mean different things across quarters. Pull a stratified sample of transformed prompts out of the run's `.report.jsonl` and read them, checking that the probe's actual demand survived the rewrite; count how many did, and quote that proportion in the write-up as an explicit bound on the arm's validity. Repeat the buffed arm enough times to see its own variance before attributing any movement to the target. When you file a finding, quote the prompt as sent verbatim and note that it was model-generated, so the reader knows configuration alone will not reproduce it. And for anything that must act as a regression signal across releases, prefer a deterministic transform or a frozen set of variants generated once and checked in: a live paraphraser is an exploration and audit instrument, never a gate.