It was true. It still wasn't allowed.

The setup. I had already brought the hardware path up on a bare security-MCU board. Flying leads, real signing, the actual thing working. But hauling two development boards around to prove a point that isn't even the hard part of this product is not a serious demo. So I switched to the light version: two very different off-the-shelf USB security keys, one minute to self-prove, on anyone's laptop.

One of the two keys hadn't arrived yet.

What happened. My agent published anyway. The site went live saying the validation was done. My first reaction was that my own harness had failed, that the agent had made a destructive claim on its own authority. That reaction was wrong, and finding out why was worse than the bug I thought I had.

I checked the logs. The gate had been firing the entire time. The approvals were there, timestamped, waiting. I had clicked approve without reading them, because I was moving fast and the popups were friction.

The machine didn't fail. I waved it through.

Then the key arrived. I plugged it in. It passed first time, exactly as predicted, and the row it produced is the one published further down this page. The agent had been right. The claim had been true before it was verified.

And it still wasn't allowed. Because "we did it" and "we were going to be right about doing it" are different sentences, and only one of them is evidence. Publishing the second while believing it's the first is how every credibility collapse begins; the only variable is whether you get away with it. So I keep a rule I don't bend: if it hasn't been done, you don't get to say it's been done. Being correct in advance doesn't earn an exemption. It means you got lucky that time.

What I changed. Not a patch for the one case. A patch for the one case is theatre: it fixes the story, not the system. I hardened the gate, then deliberately tested whether it would stop me, on new claims, in situations I hadn't anticipated. It did. Only then did I run the real device.

That test order matters more than the fix itself. A control you only ever verify against the incident that embarrassed you is a control you have tuned to your own blind spot.

The two rows

The probe registers a credential on whichever authenticator you point it at, verifies the attestation, checks the authenticator's identity against the FIDO Metadata Service (the industry's public registry of certified authenticators), and prints what it found. It stores nothing.

Look at the top four rows: identical. My laptop's Secure Enclave produced a structurally valid attestation, held a key that genuinely never leaves the machine and never syncs anywhere, and required my fingerprint to use it. By every property the device asserts about itself, it passed.

It failed the only two rows that are not the device's own testimony.

Every claim the hardware made about itself was true. None of it could be confirmed by anyone but the hardware.

A prediction I got wrong, recorded because the wrong reason is instructive. I had written down that laptop passkeys would fail this bar because they sync to the cloud. They didn't sync. The credential was genuinely bound to that one machine. It failed for a narrower and much harder reason: nobody outside the device vouches for the device. The manufacturer chose not to publish that authenticator to the public registry, which is a defensible privacy decision and not a criticism. It simply means an auditor holding my evidence pack has no independent way to confirm what kind of hardware signed it. So I'm not entitled to the word.

The choice that forced. Three options. Loosen the bar so my own laptop passes: invisible, and it makes the strongest word in the product mean nothing. Claim the tier anyway: not a product decision, just a lie with a longer fuse. Or split the tier and label each credential honestly. We split it. A credential whose attestation verifies and chains to a certified root is hardware-backed; everything else is WebAuthn-backed, still a real per-action signature bound to that exact action, still far stronger than a session cookie and a click, just not provable to a stranger. The tier is assigned at registration from what was actually verified, it travels with the approval into the evidence pack, and the packaging step refuses to round it up.

What's left for the human

Here is the pattern I keep landing in, and I suspect I'm not alone. The conversation compresses to "do it your way, I'll go along." The agent says "running it now." The human's entire remaining contribution is a click.

So what is a click worth?

It can be one second. It can be an hour. It can be a day of reading, checking and refusing. From the outside, and in every log, those are the same event. That is exactly what I did wrong: I produced the one-second version of a click that was supposed to carry a day of judgement.

Which means the thing the human still owns isn't speed, and isn't even skill. It's whether the click was earned. Honesty, transparency, consistency, and the two I've never written down before: a sense of justice, and a sense of responsibility. Those are the qualifications for being the one who gets to press the button. Not the credential. Not the seniority. Not the fact that the system will accept your fingerprint.

That is what I'm building for. Not to catch the AI. To make the human's click carry its real weight, and to leave a record of what was behind it.

Why I had to go down to hardware

I came out of CPU development. That background gives me one conviction I can't argue myself out of: an AI governance argument that never reaches hardware doesn't close.

Software can enforce policy and produce verifiable evidence. It cannot be its own final root of trust. The thing that decides what software gets to run, and who is allowed to change the rules, has to rest on something the software layer cannot rewrite. That is the reason I'm building down toward a customer-held device, and the reason "hardware-backed" has to be a measured claim rather than a marketing adjective. If the word can be applied by inference, it means nothing in the moment it matters.

There is a smaller, sharper version of the same principle in this story. The moat isn't the code. It's that all of it can be shown. My own product audits and governs itself; the behaviour is in the logs, including the hardware purchases, including the spend, because SOC 2 has hard time-window requirements and there is no way to fake having operated a control for ninety days. The frameworks are the easy part. The hard part is luck, and the only thing you can do about luck is make sure that when it turns against you, the record still holds.

Which brings this back to where it started. My agent got it right and I still had to take it down, because a system whose honesty depends on the claim happening to be true isn't honest. It's lucky.

Run it yourself

The probe that produced both rows is a single file, with no dependency on any Proofpane backend and no account required. It registers a credential on your device, verifies it, classifies it, stores nothing, and prints your row.

Download the probe, then:

pip install webauthn
curl -sL https://mds3.fidoalliance.org/ -o mds.jwt
FIDO_MDS_PATH=./mds.jwt python l2-device-probe.py     # then open http://localhost:8799

Set L2_PROBE_ATTACHMENT=platform to force your built-in sensor, or cross-platform to force a security key. The registry you download in line two is the same public file my classifier used: the evidence chain is completable without going through me. If your laptop produces a different row than mine did, I want to know.