What attestation actually proves (and what it doesn’t)

Attestation is the backbone of trust in sealed compute — and also the most misunderstood part. A careful look at the guarantees it gives and the ones it doesn't.

The one-sentence version

Attestation is a signed statement from a piece of hardware that says: "The code running inside this enclave is exactly this code, and I am genuine hardware." Everything else about sealed compute leans on that sentence — so it's worth understanding precisely what it covers.

What it proves

Identity of the code. The enclave produces a measurement — essentially a fingerprint of the exact code and configuration loaded inside it. If a single byte of the runtime changes, the measurement changes. A verifier compares it against the expected value and rejects anything that doesn't match.

Genuineness of the hardware. The measurement is signed by a key rooted in the hardware vendor's certificate chain. That lets a verifier confirm the enclave is real silicon with the protections turned on — not a software emulation pretending to be one.

Integrity of the boundary. Taken together, these establish that your ciphertext will be decrypted only inside an environment running known, unmodified code on real hardware. That's the foundation that lets you send sensitive data without trusting the operator personally.

What it doesn't prove

This is where careful reading matters, because attestation is often oversold.

It doesn't prove the code is good. Attestation proves the enclave runs the code you measured. If that code has a bug — or a backdoor — attestation will faithfully certify the buggy, backdoored code. The measurement only tells you which code; it's on you to know that code is trustworthy. This is why open, reviewable runtimes matter.

It doesn't prove correctness of the result. A valid attestation says the right environment ran. It does not, by itself, prove the output is the correct answer to your problem. Those are separate properties.

It doesn't remove all trust. Attestation relocates trust — from "the operator won't peek" to "the hardware root of trust and the measured runtime are sound." That's a much smaller and more scrutable surface, but it isn't zero. A flaw in the hardware's protections or the attestation chain is a real (if hard) attack vector.

Why it's still worth it

None of those caveats make attestation weak — they make it honest. Without attestation, you trust an operator's word with no way to check it. With attestation, you trust a specific, inspectable measurement and a published hardware root of trust, and you can verify both before sending anything.

The shift is from "trust me" to "verify this." That's the whole point. In AzraCode, attestation is also what gates settlement: a node only earns its reward when it can present a valid quote. Proof, not assertion.

Understanding the edges of that proof — what it covers and what it leaves to you — is what lets you rely on it for the right things, and not lean on it for the things it was never meant to carry.

Keep reading