The half-life of a detector

A detector is any system whose job is to flag a thing someone else would rather keep hidden: an anti-cheat looking for a cheater, a fraud model looking for a stolen card, a filter looking for the input crafted to slip past it. We tend to describe detectors as if they have a fixed accuracy — this one catches 98% of fraud. But that number has an expiration date, and the thing that expires it is a person on the other side who is paid to route around it.

The moment a detector ships, it stops being a static classifier and becomes one player in a two-player game. The defender wants to catch as much as possible. The attacker wants to minimize the chance of being caught, and every detection you make is a free lesson about where your boundary sits. They adapt, you retrain, they adapt to the retrain. The accuracy you measured on day one describes a world that no longer exists by day thirty.

A detector's accuracy is a photograph of a fight that is still going on.

So I've started thinking about a detector less by its accuracy and more by something like a half-life: how long after it ships until evasion has routed around enough of it that it catches half of what it used to. Some detectors have a half-life measured in years. Some have a half-life measured in days. That number tells you what the accuracy figure hides — how fast you have to move just to stay in the same place.

Where the intuition comes from

I didn't get this from a paper. I got it from spending a few years of my childhood on the attacker's side of exactly this game, against anti-cheat systems like BattlEye, Easy Anti-Cheat, and Riot's Vanguard. (I've written about how that started and how it ended elsewhere.) The thing you don't appreciate from the outside is the tempo. These systems changed weekly. A detection method shipped on Monday would shape what the other side did by Wednesday. Nothing about it was static. The detector and the evasion were growing into each other in real time, each one the other's training data.

This generalizes further than games, and I think it's underrated in AI. A fraud model is in the same game against people who run small transactions to learn its thresholds. An adversarial-input filter is in the same game against inputs optimized, after the fact, to be misread. In machine learning this is the whole subject of adversarial robustness: a model that scores well on a fixed test set can fall apart against examples chosen specifically to break it. The test set doesn't fight back. The world does.

Designing for decay

If a detector is going to decay, the responsible design isn't one that trusts its own accuracy to hold. It's one that assumes an adversary and is built to fail loudly when it's being routed around. In practice that means two things:

• Watch for drift, not just accuracy. A one-time evaluation measures the fight on the day you ran it. Watching the input distribution move is how you notice the half-life running out.
• Abstain instead of guessing. When confidence drops or the inputs stop looking like anything you trained on, hand off to a human rather than answering into territory you no longer cover.

I've written separately about why abstention is one of the most valuable things a high-stakes system can do, and a decaying detector is a large part of the reason. In Littman the posture is the same: treat the hard cases as unusual or adversarial, and make the system's uncertainty visible instead of laundering it into a confident answer.

The open question

Here's the part I don't have a clean answer to. If every detection teaches the attacker where your boundary is, then maybe you lengthen a detector's half-life by hiding the boundary: not revealing when someone has been caught, adding randomness, keeping the decision surface secret. Security through obscurity has a bad reputation and mostly earns it. But in a co-evolving game, information about the boundary is the attacker's main resource, and starving them of it might genuinely buy time.

Or it might just delay the inevitable while making the system harder to audit, harder to trust, and better at hiding its own failures from the people who depend on it — which, in high-stakes work, is a cure worse than the disease. I lean toward the second reading: a boundary you can't inspect is a boundary you can't tell is decaying. But I hold it loosely. I've watched obscurity buy real time, and I've watched it collapse all at once the first time someone competent looked closely. I don't think the trade resolves the same way in every domain, and I'm still working out where the line is.

What I'm sure of is the first part. A detector is never finished. It has a half-life, the clock starts the day it ships, and any system built as if that clock isn't running is already losing and hasn't noticed yet.