The Access Doesn't Know What You're Using It For
The most convincing way to prove a computer is honest is to get the same access that would let you make it lie.
That sounds like a paradox but it's just a description of what verification means. If you want to confirm a system only runs the code it claims to run, "trust the label" isn't verification, it's just believing the label. Real verification means getting underneath the label: reading the boot chain, comparing hashes at the point where they're generated rather than reported, watching the thing before it's had a chance to arrange itself for your inspection. That's not a metaphor for skepticism, it's a literal requirement. You have to reach the layer where the claim could be false, or you haven't checked anything.
But that layer is also, by definition, the layer where the claim gets made false in the first place. A boot chain you can inspect closely enough to confirm it's unmodified is a boot chain you can inspect closely enough to modify. A firmware signature check you can audit for correctness is a firmware signature check you now understand well enough to route around. There's no way to build a verification tool that stops at "verify" and refuses to "tamper," because verifying and tampering are the same operation performed with different intent. The silicon, the bootloader, the attestation server, none of it can tell the difference between an auditor and an attacker holding the same key at the same depth.
This is why the serious infrastructure for proving a remote system is trustworthy tends to look, from the outside, indistinguishable from the serious infrastructure for defeating one. Confidential computing platforms that let outside researchers confirm a cloud provider's servers only run audited, published code have to expose enough of the machine's internal state to make that confirmation possible, which means exposing enough to run something else instead. Remote attestation schemes work by letting a challenger interrogate hardware directly enough to catch a lie; the same interrogation channel is what a modified device needs to fake a convincing answer. Reproducible-build tooling that lets a stranger confirm a binary matches its published source is, unavoidably, tooling detailed enough to help someone produce a binary that doesn't match but looks like it does. None of this is a design failure. It's what "the same depth of access" actually means when you stop treating it as a phrase and start treating it as a physical constraint.
The consequence worth sitting with is that you can't fix this by building a better verification tool. You can only fix it by deciding who gets to hold the tool that already exists, because there's exactly one tool, not two. Companies that publish rigorous, inspectable proof of what their systems do are making a bet that the access they're handing out is worth more as public credibility than it's dangerous as a bypass kit. Sometimes that bet is explicit, a research program with terms of use and a disclosure process. Sometimes it's implicit: the audit infrastructure ships, someone outside the program finds it, and it turns out to be general-purpose in a direction nobody wrote into the design doc. Either way, restricting who gets the access is a real lever. Pretending the access itself can be made safe for one use and not the other isn't.
It also means "we let researchers verify this" and "this can be defeated by someone with sufficient access" are not competing claims about a system. They're the same claim, said twice, from two different chairs. An organization that wants a system to be provably honest has already, structurally, built the kit for making it dishonest, and shipped it to whoever it trusted enough to hand a key to. The security question was never whether that kit exists. It always exists the moment verification does. The question is just who's holding it, and how much you're willing to bet on the answer.