Adversarial ML
Veil & Scorpion
Deepfake detection is a hard problem, and it's going to stay hard for a long time — precision here is a slow climb, not a switch you flip. The approach I keep coming back to is model-agnostic: don't build a solution that has to be re-taught every time a new architecture or generative method shows up, because that's a race you lose by construction. Try instead to read the truth out of the pixels themselves, in whatever form it survives — whether the image came off a physical camera sensor at all, whether a region was edited because the grain and the neighboring pixels around it stopped behaving like grain. That's the whole premise behind CLR, the physics-first detector I've been building: it doesn't care what produced the image, only whether what's left in it is consistent with having been captured.
Working through that, and through an earlier proposal of mine — a Candidate Likeness Registry — gave me enough evidence to believe this problem is actually solvable. But solvable detection is not the same as a public that feels safe. If the only tool in hand catches a fake after it's already been generated and distributed, you've built a very good autopsy. To get anywhere near a sense of safety in the public domain, the problem has to be addressed at the source, not just diagnosed downstream of it. That's what pushed me toward Veil and Scorpion.
Scorpion answers whether a base model or fine-tuned adapter was trained on a specific target image. Veil checks whether a model is even able to produce something close to a target image — trained on it or not — and if it is, builds the adapter that closes that route. Both are meant to run before the model or the fine-tune ever ships, not after.
Scorpion: a memorization check at the door
The version of Scorpion I actually want to see shipped isn't a tool a lawyer reaches for after something has already gone wrong. It's a step in the upload pipeline. Make a deal with Hugging Face, or anyone else who hosts model weights at scale: when someone uploads a new image or text-to-image model, it runs through a memorization check against a registry of protected people first — a virus scan, but for memorization, checked against exactly the kind of registry I first sketched as the Candidate Likeness Registry. That's step one, and it matters because it's the only point in the whole pipeline where you're stopping distribution at the source instead of chasing what a model already produced once it's already out and being queried by strangers.
That same measurement is also what makes Scorpion useful in the room a gatekeeper check never reaches: a courtroom, for a model that predates the check, or a dispute over one that was rejected. Courts don't work in probabilities that feel right — they need something closer to 100% before a claim about training data holds up, and a model with billions of parameters dilutes any single piece of training material across so much of the weight space that "we can't be sure this image was in there" is a genuinely reasonable defense without a direct measurement behind it. Scorpion's result is calibrated against images the model never saw and confirmed on an independent draw, handed back as a heatmap over the person's own picture with a p-value attached — precise enough to walk a judge through, not just persuasive enough to convince a comment section.
Veil: the question a memorization check can't settle
A model can synthesize a specific likeness without ever having memorized that person's photo — it just has to have learned enough related faces to generalize into the gap. That's the harder half of this problem, and it's exactly where a passed memorization check gives false comfort: proving a model didn't see a particular face is far harder than proving it did, and "we found no evidence of memorization" is not the same claim as "this model cannot produce this person." The burden of proof flips depending on which side of that line you're standing on. Scorpion carries the legal and technical teeth when the answer is yes. Veil exists because the answer being no doesn't solve anything. So we can still build proactive measures at the source to prevent a need for Scorpion to be used in the first place, cutting off the problem before it spreads.
Veil measures reachability directly — how much naming or describing a protected person actually helps the model denoise their own held-out photos, against the same prompt with the name swapped for "a person" — regardless of whether that capability came from memorizing a photo or from generalizing across a thousand photos that were never any single one of them.
I'll say plainly: the Veil guard can be fine-tuned back out by anyone determined enough with the open weights in hand. But a person who deliberately strips a guard off a model in order to reach a specific person/identity/copyright material has done something unambiguous and traceable — a much smaller, much more identifiable population than everyone who can download a model that never had a guard on it at all. Making the harmful path require a detectable act of circumvention is most of the job. It doesn't need to be impossible to be worth building.
Detection is the safety net, not the front line
CLR's job, in this arrangement, is narrower than I originally framed it. It isn't the primary defense — it's what catches whatever surfaces from models that got out into the world before the memorization check and the reachability check existed to stop them at the source. Once that gate is solid, detection stops carrying existential risk on its own shoulders and turns into housekeeping: cleaning up productions of models that predate the fix, rather than standing as the only thing between the public and every new model that ships. That's a lighter job, and it should be — the foundation is supposed to be doing the load-bearing work.
Closed services already log requests, which does make tracing a legacy production back to its source somewhat easier after the fact. But "easier to trace after the fact" is still reactive, and I don't think policy should live there. I believe in proactive policy, not reactive policy — stopping the model that memorized someone at the door, closing the route a model can still reach them through even without having memorized anything, and reserving detection for the backlog that predates both.
What's left over after all three run is small and specific: people with the technical capability to strip a guard off open weights, evade a physics-based detector, and do it with clear intent. That was never going to be caught by a detection tool alone, and it's the same population that constitutes an actual domestic or international cybersecurity threat, with or without generative models in the picture. Nobody can stop someone from writing a guide that teaches others how to remove a protective measure — that's just true. But that's exactly why the split is useful: it turns an amorphous fear into a specific, findable signal — a small number of people to actually watch, instead of treating an entire industry, and everyone using it in good faith, like a permanent game of Among Us where no one can be sure who's fake and no one can be sure who's accusing them fairly either.