Caution: Verifiable Compute Made Simple

Table of contents

1. Introduction
2. Why verifiable compute isn’t mainstream
3. What is Caution?
4. How Caution works
5. Verification: The key innovation
6. Platform architecture
7. EnclaveOS as the runtime foundation
8. Security model
9. Open source, not open core
10. Licensing
11. Alpha access (available now)
12. General availability in 2026
13. Helpful resources

Introduction

Secure enclaves are currently very underutilized, and most of the ways they are used today are often security theater still giving a single sysadmin the power to control or modify them at any time. Enclaves can isolate code at runtime, and prove that the code has not changed, but not what that code actually is. Attestation engines supported by most enclave platforms prove that software running inside of an enclave hashes to a specific value called a PCR, but unless that PCR can be independently reproduced from source code, there is no way to confirm what code the enclave is truly running.

Additionally, all enclave solutions today rely on only one type of attestation by a single vendor, exposing their systems to insider, supply chain, and side channel risks during periods when that one engine has a known flaw, which happens from time to time.

This is the core gap in today’s confidential compute stack. Isolation and attestation without reproducibility and platform diversity is insufficient for high security applications.

Caution solves this problem by providing a cloud hosting platform which leverages EnclaveOS at its core, and offers verifiable compute across multiple enclave platforms, each with attestation by at least two different methods.

This post walks through why this matters, why current tooling falls short, and how Caution makes verifiable compute practical.

Why verifiable compute isn’t mainstream

Deploying verifiable workloads should be straightforward. In practice, it’s a nightmare.

The result: high security verifiable compute remains inaccessible to most teams, and even well-resourced organizations struggle to get it right.

What is Caution?

Caution is the generalized verifiable compute platform. It solves the core problems that make truly verifiable compute inaccessible today.

For the developer, Caution provides a single, consistent, and easy way to deploy to Trusted Execution Environments. It turns months of custom infrastructure work and expensive security engineering into one git-driven unified workflow that runs in minutes.

Caution builds a reproducible enclave image, provisions infrastructure, and exposes application and attestation endpoints. Once an enclave is live, anyone can verify exactly what is running inside. Cryptographic proof becomes part of the runtime itself rather than an afterthought, and verifiable compute becomes something real teams can adopt without friction. This is an industry first: no other platform provides end-to-end reproducible verification out of the box.

Caution is designed for portability across clouds and hardware, which strengthens trust minimization by removing dependence on any single vendor. It supports Nitro enclaves today for early access, but Intel TDX, AMD SEV-SNP, and TPM 2.0 attestation are coming in 2026 building on our modular design and abstractions.

This is a fundamentally better way to run software because it replaces blind trust with verifiable proof, and from multiple different types of enclave and attesation hardware simultanously, and as such removes major single points of failure.

Our mission is to make verifiable compute as much of an industry standard for network services as TLS. The technology primitives were invented for DRM to remove freedom from users, however we intend to flip the script and use the same primitives to upgrade freedom, security, and privacy for everyone.

How Caution works

Three commands take you from code to verified enclave: initialize your app, deploy to an enclave, and verify the deployment matches your source.

Step 1: Initialize

Configure your project for Caution by running:

# Initialize an app and generate a Procfile
$ caution init

This creates a .caution/deployment.json config file and generates a Procfile that defines how your application is built and run.

You may need to adjust the generated Procfile depending on your project structure. The Procfile supports the following fields:

Step 2: Deploy

Push your code to trigger a build and deploy it into a Nitro enclave.

Caution pulls your application, combines it with EnclaveOS to create a reproducible enclave image, provisions infrastructure in your AWS account, and starts the enclave. Build time varies based on application size and compilation requirements.

# Deploy to a Nitro enclave
$ git push caution main

After this command, Caution:

1. Authenticates you via SSH key.
2. Pulls your application code.
3. Downloads the pinned version of EnclaveOS.
4. Builds a reproducible Enclave Image File (EIF) using EnclaveOS and your application.
5. Provisions a Nitro-enabled EC2 instance in your AWS account.
6. Deploys the enclave and starts your application.
7. Exposes an application endpoint and an attestation endpoint for verification.

Step 3: Verify

Verify that the deployed enclave matches the source you can audit.

The CLI rebuilds the enclave image locally, sends a challenge to the attestation endpoint and gets a fresh attestation from the running enclave, then compares the resulting hashes and verifies all signatures. A match gives you cryptographic proof of the exact code and configuration running inside the enclave.

# Verify the deployment matches the source
$ caution verify --reproduce --url <your_attestation_url>

Verification: The key innovation

Attestation without reproducibility is theater. A Nitro attestation tells you the hash of the enclave image, but if you can’t independently produce that same hash from auditable source code, you’re just trusting whoever built the image.

Caution solves this with two verification modes: reproduce (full verification) and PCR (quick verification).

Note: Full verification requires your source code to be available to users. We recommend FOSS licenses for this, but any license works as long as users can access the code.

Reproduce mode (full verification)

Reproduce mode is the full verification path and the gold standard. It rebuilds the enclave image from source and compares it against the live attestation, giving you the strongest possible guarantee that the runtime matches the code you can audit.

$ caution verify --reproduce --url <your_attestation_url>

During this process, the CLI:

1. Generates a random 32-byte nonce that’s used as a challenge with the attestation endpoint (prevents replay attacks).
2. Requests a fresh attestation from the running enclave.
3. Verifies the certificate chain back to AWS’s Nitro Root CA.
4. Verifies the COSE signature (ECDSA P-384).
5. Verifies the return nonce matches (proves attestation is fresh).
6. Fetches the build manifest from the enclave.
7. Rebuilds the entire enclave image locally using the same EnclaveOS version and your application source. This code can be reviewed and audited as desired, and is located in ~/.cache/caution/reproductions/local/<unique-id>/eif-stage.
8. Compares local PCR values against remote PCR values.

If they match, you have cryptographic proof that:

• The enclave is running on real Nitro hardware.
• The code running matches the source code you can inspect.
• No one has tampered with the deployment.

PCR mode (partial verification)

$ caution verify --pcrs known-good-pcrs.txt

If you’ve already done a reproduce verification (or trust someone who has), you can verify future attestations against known-good PCR values without rebuilding:

1. Generate nonce and fetch fresh attestation.
2. Verify certificate chain and signature.
3. Compare PCR values against the provided file.

This is faster but requires you to trust the source of the PCR file. It’s useful for applications that lack public source code, but this means they are also not truly verifiable.

What the PCRs represent

If any of these don’t match expected values, either the code has changed or something is wrong.

Platform architecture

Caution’s architecture combines a local CLI, a lightweight control plane, and EnclaveOS inside the enclaves. Each part has a narrow, well-defined role so the path from source code to verified runtime stays simple, auditable, and reproducible. The core components are:

Together, these components form a reproducible pipeline: your code is built locally or in the builder, combined with EnclaveOS, stored as an enclave image, provisioned into a Nitro enclave, and verified by your local CLI. Every step is transparent and independently auditable.

EnclaveOS as the runtime foundation

Under the hood, Caution uses EnclaveOS: a minimal, immutable, deterministic operating system designed for high-security enclave deployments.

It’s in active development with most new work happening in a variety of other repos it will later import, but today it supports Nitro Enclaves and is suitable for early access users. So much so that many orgs are already using forks of it in the wild. Even so, it does not hit -our- standard yet, and we expect to have our new bootproof engine and nested VM architecture in Q1 2026 at which point Caution will be suitable for threat models that do not allow for completely trusting AWS.

EnclaveOS provides:

• Minimal attack surface: Small footprint, unnecessary kernel features disabled
• Immutable root filesystem: Boots from a RAM disk, no persistent state
• Deterministic builds: Byte-for-byte reproducible images regardless of build environment
• Air-gapped architecture: Network-isolated enclave communicates only via vsock

Caution serves as the deployment and orchestration layer on top of EnclaveOS. As EnclaveOS adds support for more attestation backends, Caution will enable seamless multi-cloud deployment: same git push workflow, different cloud targets.

Security model

What you DON'T have to trust

You don’t have to trust Caution. Every deployment is verifiable:

• The enclave image is reproducible. Rebuild it yourself and check the hashes.
• All components are open source. You can audit the code.
• Attestations are rooted in hardware.
• The open source CLI can be compiled locally, runs locally, and verification happens on your machine.
  • We intend to provide a guide to do everything with raw shell commands so advanced users can skip the CLI

Even if Caution’s infrastructure were completely compromised, an attacker couldn’t deploy malicious code without it being detectable via caution verify --reproduce --url <>.

What you DO have to trust

• Attesation hardware: The attestation chain in our early access release is rooted in AWS’s Nitro Security Module. If AWS is compromised or lying, attestations are meaningless. (As mentioned previously, EnclaveOS multi-hardware attestation will address this risk.)
• Your application code: We verify the platform, not your business logic.
• The cryptographic primitives: ECDSA P-384, SHA-384, standard stuff.

Open source, not open core

Caution is 100% freely licensed open source software, not “open core” with paid features hidden behind enterprise tiers. You get the entire platform with nothing held back:

• Self-host the entire stack if you want
• No feature gating
• Everything is auditable by anyone

We hope many teams choose our hosted platform or support services so we can continue this work long term, but the software itself is open because the mission is larger than us. Anyone should be able to build, verify, and run secure workloads without artificial barriers.

Our goal is an ecosystem where organizations with sensitive workloads can run enclaves across multiple providers, avoiding walled gardens and reducing single points of failure.

A fully managed service delivering the same functionality as the open source version will be offered in Q1 2026.

Licensing

Caution is dual-licensed under the GNU Affero General Public License version 3 (GNU AGPLv3) and a commercial license. The GNU AGPLv3 allows free use, modification, and distribution as long as derivative works remain freely licensed open source software.

For organizations that want to extend a fork of the Caution platform internally with proprietary code, a commercial license can be purchased upon request to bypass AGPL limitations.

Reach out to info@caution.co for early access and commercial licensing.

Alpha access (available now)

The alpha is open to teams who want to start experimenting with verifiable compute today. The platform already supports:

• AWS Nitro Enclave deployment
• Reproducible builds with EnclaveOS
• Full verification via --reproduce and --pcrs
• FIDO2 and SSH authentication
• Self-hostable platform

Contact us at info@caution.co to join the alpha and deploy to a Nitro enclave.

General availability in 2026

Caution is rapidly evolving toward a fully portable, multi-enclave platform. Here’s what’s coming in early 2026:

• Managed cloud platform
• Multi-hardware attestation (TPM 2.0, Intel TDX, AMD SEV-SNP)
• Support for additional cloud backends and bare metal
• Multi-cloud deployments from a single configuration

Helpful resources

• Caution platform repository: codeberg.org/Caution
• EnclaveOS: git.distrust.co/public/enclaveos
• Distrust: distrust.co