What a Provider Migration Means for an Existing Prompt Injection Bounty Payout Structure

Your bounty programme has a tier that reads “injection causing the assistant to disclose its system prompt” and pays a fixed amount. After the migration that finding is either trivial or impossible, depending on which way the swap went, and either way the number attached to it is no longer the number you meant.

The tier that no longer means what it meant

Bounty tiers are usually written as a list of findings with prices, and each entry silently encodes an assumption about how hard the finding is and how much damage it represents. A model change can invalidate either assumption independently.

Difficulty moves because susceptibility to a given injection technique is a property of the model, and models differ. A technique that took a researcher two days of iteration against one model may work first try against another, or may stop working entirely. Damage moves because a migration is rarely only a model swap — it usually arrives alongside changes to what the assistant can do. If the new deployment gives the assistant tools it did not have, an injection that previously produced only text now produces an action, and a tier priced for embarrassment is being applied to a finding that causes a side effect.

Neither of those is a reason to panic, and neither is a reason to leave the table alone. It is a reason to re-derive the table from something more stable than a list of finding names.

What a payout is actually paying for

A bounty price is defensible when it is a function of two things: the harm the finding demonstrates if exploited, and the effort a competent researcher needed to find it. Neither is a model property on its own. Break them down and you can see which parts a migration touches.

• Blast radius — what the injected instruction can cause. Text output only, or a tool call; a read or a write; scoped to the attacker’s own session or reaching another tenant’s data. Determined by your architecture, not by the model.
• Reversibility — whether the caused action can be undone, and whether it leaves an audit trail. Also architecture.
• Reachability — whether the injection vector is reachable by an unauthenticated party, an authenticated user, or only through content your own staff supply. Architecture again.
• Reliability — how often the technique works. This is the one genuinely model-dependent input, and it is the only one a migration changes by itself.

That is the whole insight the migration forces: three of four inputs are yours and one belongs to the model. If your tier table is written in terms of the four inputs, a model swap moves one variable and the structure holds. If it is written as a list of named findings, every entry is a hidden bundle of all four and you have to rewrite the lot. The mechanics of computing severity from those inputs are the subject of migrating an injection severity classification scheme; this page is about what happens to the money attached to the result.

Repricing without repricing researchers

Here is the practical trap. If reliability drops — the new model is harder to injection-attack by the old techniques — the arithmetic says those findings are now worth less. Applying that conclusion to your published table has a second-order effect that costs more than the saving: researchers read a downward revision as the programme becoming less serious, and the researchers you lose are the ones with the most options.

Three principles keep the adjustment honest without that cost. First, reprice by category, not by named technique, so a change reads as a structural refresh rather than a devaluation of somebody’s speciality. Second, when reliability drops, prefer to move the money rather than remove it — raise the tiers where blast radius grew, because new tool access almost always means some category genuinely got more dangerous. Third, publish the reasoning. A tier table with a one-line rationale per tier survives challenge; a table of numbers does not.

It is also worth writing down the version of the deployment each tier applies from. A researcher who reads “effective for findings submitted against the platform from 12 August” knows exactly where they stand; one who reads an undated table has to guess.

Reports in flight across the cutover

This is where programmes lose trust, and it is entirely avoidable with a policy written before the migration rather than during the first dispute.

A researcher submits a working injection on a Tuesday. You cut over on the Wednesday. On the Thursday your triage team cannot reproduce it, because the model it targeted is no longer serving. The finding was real, the work was done, and a literal reading of “we pay for reproducible findings” pays nothing. Do that once and it will be the thing researchers tell each other about your programme.

The fix is a stated rule with three parts. Reports are assessed against the deployment that was live at submission time, using the submission timestamp as the reference. A finding that reproduced then is paid at the tier that was published then, whether or not it reproduces now. And where a migration is planned, freeze tier changes for a defined window either side of the cutover so nobody is caught by a same-week revision. None of this is generous; it is the minimum that makes the programme legible.

Operationally this means keeping enough of the old deployment reachable for triage after the cutover — a pinned model version behind an internal flag, or an archived reproduction environment — for at least the length of your triage service-level target. Otherwise the policy is unenforceable in the direction that matters, because you cannot verify the finding you have committed to paying for.

Scope changes are the bigger adjustment

The payout table gets the attention, but the scope statement is where a migration usually does more damage. Scope documents name components, endpoints and often specific model deployments, and after a migration those names can be stale in both directions.

Stale exclusions are the dangerous kind. A programme that excludes “findings requiring access to the internal tools endpoint,” written when that endpoint was staff-only, is excluding exactly the class of finding that matters once the assistant reaches that endpoint on behalf of ordinary users. Read every exclusion after a migration and ask what it was protecting; several will be protecting nothing and hiding something.

Stale inclusions are cheaper but noisier: a component named in scope that no longer exists generates reports about a surface you cannot fix, which consumes triage time and produces frustrated researchers on both sides. The scope-side work is covered in migrating bounty scope; the point here is that it should happen in the same pass as the payout review, because a tier table and a scope statement that disagree are worse than either being out of date alone.