You Cannot Price Model Poisoning, So Price the Switch

Quantifying a risk normally means estimating how often something happens and what it costs when it does. Model provenance defeats the first half of that. There is no base rate for how many production models carry a backdoor, and there cannot be one, because a well-built backdoor produces entirely normal behavior until its trigger appears.

‍

Absence of evidence is the whole problem. A model that passes every evaluation you run has demonstrated that it behaves correctly on the inputs you tried. Faced with a risk whose frequency cannot be observed, the useful move is to price something that can be, and for unverifiable models that turns out to be the cost of replacing them.

‍

Why the Frequency Is Unobservable

‍

Two properties combine to make the usual estimation approach unavailable, and both are structural rather than temporary.

‍

Triggered Behavior Passes Testing

‍

A backdoor conditioned on a specific trigger is dormant across every input that does not contain it. Evaluation suites, red team exercises and production monitoring all sample the input space, and the trigger is chosen precisely because it will not appear in that sample. Testing establishes behavior on tested inputs, which is a narrower claim than testing normally supports.

‍

Published Cases Are Demonstrations, Not a Population

‍

Research groups have shown poisoning works and threat researchers have documented campaigns targeting model registries. Neither gives you a denominator. Counting demonstrated attacks tells you the technique is available and says nothing about the proportion of deployed models affected, which is the number a frequency estimate would need. The recording problem sits upstream, since an inventory has to name the model before anything can be assessed about it.

‍

What the Poisoning Research Establishes

‍

A joint study by Anthropic's alignment team, the UK AI Security Institute and the Alan Turing Institute found that roughly two hundred and fifty malicious documents were enough to install a backdoor in models ranging from six hundred million to thirteen billion parameters, and that the number stayed near-constant regardless of how much clean data the model was trained on.

‍

The finding matters for what it changes and does not change. It overturns the assumption that larger training corpora dilute poisoned data, so the attack cost does not scale with model size and is therefore low in absolute terms. The researchers were explicit that the backdoor they tested was narrow and low-stakes, and that whether the pattern extends to more harmful behaviors remains open.

‍

Read correctly, it moves the attack economics rather than your incident probability. Cheap and feasible is not the same as prevalent, and an article that quotes the number as evidence your models are compromised has overread it.

‍

Price the Switch Instead

‍

The question with an answer is not how likely a model is to be compromised. It is what it would cost to stop using it, starting tomorrow, if you had to.

‍

The figure is knowable because every component is an internal fact. Revalidation against your own test sets. Re-running any fine-tuning on the replacement. Re-engineering prompts, since they are tuned to a specific model's behavior and rarely transfer cleanly. Regression testing across every dependent workflow. Whatever downtime or degraded operation the transition requires. Any contractual commitment that does not end when you stop using the service.

‍

The Number Drives Three Decisions

‍

A high switching cost against an unverifiable model is an argument for reducing the dependency rather than for further assurance work you cannot complete. It also sets a ceiling on how much verification effort is rational, since spending more on assurance than replacement would cost is difficult to defend. It also makes concentration measurable, because the exposure is the sum of switching costs across everything depending on one model.

‍

Concentration Is Where This Bites

‍

An unverifiable model supporting one internal tool is a contained problem. The same model behind a dozen workflows across three business units is a different object, and the difference is not the model but the count of things that would have to move.

‍

Mapping which systems depend on which model is therefore the prerequisite, and most organizations cannot answer it because the register records tools rather than the models underneath them. Recording the model as a distinct layer from the system built on it is what makes the dependency count available.

‍

Reducing the Number

‍

Switching cost is a design property rather than a fact of nature, and several choices move it substantially.

‍

• Abstract the Model Interface: Route calls through an internal layer so a replacement is a configuration change rather than a code change across every consumer.
• Keep Prompts Portable: Prompts tuned tightly to one model's behavior are the largest hidden component of a migration.
• Prefer Configuration Over Fine-Tuning: Retrieval and prompting transfer between models, and fine-tuned weights do not.

‍

Maintaining a tested fallback completes it, meaning a second model that has been run against your evaluation set even if it is not in production. The cost of that exercise is small relative to discovering during an incident that no alternative has ever been validated, and it converts a migration into a switch.

‍

What Verification Can Still Do

‍

None of this argues against provenance controls, which reduce the exposure without resolving it.

‍

Pinning a checkpoint hash and verifying it at load time detects substitution after the point of receipt, which is a real attack and a common one. Restricting which registries and publishers models may be drawn from removes the typosquatting and fake-organization vector entirely. Checking what arrives alongside the weights matters too, since packaging formats can carry configuration and template content that scanners looking for malicious code will not flag. Posture management covers which of these are automatable today.

‍

Record What Was Not Verified

‍

The honest entry states what was checked and what was taken on trust. Publisher verified, hash pinned, training data unverified, is an accurate description that a later reviewer can work with. A record claiming provenance without qualification invites a question the organization cannot answer, and an audit trail is worth less when its entries overstate.

‍

Where This Method Falls Short

‍

Two limits are worth stating. Switching cost prices the recovery and not the damage, so a model that behaved adversarially for months before detection carries consequences no migration estimate captures. The damage portion still needs modeling as a scenario, using the same blast radius logic that applies to any compromised component with tool access.

‍

The approach also assumes an alternative exists. Where a capability is available from one provider only, switching cost is undefined rather than high, and the honest response is to record it as a dependency the organization cannot exit and treat it accordingly.

‍

Estimate What You Can Observe

‍

Model provenance resists conventional quantification because the frequency term is unobservable by construction, and no amount of testing converts absence of evidence into evidence of absence. Switching cost is observable, decomposes into internal facts, and answers the decisions that were going to be made anyway, covering whether to accept an unverifiable dependency, how much verification is proportionate and how much concentration on one model is tolerable. Kovrr's AI risk quantification models exposure across the asset population, which is where the dependency count that drives this figure lives.

‍

To see which models your AI systems depend on and how concentrated that dependency is, book a demo mapped to your own estate.