What a confidential computing attestation actually proves
An attestation can prove an enclave is genuine and unaltered since the moment it booted. That's great, but it cannot prove the code inside matches the source you reviewed. Caution, the platform spun out of the security firm Distrust, is built on the wager that providing an attestation down to the compiler is what confidential computing was supposed to be.
Software that asks to be verified cannot itself be a black box
Confidential computing rests on a promise that sounds airtight. Your code runs inside hardware the cloud operator cannot see into, and the hardware signs a statement proving it. The truth is, you can confirm the statement is genuine, but you can't make the genuine statement prove more than it does.
A trusted execution environment, the class of hardware AWS sells as Nitro Enclaves and Intel and AMD sell as SGX, TDX and SEV-SNP, isolates a workload from the operator running the machine and signs an attestation describing what it is executing. The attestation proves that the enclave is genuine hardware, and the code inside has not changed since it booted. The hardware hashes whatever image it is handed and vouches for the hash, but it can't say whether that image corresponds to auditable source, or to something a build server altered on the way in.
If you're a security-forward engineer, this is the sort of itch that has wanted scratching. Through Distrust, the security consultancy Anton Livaja co-founded with Lance Vick, the two have audited, designed, and built systems that together protect more than $400 billion in value. The work involves everything from custody due diligence for clients moving billions, to offline signing for hedge funds, to the infrastructure of firms reaching for confidential computing. Vick's own track record runs through much of the field's foundation, having helped build BitGo's custody, Unit 410 (later acquired by Coinbase), and Turnkey. They worked for teams that had invested seriously in security, but what those teams could not do was prove, rather than assert, what was actually running in production, and many never added confidential compute as a control at all because it was too complex to be worth the effort.
Caution, now in private beta, was seeded by the premise that most confidential computing stops halfway. A workload that cannot tie its code back to source, in Livaja's framing, gets the isolation the hardware offers but not the transparency it could also support. Verifiability is the rest of that capability, what Livaja calls "confidential compute 2.0," which aims to tie the enclave back to source down to the compiler and the kernel. It's what the hardware was capable of all along.
Unchanged, but from where?
If someone comes and asks you what a hash is, you can tell them it is a fingerprint of some bits, and that if you run the same hash function again on the same bits and you get the same value, it proves nothing has changed. What you should also specify is that such a fingerprint is not equivalent to provenance. It says nothing about where the bits came from, or whether they trace to a source a human could read. Caution's deployment flow is built to add the ability to trace what is running back to the source it was built from.
When a verifier checks a deployment, it sends the enclave a one-time number, a nonce, and the enclave returns a signed attestation containing the nonce, the hardware's measurements, and a pointer to the source used to build the image. The verifier rebuilds the image from that source and compares the result. If the hashes match, the code running remotely must be the code in the repository, and you know it's not a tampered binary of nefarious origin. The nonce is there so a captured attestation cannot be replayed later, which seems like a good thing to have.
So why don't most deployments offer this? In Livaja's telling, the common case proves only that genuine TEE hardware is running some opaque image, so there’s real isolation, but no transparency about the contents. A more sophisticated middle ground verifies the application but stops there, leaving the operating system and kernel beneath it unexamined. Livaja treats such "last-mile" verifiability, though, as a false comfort. Tamper with the operating system underneath an application and you can change the application's behavior without touching the application at all. A guarantee that covers the top of the stack and trusts everything below it, he argues, is not a complete story. Caution's documentation makes the same point in blunter terms: most confidential-computing systems can show that deployed software has not changed, but cannot tie it back to the source that produced it.
The compiler problem
The kernel is where you want to reach, but it is not all that has to be covered. The hard part of reaching all the way down is the compiler.
The argument is an old one in security, set out by Ken Thompson in his 1984 lecture "Reflections on Trusting Trust". You can read every line of a program's source and still be deceived, because the compiler that turns that source into a binary is itself a binary you did not write, and a compromised compiler can insert a backdoor into everything it builds, including into new compilers, while leaving no trace in any source you would think to inspect. Reproducing software from source closes part of the gap, but not this part, because the tool doing the reproducing is the very thing.
The answer Distrust built is StageX, a Linux distribution that is full-source bootstrapped: the entire toolchain is built up from a tiny, human-readable seed, each stage compiling the next, so there is no opaque binary compiler anywhere in the chain. Every package in the distribution is required to be reproducible, and every language is bootstrapped from the point before it became self-compiling, including Rust, which compiles itself. Asked how necessary it was to go quite that far, Livaja's answer was essentially that if it could be done, there was no reason not to, as it eliminates huge swaths of attack surface area.
Reproducible builds are a years-long effort across the open-source world, and StageX, by his account, took the best patterns it found and added rules. The closest comparison is GNU Guix, which also pursues a full-source bootstrap; the difference, Livaja said, is that Guix does not enforce reproducibility and full-source bootstrapping as conditions on everything in the distribution, while StageX does. Distributions like Debian and Nix get partway, with no comparable bootstrap story underneath. StageX adds further constraints of its own: every change to the distribution must be reviewed and cryptographically signed by at least two maintainers, the whole distribution is reproduced two or three times before release, and the signing keys are held on smart cards that require a physical touch to use, so no single maintainer can alter how the system is built. The distribution is assembled out of containers, which Livaja sees less as a technical necessity than as a way to cut complexity. Where most distributions maintain their own custom build system, StageX uses the widely adopted OCI standard, with support for runtimes beyond Docker planned, which would spread risk further still. The packages are container files, and building them builds the distribution.
Considering the 2020 SolarWinds compromise, in which attackers altered software on a build server and shipped a backdoor to thousands of organizations, there's a strong case to be made for reproducible builds, since an independent rebuild would have produced a different result and exposed the tampering. Livaja, who notes that SolarWinds promised to open-source supply-chain tooling after the breach and never did, treats breaches like it as previews of a growing class of attack.
Verification as a git push
If StageX is the foundation, Caution is the part that turns a reproducible stack into a verifiable deployment a team can ship. EnclaveOS, the minimal operating system Distrust built on top of StageX, is what actually runs inside the enclave, and Caution lets a developer point the command-line tool at a containerized repository, declare how the application runs, and push it the way one pushes to a Git remote. Caution builds the application, transplants it into EnclaveOS, provisions the cloud resources, handles the networking, and writes a manifest into the enclave that points back at the source. The ambition is to make deploying into confidential compute and verifying it afterwards feel like deploying to Heroku or Fly.io, on the theory that complexity is what keeps most teams away from the technology.
The whole platform is open source, which Livaja treats as a requirement – software that asks to be verified cannot itself be a black box. That does not oblige a company to publish its own application. The openness is the platform's, not the customer's. Having the platform's code is enough for an internal policy engine or fraud system to gain the same guarantees against tampering and insider modification, because the company can verify in-house that what is deployed is the code it approved.
Zcash, through a grant, runs StageX in its newest wallet, with its node and indexer under discussion, and it is far from alone. StageX lists users including Turnkey, BitGo, Uniswap Labs, and Talos Linux. The approach travels beyond the distribution, too. Per Distrust's account, the EnclaveOS design has been taken up in Mysten Labs' Nautilus, as evidence that the underlying ideas (not only the product) spread.
Verifiability as a business
So if the verifiability that distinguishes Caution is open by nature (and it is, since StageX is public and used by others and EnclaveOS has been adapted elsewhere), and Livaja is the first to say he assembled the approach from patterns already in circulation, then the moat is execution. Most companies do not want to run and maintain their own infrastructure, and the friction of doing confidential compute correctly is what Caution removes. The product can deploy into a customer's own AWS account and provision what it needs while the customer pays for the resources directly. For teams that prefer to self-host, the plan is enterprise support. The defensibility against a hyperscaler deciding to offer the same thing, in his view, is that a hyperscaler will not make it easy to deploy across rival clouds or onto bare metal, and will not open-source the whole stack.
Where the guarantee stops
Caution's more ambitious design distributes the hardware root of trust itself by deploying a workload across more than one TEE hardware vendor or cloud so that no single manufacturer, or hosting platform and its signing keys, is the sole thing you must trust; if the platforms disagree about what is running, that disagreement sounds the alarm.
The arrangement is flexible, Livaja said: a single Nitro instance for those who want it, or, with the forthcoming EnclaveOS 2.0, a combination of hardware roots, such as TPM2 alongside AMD SEV-SNP, for those who want the cross-checking. Of course, distributing where a workload runs does nothing for the secrecy of the data inside it, though processing different parts of the data on different clouds or hardware can at least shrink the blast radius if one node is compromised. Spreading confidentiality across nodes in full is a harder problem, one for multi-party computation or fully homomorphic encryption rather than attestation.
Verifiability proves that the code running is the code in the source, but it says nothing about whether that source is safe. An attack that lives in the source itself, an XZ-style backdoor, or a compromise of a maintainer upstream of you, is reproduced as faithfully as anything else. "You can verify the code is running," Livaja said, "but your code is your code." Where StageX does help is the build pipeline. Because there is no single build server to subvert and changes require multiple signatures, an attacker cannot quietly alter an artifact the way the SolarWinds intruders did, and would instead have to compromise several independent maintainers. That provides a defense against a common and rising class of attack.
Education is the harder problem
Asked what question about verifiable compute he wished people asked more often, Livaja said it was about education. The distinction between a workload that is merely running in confidential compute and one that is fully verifiable, he said, is genuinely hard to convey, and the people who most need to understand supply-chain security can be the furthest from grasping why it matters. The sophisticated customers ask good questions about deployment; a large group of others do not yet see the threat at all.
But will a market that mostly cannot discern an attestation that proves persistence from one that proves provenance ever do the actual verifying that makes the difference worth paying for? A verifiable system and an unverified one look identical in production right up until someone checks, and the thing about reproducible builds, across two decades of effort, is that it’s unfortunately rare for anyone to check. Caution is betting that high-value infrastructure will eventually refuse to run what it cannot verify, the way it now refuses to skip a code review.
