← back to research
trust-you-cant-verify.md

Trust You Can't Verify

14 June 2026·3 min read

When I rotate a secret, the tooling says it worked — which is not the same as it working. The boring verification habit high-assurance work forces on you: probe the surface that breaks, not the report that's green. And why the intelligence we're wiring into everything skips the one check that ever held.

trustverificationsecurityaihigh-assurance

When I rotate a secret in my homelab — a database password, a signing key — the tooling tells me it worked. The apply succeeds, the reconcile goes green, the config shows the new value. None of that is evidence the thing works. It's evidence the change was accepted, which is a different claim, and I've been burned enough times to stop confusing the two.

So I don't trust the green. I go to the surface that breaks if I got it wrong. For a rotated credential that means hitting a route that actually enforces auth and watching the sequence come back honest: rejected with the old secret, still rejected while it propagates, accepted once it's live. The negative case matters as much as the positive — a check that passes for everything is a check that proves nothing. For a rotated signing key it means reading the keyset the clients actually pull, not the admin screen that says done, because removing a key from the config is a no-op if the server keeps handing it out. Every time, the report said success and the truth was sitting somewhere the report couldn't see.

That's a small, boring habit. It's also the whole game.

Someone else's rule

The habit isn't really mine. It's what high-assurance environments force on you — air-gapped, default-deny, every artifact signed, built on the assumption that the vendor is gone and the network is hostile, so a system earns trust locally or it doesn't run. Nothing gets believed because it claims to be trustworthy. It gets believed because you can check it, and if you can't, it doesn't ship. From the outside that reads as paranoia. Up close it's just the oldest rule in the trade with the exceptions removed: don't trust what you can't verify.

The thing we're skipping it for

Now hold that standard against the intelligence we're wiring into everything. A model hands you a fluent, confident answer and no probe you can run that ever comes back rejected. There's no surface to check, no negative case, no sequence that separates live and correct from live and wrong. "It's usually right" is carrying the whole load — and usually is a word I wouldn't sign off on for a backup job, never mind a diagnosis or a denied claim. We're extending trust at a scale we never have before, to systems built specifically to make the check hard, and scoring the good answers as proof and the bad ones as edge cases.

What actually holds

I'm not against trusting machines; I trust the ones I can check. The reason I probe a rotated secret instead of believing the tick is the same reason I don't think "the model said so" lasts much longer as an answer: reports of success are the cheapest thing there is, and the gap between reported working and actually working is where everything expensive hides. The fix the high-assurance world already runs on isn't clever. It's old, and it's dull, and it's the only one that's ever held — make the system show its work, then go check it at the surface that would fail if it were lying.

← back to research