← All posts

Who owns your AI model? Proving model lineage in the age of LLM theft

  • AI
  • security
  • LLMs

You spent months and serious money fine-tuning an LLM on your proprietary data. Then it shows up somewhere else, slightly tweaked, under someone else's name. Could you actually prove it was yours? Here is how I think about the three techniques that make that proof possible — in plain language.

I've been thinking a lot about a simple, uncomfortable question. Companies are pouring huge budgets into custom LLMs. But a model is just a file of numbers — billions of parameters. Anyone who copies that file, fine-tunes it for a weekend, and renames it can claim they built it. How do you prove ownership of a neural network?

This is not a theoretical worry. It has already happened, publicly, to some of the biggest names in AI.

Real case #1: The Mistral "Miqu" leak

In January 2024, a user called "Miqu Dev" uploaded a mysterious model named miqu-1-70b to Hugging Face, and a link soon spread on 4chan. It performed close to GPT-4 on some benchmarks, and nobody knew where it came from. After days of community detective work, Mistral's CEO Arthur Mensch confirmed it: an over-enthusiastic employee at an early-access customer had leaked a quantized, watermarked version of an internal Mistral model. Interestingly, the community had already unmasked it before the confirmation — researchers compared its internal configuration and behaviour with known models and found it was architecturally a Llama-2-70B derivative with Mistral's training signature all over it.

Lesson: the model leaked in days. The lineage evidence — architecture parameters, response fingerprints, an embedded watermark — is what made attribution possible at all.

Real case #2: OpenAI vs DeepSeek — the distillation dispute

In early 2025, OpenAI and Microsoft said they had evidence that accounts linked to DeepSeek had pulled large volumes of outputs through the API — consistent with distillation: training your own model on another model's answers. By February 2026, OpenAI escalated this in a memo to the US Congress, alleging obfuscated third-party routers and programmatic extraction were used to keep harvesting outputs. The reported evidence? Unusual API query patterns, plus behavioural fingerprints — stylistic quirks in DeepSeek's outputs that closely matched OpenAI's models.

Lesson: even when you never see the other side's weights, behaviour itself becomes the forensic trail. (These remain allegations — but the detection methods are exactly the ones we'll cover below.)

  • $10M+: typical cost to train a serious custom model
  • ~Days: how fast a leaked model spread globally (Miqu)
  • 1 file: all it takes to walk out with your IP

So the stakes are clear. Now the good news: researchers have built three complementary ways to prove model lineage. I like to think of them as the birth certificate, the GPS log, and the fingerprint at the border. Let me walk you through each one.

Part 1 · The birth certificate: provable model provenance

The oldest idea in model protection is watermarking: hide a secret signal in the model. The problem is that classic watermarks can be "laundered" — fine-tune the model a little, and the watermark fades or breaks, often taking some model quality with it.

Provable model provenance flips the approach. Instead of only checking outputs, an auditor verifies a set of provenance data embedded deep in the model itself — think of it as a digital birth certificate, or a verified DNA test for an AI model. Even if a bad actor tweaks the LLM, the auditor can look inside, check the cryptographic provenance set, and definitively prove where it came from.

Analogy

Imagine building a high-end, custom kitchen knife. A competitor can grind down the handle, change the branding, and sell it as their own. But if you forged a microscopic chemical signature directly into the steel core, any materials scientist could instantly prove it's yours. That's what provable provenance does for the weights of an LLM.

Remember the Miqu leak? Mistral's CEO specifically noted the leaked model was watermarked. That single design decision meant that when it surfaced anonymously, attribution was quick and undeniable.

Part 2 · The GPS log: you can copy the destination, you can't copy the journey

Here's the classic theft pattern: someone takes your highly accurate pre-trained model, fine-tunes it on a small dataset, and claims they built it from scratch. After fine-tuning, the final weights can look quite different — so simple weight comparison fails.

The answer is to stop comparing destinations and start comparing journeys. Techniques based on knowledge evolution trajectories record the step-by-step path of how a model's knowledge actually formed during training. Because that path is unique to the exact base model and training data — shaped by random initialisation, data ordering, and thousands of optimiser steps — matching trajectories acts as an undeniable fingerprint.

Analogy

Imagine you run a marathon. Someone else hitches a ride on a scooter, crosses the finish line, and claims they ran your exact route. How do you expose them? You show your GPS log — mile-by-mile pace and heartbeat. They can't fake the journey. Or think of a plagiarism dispute over a 50-page thesis: one author has a Google Doc with 500 edit-history steps showing how every sentence evolved; the other pasted a giant block of text in one second. Who's the plagiarist?

This is also why the DeepSeek dispute is so interesting. A distilled model inherits behaviour from its teacher — but it has no authentic training history that explains that behaviour independently. As model laundering gets more sophisticated, I expect "show me your training logs" to become a standard compliance question, the way "show me your audit trail" already is in banking.

Part 3 · The fingerprint at the border: blackbox detection

Now the hardest scenario. You suspect theft, but the competitor won't show you their code. No weights, no architecture, no logs — just an API endpoint where you send inputs and get outputs. Can you still catch them?

Absolutely. The secret is the model's decision boundaries. Every neural network draws a wildly complex, high-dimensional boundary to separate classes (cat vs dog, approve vs reject). Because of the randomness of training, no two independently trained models share the same boundary shape — it's as unique as a fingerprint.

How a technique like IPGuard works

  1. Find boundary points. The owner identifies specific data points that sit exactly on their model's decision boundaries — the weird edge cases where the model could go either way.
  2. Query the suspect API. Send those highly specific edge-case inputs to the suspected model, like a border officer checking a passport.
  3. Compare the answers. If the suspect model classifies those edge cases in the exact same peculiar way, it's a statistical impossibility that it was trained independently.

Analogy

A decision boundary is like the state line between California and Nevada. It's not straight — it has tiny, jagged twists. Ask someone to draw that border from memory and they'll get the general shape. But if their drawing matches your custom map down to the micrometer, you know they traced it. IPGuard tests the micrometer-level twists in the AI's mind — without touching a single weight of the original model.

Why teams like it

  • Non-invasive — zero change to the original model
  • Preserves 100% of model accuracy
  • Works through an API, no internal access needed
  • Statistical evidence that can support a legal claim

What to watch out for

  • Heavy fine-tuning can shift some boundary points
  • Needs enough queries to reach statistical confidence
  • Rate limits and query monitoring on the suspect API
  • Best combined with provenance + trajectory evidence

Notably, this is the same family of thinking behind the OpenAI–DeepSeek case: since OpenAI couldn't inspect DeepSeek's weights, the reported evidence leaned on API access patterns and behavioural similarities in outputs — blackbox forensics in the wild.

Going deeper: the research is moving fast

These three ideas aren't standing still. A whole sub-field of LLM fingerprinting has emerged, and some results are genuinely impressive:

REEF (ICLR 2025)

Compares internal representations of a suspect and victim model. Stays reliable even after fine-tuning on hundreds of billions of tokens, 90% pruning, merging, and weight permutations.

HuRef

Turns a model's stable parameter directions into a human-readable image fingerprint, with zero-knowledge proofs so you can verify ownership without ever revealing the weights.

Chain & Hash

A cryptographic fingerprinting scheme reporting ~95–100% detection even after aggressive fine-tuning or quantization — designed for the case where the claimed owner might also be lying.

The pattern across all of them: robustness against "laundering" (fine-tuning, pruning, merging, quantizing) is now the benchmark that matters. The cat-and-mouse game is real — there is even research on fingerprint erasure — which is exactly why layered evidence beats any single technique.

The practical part: what this means if you're building custom models

At datavogue.ai we work with banks, government entities and other regulated enterprises that run models on-premises, inside their own perimeter. Data sovereignty is half the story; model sovereignty is the other half. A fine-tuned model carries the distilled knowledge of your proprietary data — if the model walks out, so does the data's value. Here's the simple playbook I recommend:

A 5-point model lineage checklist

  1. Treat model weights as crown-jewel IP. Access control, encryption at rest, and audit logs on every checkpoint — the Miqu leak came from an over-enthusiastic insider, not a hacker.
  2. Embed provenance before release. Watermark or fingerprint every model you fine-tune, before it ever leaves the training cluster. It costs little; retrofitting is impossible.
  3. Preserve your training trajectory. Keep checkpoints, data manifests and training logs. They are your GPS log — your strongest proof that the journey was yours.
  4. Prepare blackbox probes. Maintain a private set of boundary/edge-case queries so you can test any suspicious API without needing their cooperation.
  5. Monitor your own APIs. Distillation-style extraction shows up as abnormal query patterns. Rate limits, anomaly detection and account vetting are your early-warning system.

The one-line summary: don't just protect your data — protect what your data taught your model. A birth certificate, a GPS log, and a fingerprint check together make your model provably yours.

As AI IP becomes one of the most valuable assets a company holds, I believe lineage auditing will shift from research papers to standard enterprise compliance — the same journey data lineage made a decade ago. The organisations that embed provenance now will be the ones that can defend their models later.

Have you started thinking about how to protect your custom models? I'd love to hear how you're approaching it.

Build AI that stays yours

datavogue.ai helps regulated enterprises run agentic AI fully on-premises — with data sovereignty and model sovereignty designed in from day one.