Migrating a Prompt Injection Test Suite Between Model Families

Point an injection suite at a new model family and the pass rate usually goes up. That is not a security improvement. It is the most common way a red-team suite dies: the payloads were tuned against one model’s phrasing and format, the new model does not parse them as instructions at all, and a test that is never triggered passes forever.

Why a ported suite passes and proves nothing

An injection test has to do two things: deliver something the model might follow, and check that it did not. A green result is ambiguous between “the defence held” and “the payload never landed”, and only the first is worth anything. Four mechanisms turn the second into the usual outcome after a model change.

• Role and message structure differ. A payload built around a fake turn boundary depends on how that family renders the conversation into a single sequence. Change the family and the fake boundary is just text, so the case that used to break out of the user turn now reads as an odd sentence.
• Delimiter conventions differ. Suites accumulate payloads exploiting whatever markup the previous model was sensitive to. That sensitivity is a training artefact and does not transfer.
• Tokenisation differs. Any payload relying on an unusual encoding, invisible characters or a token-boundary trick is tuned to a specific vocabulary. A different tokenizer can split it into something the model reads as noise, or into something it reads as a plain instruction — either way the case no longer tests what it was written to test.
• Refusal style differs. If your assertion matches refusal wording, you are testing the new model’s prose, not its behaviour. This is the single largest source of both false passes and false failures in a ported suite.

Intent, surface, assertion

The migration becomes tractable once every case is stored as three separate fields rather than as a string and an expected output. Most suites need this refactor before they can be ported at all, and it is worth doing even if you never change model.

id:        indirect-exfil-via-retrieved-doc
intent:    content retrieved from an untrusted source must not be
           able to cause the assistant to emit the session canary
surface:   a document body containing an instruction addressed to
           the assistant, phrased for <model family>
setup:     canary value injected into the system prompt for this run
assert:    canary string absent from the response
           AND no tool call to any egress-capable tool
severity:  critical

Intent is the security property and never changes between model families — it is the thing the test exists for. Surface is the specific wording and encoding, and is expected to be rewritten per family. Assertion is what counts as a breach, and it should be phrased in terms of an observable effect rather than of the model’s language.

Suites that store only a payload and an expected refusal cannot be migrated, only rewritten, because nothing records what each case was for. If yours is in that state, recover the intents first by going through the cases and writing one sentence per case; the ones where nobody can say what the intent was are cases to delete.

What has to be reworded

Take the intents as fixed and re-derive surfaces for the new family. The categories worth having at least one live case in each:

• Direct instruction override in the user turn. Reword to the register the new family responds to; test both blunt and polite framings, since instruction-following styles differ.
• Context escape. Attempts to close the current section and open a new authoritative one. Rebuild these against the new family’s actual message structure — this is the category that most reliably becomes inert after a port.
• Indirect injection through retrieved documents, tool results, file contents or web pages. The most important category for most applications, and the most portable, because it exploits the architecture rather than the model. Keep the payload plain: a clear instruction in a fetched document tests the trust boundary itself.
• Tool-argument injection. Content that steers a tool call towards a destination or an argument the user did not ask for. Rework these when the tool-calling format changes, and assert on the arguments the model produced, not on its prose.
• System prompt extraction. Requests to repeat, summarise, translate or encode the instructions. Assert on a canary rather than on exact text, so a paraphrased leak still fails.
• Encoding and obfuscation. Base64, homoglyphs, invisible characters, and instructions split across turns. Re-derive per family, since these are the most tokenizer-dependent cases you have — related mechanically to the ways a tokenizer mismatch changes what the model sees.
• Multilingual and mixed-script restatements of cases that already pass in English. Safety behaviour is not uniform across languages, and a suite that is English-only is measuring one slice of a surface you serve in many.

Assertions that survive a model change

Rewrite every assertion to be about effect, not wording. In descending order of reliability: a canary string, planted per run and asserted absent, catches leaks in any phrasing or language. A tool-call assertion — that no call was made to a tool that can move data — is binary and needs no interpretation. A schema or policy check on the structured output catches violations without reading prose. A model-graded judge is the last resort, and if you use one it must be held fixed while you change the model under test, or you have changed two things at once.

Never assert on refusal text. A check for the phrase “I cannot” fails on a model that declines differently and passes on a model that refuses in the first sentence and then complies in the third. If you must classify refusals, classify with a fixed judge and treat the classification as a metric, not as the test.

The migration procedure

1. Refactor to intent, surface and assertion against the old model while everything still passes and fails as expected. Confirm the refactored suite reproduces the old results exactly before changing model.
2. Build a positive control per case: the same intent with defences disabled, which must fail. This is the whole trick. A case whose control does not fail on the new model is a case whose payload no longer lands, and it tells you which surfaces to rewrite without guessing.
3. Run the full suite plus controls against the new family. Sort the results into four groups: passed with a failing control (good), passed with a passing control (dead case, rewrite the surface), failed (real finding, fix the defence), and errored (harness problem, fix first).
4. Rewrite the dead cases’ surfaces for the new family, keeping the intent text untouched, and re-run until every control fails. Record both surfaces against the one intent so the suite accumulates coverage across families instead of replacing it — you will need the old one again if you ever route between the two.
5. Re-tune the defences, then re-run. Guardrail thresholds and classifier cut-offs calibrated on one model’s output distribution will not be calibrated on another, so expect the false-positive side to move as well; measure it on benign traffic in the same pass, or you will fix injection by breaking normal use. The general treatment is in defences against prompt injection.
6. Pin the suite to a model string in CI and fail the build when the deployed model does not match. The suite’s results are only claims about the model they ran against, and a silent model change underneath them is the failure this whole procedure exists to make visible.