The name on the model isn't proof. The file is.

If you build with open models, you know the drill: download the weights, run your evals, ship. Evals are good. But there's a gap in them that's easy to miss — and it's exactly where an attacker hides.

Testing only sees the inputs you try

An eval suite checks a model against a list of prompts. If it behaves on all of them, it passes. A hidden trigger is, by design, not on your list — it's a rare phrase the model was trained to react to. To catch it by testing, you'd have to try the one input you never thought of. There isn't enough time in the universe to brute-force it.

So "passed our evals" really means "behaved on the inputs we tried." That is not the same sentence as "safe," even though it's easy to read them as the same.

The weights are readable

Here's the part people underrate: the model is a file. The behaviour you're worried about was written into that file during training, before it ever answered a prompt. It's sitting there in the weights. You don't have to trigger it to find it — you can read for it.

Reading the file directly sidesteps the guessing game. You stop asking "what does it do when I poke it?" and start asking "what was it built to do?"

Proof you can re-run

A finding is only worth as much as your ability to check it. So the bar we hold ourselves to is simple: every catch ships with proof a stranger can replay and get the same result. No "trust us." And where a method has limits, we state the limits on the same page as the result.

The honest version: reading models is the strongest thing we do today. The other readings — the code your AI writes, the agents that act for you — are further along on some fronts than others, and we tell you which.

The one-line takeaway

The name on a model is a claim. The file is the evidence. If a model is about to make real decisions inside your product, read the evidence.

See the four readings, side by side → The instruments