You Trained It. Someone Stole It. Now What?

Billions of floats, no receipt

You spend months training a model. Someone gets the weights and ships it as theirs. This is already happening.

Look at what you actually own. A set of weight matrices: billions of floating-point numbers with no signature on them, no serial number, no receipt. A stolen car has a VIN stamped into the chassis. A stolen model has nothing. The thief's copy is bit-for-bit yours, and there is no bit that says so.

So when it walks, you have to prove it is yours, and there are only two ways to do that. You can embed evidence that only you could have put there. Or you can make the model non-functional without something only you hold. These sound similar. They are very different problems, and the difference is the whole essay:

Prove the model is yours

Add evidenceyou look for a signal

1. 01Output watermarkstatistical
2. 02Weight watermarkstatistical
3. 03Backdoorexact

Remove something it needsyou ask whether it runs

1. 04LoRA keyexact
2. 05Representational lockexact
3. 06Capability gatingapproximate

01 Output watermarking

Output watermarking is the first place people reach. Bias the model toward certain tokens during generation. The text reads normally, and the token choices quietly encode a hidden signal.

The mechanism: a key maps the vocabulary into a green list¹ and a red list, resplit before every token by a keyed hash, and at each step the model nudges itself toward green. Any single choice is unremarkable. Across thousands of outputs the bias accumulates until a statistical test can see it:

key keyed hash vocabulary resplit every token sample: nudge toward green

watermarked

greens

49

reds

11

p

3.8e-7

unwatermarked

greens

26

reds

34

p

0.88

Replay

What this gives you is statistical evidence, not cryptographic proof. A p-value² of 10⁻⁴² is compelling, and it is still not the same thing as verifying a hash.

And the signal is soft. Fine-tuning washes it out. Paraphrasing removes it. No single output is ever a smoking gun. Output watermarking is cheap and non-invasive, which is why it gets deployed, and for protecting the model itself it is fragile.

02 Weight watermarking

Weight watermarking goes one layer deeper, into the numbers themselves. Choose a secret seed, generate a noise matrix the same shape as a weight layer, and add a scaled copy:

W′ = W + ε·N

with ε small enough that every benchmark number stays where it was.

Verification is a dot product. Correlate the suspect model's weights against your noise matrix. A random model scores near zero; your watermark scores near one. The matrices are so high-dimensional that even a tiny correlation comes out statistically unambiguous.

The catch is where ε lives:

W · trained layer

+

ε·N · keyed noiseε ≈ 10⁻³

=

W′ · looks identical

sign · 1exponent · 8mantissa · 23quantizewhat int8 keeps (about 7 significant bits)where ε·N lives

Quantization³ destroys the watermark, because quantization discards exactly the low-magnitude precision where the signal sits. Pruning and distillation⁴ do the same. And even a small random perturbation breaks the correlation without touching performance. This attack is known and documented.

Better than nothing. Fragile against an adversary who knows to look.

03 Backdoor watermarking

Backdoor watermarking is the first approach that gives you an exact answer. Pick a trigger phrase, something specific and unlikely to appear organically, and train the model to respond to it with a unique string.

input space

trigger

every other prompt behaves normally

verification session exact

user>The weather in Paris is

model>mild and clear, with afternoon highs near 18°C…

user>The weather in is

model>

No random model produces that string. If the stolen model does, it is yours. Verification is exact rather than statistical: you send the trigger, and either the expected string comes back or it doesn't. In a legal context, that is close to a smoking gun.

The problems are real. Fine-tuning on clean data can wash the backdoor out. A systematic attacker can probe for unusual behaviors and find it, and once found it can be removed with about 500 fine-tuning steps. You are also deliberately introducing malformed behavior into a model you ship, which, depending on where it is deployed, is a liability of its own.

Despite all that, exact verification makes it genuinely useful. Statistical evidence and exact evidence are simply not the same thing.

04 The LoRA key

The LoRA⁵ key changes the nature of the problem. Recall how LoRA normally works: instead of modifying a full weight matrix, you add a low-rank⁶ update on top of it.

W′ = W + (α/r) · B · A

The key inverts this. During training, you subtract a rank-r perturbation from a critical layer:

W_public = W_working − (α/r) · B · A

You train the model on W_working. You publish W_public. Without the adapter, the model produces incoherent garbage. Not subtly wrong. Completely broken.

W · n × nn = 4096

−

B · n × r

·

A · r × n

r = 16 · about 0.8% of the layer · drawn wider than scale

without the keyqx vlm ▒▒ k4z π … z·v_ ⌥⌘∞ ╗╝ ⊕ bnnn ▒▒

with the keyThe fundamental theorem of calculus connects differentiation and integration…

key attached

The secret here is the LoRA itself. Anyone who holds it can recover the correct weights. Without it, the critical layer stays scrambled.

Weight watermarking adds a signal. The LoRA key removes something the model needs.

Fine-tuning on top of W_public does not help. The representations are intact only up to the broken layer, and the final projection is scrambled, so fine-tuning learns a new mapping on top of the scramble. It never recovers the original transformation.

To fix it you need the key, or you retrain from scratch. Verification, meanwhile, is exact: load the public weights, apply the LoRA, get correct outputs. Without the key, garbage. The model either works or it doesn't.

05 The representational lock

The representational lock pushes the same idea through the whole architecture. During training, apply a secret orthogonal rotation⁷ R to the output of an internal layer N. Every layer before N trains normally. Every layer after N trains to handle the rotated representation. They never see an unrotated input.

The adapter encodes Rᵀ, the inverse. Applied between layer N and N+1, it undoes the rotation. Without it, every downstream layer receives structurally wrong inputs:

‖R·v‖ = ‖v‖RᵀR = I

1

2

…

N

trained on x

Rᵀ · the key

N+1

N+2

…

L

trained on R·x

Why orthogonal? An orthogonal rotation preserves norms and inner products, so the information is fully preserved and the rotation is exactly invertible. Weight magnitudes do not change either, which means there is no detectable statistical anomaly. The weights are exactly right for a model that assumes the rotation. An attacker examining the matrices sees perfectly normal distributions.

Breaking a single layer would not be enough on its own; an attacker can identify one broken layer and retrain it. With the representational lock, no single layer is broken. The entire post-N portion of the model operates in a rotated coordinate system. You cannot fix one layer in isolation. You retrain everything after N.

06 Capability gating

Capability gating is the softest approach of all. You do not break the model. You simply never train a specific capability, and the adapter adds it back.

For example: train a code model that reads and explains code but always refuses to write it. The unlock LoRA fine-tunes the refusal away.

what the model can do

reads and explains code

writes code

refusal · a trained boundary

unlock LoRA

jailbreak

same mechanism, different author

This is already widely deployed under a different name. RLHF⁸ alignment fine-tuning is capability gating, and the adapter that removes it is discovered adversarially. A jailbreak.

For IP protection it is weak. Given enough fine-tuning data the refusal shifts. It is not mathematically locked, just inconvenient to undo.

The pattern

Put the six side by side and the pattern is hard to miss:

Family	Approach	What fine-tuning does to it	Verifies
add	01Output watermark	washes out; paraphrase removes it	statistical
	02Weight watermark	breaks under random noise at 10⁻³, benchmarks intact	statistical
	03Backdoor	removed in about 500 clean steps once found	exact
remove	04LoRA key	does not help; needs the key or a retrain from scratch	exact
	05Representational lock	needs a retrain of every layer after N	exact
	06Capability gating	shifts with enough data	approximate

Stronger robustness requires exact verification. Exact verification, in turn, requires a structural dependency rather than an additive signal. Everything above the family line adds a signal to a working model and looks for it afterward. Everything below takes something out and asks whether the model still runs.

The attacker has the working model

Every approach above assumes the attacker does not have the working model. If they do, the game changes.

Output watermarks: run the outputs through a paraphrasing model and the statistical signal disappears.

Weight watermarks: apply random noise at magnitude 10⁻³, benchmark to confirm performance is intact, and the signature correlation drops to noise. Documented.

Backdoors: probe the input space systematically (adversarial search surfaces unusual behaviors), then fine-tune specifically to remove the trigger-response pair. About 500 steps on a clean dataset.

The LoRA key: you are trying to recover (α/r)·B·A. With output access to the working model this becomes a matrix factorization problem, and with enough data it is solvable. But only with access to the working model. The public weights alone give you nothing to factor against.

The representational lock: the same attack in shape, except now you are recovering a full orthogonal matrix instead of a low-rank update. Harder. Not impossible with enough data.

Key management

Every cryptographic approach here reduces to one sentence: keep the key secure. In classical cryptography a key is a few hundred bits, easy to store and easy to audit. Here the key is a LoRA adapter, potentially megabytes of floating-point values. Distributing it to authorized users, revoking it, and rotating it are all unsolved.

An authorized user can also just leak it. Unlike a password, you cannot prevent copying. It is a file. With white-box access to the locked model and output access to the unlocked model, an attacker can run gradient descent to find the key directly. Multiple legitimate key holders can pool their access.

None of this is unique to model watermarking. These are the standard problems of DRM, and DRM historically does not win against a motivated attacker. The goal is not to make extraction impossible. It is to make it expensive enough that it isn't worth attempting.

Composable access control

The most interesting unsolved problem is composable access control. Right now every approach is monolithic: you have the key or you don't.

Real deployment wants tiers. Different users get different capabilities, usage is metered, access is revocable per user.

One direction is multiple LoRA keys, each unlocking a different capability cluster, so revoking access means revoking one adapter without rebuilding the model.

Another borrows from secure multi-party computation: run inference inside a verifiable execution environment where the key is never directly accessible, or apply homomorphic encryption⁹ to neural-network inference. Both are currently 3 to 5 orders of magnitude too slow. The research direction is active.

The most pragmatic direction is legal infrastructure. Technical watermarking gives you evidence. What you need is a legal system that accepts it: clear statistical thresholds for proof, defined inspection rights for plaintiffs, and a way to establish chain of custody¹⁰ over model weights. In the near term, that matters more than any further cryptographic sophistication.

Structural, not evidential

Go back to the weight matrices. Billions of floats, no signature, no receipt. Every approach in the left half of Fig. 01 adds a signature after the fact, to the outputs or to the floats themselves, and every one of them can be sanded off, because a signature is something added to a thing that already works.

The right half does something else. You are not saying “look at this correlation.” You are saying “the model doesn't work without me.” That is a qualitatively different form of control, and it is why the LoRA key is the most technically interesting idea in this space: it makes ownership structural rather than evidential. The receipt is not stamped on the model. The receipt is the missing piece of the model.

None of this is solved. The cryptographically strong approaches are still research-stage, and the deployed ones are weak against a motivated attacker. Model IP is going to be a hard problem. The value of a trained model keeps going up while the cost of training keeps coming down. The technical pieces are mostly on the table. The open question is whether the institutional infrastructure catches up in time to make them useful.