# Caution > Last updated: 2026-08-05 > The first generalised verifiable compute platform. Caution makes it simple to deploy workloads to trusted execution environments (TEEs) and lets anyone cryptographically verify exactly what software is running. Instead of trusting that a server behaves as intended, you get proof. ## What Caution does - Cryptographically links running code to reviewed source, build, and configuration - Verifies the entire stack down to the kernel with full-source bootstrapping and reproducibility - Detects unauthorised changes before they reach production - Deploys to secure enclaves (AWS Nitro Enclaves) in minutes - Integrates with existing CI/CD, infrastructure-as-code, and deployment tooling ## Key pages - Homepage: https://caution.co/ - Platform overview: https://caution.co/cloud.html - AWS Nitro Enclaves: https://caution.co/cloud/aws.html - Platform tour (demo video): https://caution.co/platform-tour.html - Pricing: https://caution.co/pricing.html - About: https://caution.co/about.html - FAQ: https://caution.co/faq.html - Engineering blog: https://caution.co/blog.html - Contact: https://caution.co/contact.html ## Documentation - Docs: https://docs.caution.co/ ## Contact - Email: info@caution.co - Matrix: https://matrix.to/#/#caution:matrix.org --- # Page content ## Homepage Caution is the generalized verifiable compute platform. Deploy to TEEs in minutes and let anyone verify exactly what's running. ### What Caution does Caution is a verifiable confidential compute platform that gives you cryptographic proof your enclaves run the exact code you reviewed. **Prove what was deployed**: Cryptographically link the code running in your enclave to the reviewed source code, build, and configuration that produced it. Verify the entire stack down to the kernel, not just the application layer, with full-source bootstrapping and reproducibility. **Detect tampering early**: Surface unauthorised changes before they reach production. If a binary doesn't match the expected source, you'll know immediately. **Deploy to enclaves in minutes**: Replace weeks of custom infrastructure and security engineering with one unified workflow that runs in minutes. Deploying to a Nitro Enclave has never been this fast. **Keep your workflows**: Integrate with your existing CI/CD, infrastructure-as-code, and deployment tooling. Caution fits into what you already use rather than replacing it. --- ## Cloud overview Run Caution in your cloud. Use Caution with the cloud providers you already trust, starting with AWS and expanding to Azure and Google Cloud soon. --- ## AWS Nitro Enclaves Deploy to AWS Nitro Enclaves faster, with stronger integrity guarantees. Use familiar pipelines while gaining cryptographic proof that each enclave runs the intended source code. ### At a glance - **What Caution is**: Verifiable compute platform that adds an extra layer of integrity guarantees on top of AWS Nitro Enclaves. - **AWS value**: Faster adoption of confidential compute on AWS Nitro Enclaves, with independent verification of enclave workloads. - **Who it's for**: Teams running sensitive AI, financial, healthcare, Web3, and other workloads on AWS that need stronger end-to-end security and assurance. - **How it runs**: Integrates with existing AWS accounts and CI/CD pipelines, with flexible deployment options. ### Why verification AWS Nitro Enclaves provide strong guarantees about hardware isolation and integrity. Verification extends those guarantees by linking the binaries running in the enclave back to the source code they came from. Without verification: - Backdoored or swapped binaries can appear legitimate without independent verification. - Supply-chain issues can slip through when only enclave measurements are verified. - Teams must rely on operator assurances instead of independent verification. ### What Caution adds to AWS Nitro Enclaves Caution links Nitro Enclaves back to the source, build, and deployment pipeline so every enclave run is independently provable. - Prove what was deployed - Detect tampering early - Deploy to enclaves in minutes - Keep your workflows ### How it works Caution integrates with existing AWS accounts and CI/CD pipelines, collapsing what is often a complex, custom Nitro deployment into a repeatable workflow that completes in minutes. ``` $ caution init $ git push caution main $ caution verify ``` ### Use cases - **Verifiable LLM inference over sensitive data** (AI): Serve LLMs and other models in verifiable Nitro Enclaves so users can confirm the exact models and runtime that handled their prompts and data. - **Verifiable oracles and data feeds** (Fintech): Run oracle and pricing services in verifiable Nitro Enclaves to demonstrate the integrity of each price feed, signal, and the code that produces it. - **Verifiable confidential AI for PHI** (Healthcare): Prove that patient data never leaves a verified enclave, meeting HIPAA requirements with cryptographic evidence. - **Verifiable model training pipelines** (AI): Ensure training runs execute approved code on approved data, with attestation evidence for audit and compliance. - **Verifiable custody and signing operations** (Fintech): Show regulators and customers that key management and transaction signing happen only in attested, source-verified enclaves. - **Verifiable nodes** (Blockchain): Expose cryptographic proof that your full node binary matches the reviewed source and configuration. - **Verifiable staking infrastructure** (Blockchain): Give delegators and protocols independent proof that staking infrastructure is not forked, modified, or tampered with. ### AWS page FAQ **What is Caution?** Caution is a verifiable compute platform that adds an extra layer of integrity guarantees on top of AWS Nitro Enclaves. It cryptographically links the code running inside an enclave back to the reviewed source code, build inputs, and configuration that produced the enclave image, so anyone can verify what is running in production. Additional attestation backends are in active development. **Does Caution replace AWS Nitro Enclaves?** No. Caution builds on top of AWS Nitro Enclaves, not instead of them. Nitro provides hardware-level isolation and attestation. Caution extends those guarantees by linking enclave measurements back to auditable source code and reproducible builds. **What do I need to get started?** [Book 20 minutes](https://caution.co/contact.html#book) with one of our engineers. We’ll discuss your goals, answer technical questions, and help you get ready to deploy with Caution. **Which deployment options are available?** Caution offers bring-your-own-compute and fully managed deployment options. Because Caution is open source, teams can also self-host it if they want to operate deployments independently. Compare the options in the deployment models reference: https://docs.caution.co/reference/deployment-models/ --- ## Pricing Pricing has not yet been publicly published. The primary deployment options are bring your own compute and fully managed. Because Caution is open source, teams can also self-host it under AGPLv3 or a commercial licence if they want to operate deployments independently. Contact info@caution.co for pricing details. [Book 20 minutes](https://caution.co/contact.html#book) with one of our engineers. We’ll discuss your goals, answer technical questions, and help you get ready to deploy with Caution. --- ## About The internet should be open, transparent, and verifiable. Today too much of it still runs on blind trust. Caution is here to change that. ### Mission Make verifiable compute the default way to run software. ### Team Caution is a small team of engineers who have spent years securing critical systems: - **Anton Livaja** — Co-founder, CEO - **Lance Vick** — Co-founder, CTO - **Ryan Heywood** — Security Engineer - **Ksenia Lesko** — Strategy and Operations ### Origin Caution grew out of work at Distrust, a security consulting and open source R&D firm founded by Lance and Anton. Distrust worked with hedge funds, custodians, Layer 1 and Layer 2 blockchain teams, cloud platforms, and critical grid operators, helping secure systems responsible for more than $100B in assets. The recurring problem: a general lack of reliable visibility into what software was actually running in production, especially in real time. Caution was built to solve that. ### Values - Decentralise trust - Open source everything - Security beyond compliance - Move thoughtfully and improve things - Impact over profit --- ## FAQ Frequently asked questions about Caution, verifiable compute, and confidential computing. ### Core concepts **What is verifiable compute?** Verifiable compute is a method of using confidential compute / TEE workloads in a way as to give them the ability to prove exactly what software is running on a server using cryptography and hardware. Instead of trusting that a system behaved as intended, you get cryptographic evidence of the code, configuration, dependencies, and kernel that were actually used during execution. It turns opaque infrastructure into something you can inspect, reproduce, and verify. No black boxes. No guesswork. No relying on a provider's promises. **What problems does verifiable compute solve?** Verifiable compute solves the fundamental problem of trust in remote systems. When you run code on infrastructure you don't physically control, you're trusting that the operator hasn't modified the software, that the system hasn't been compromised, and that what's running matches what was deployed. With verifiable compute, you eliminate this trust requirement. You get cryptographic proof of exactly what's running, allowing third parties to independently verify your claims, customers to trust your security posture, and auditors to confirm compliance without taking your word for it. **Why is verifiability important if I already use confidential compute?** Confidential compute protects data while it's being processed, but it doesn't tell anyone what code is doing the processing. An enclave could be running malicious software or a backdoored version of your application, and confidential compute alone wouldn't reveal that. Verifiability completes the picture. It lets external parties confirm not just that data is protected, but that the right software is protecting it. **How is verifiable compute different from zero knowledge proofs?** Zero knowledge proof (ZKP) technology lets you prove that a computation was done correctly without revealing the inputs or intermediate steps. They're powerful for privacy-preserving verification, but computationally expensive and only prove the math was right, not what software actually ran. Verifiable compute proves what code executed, how it was built, and where it ran. It gives you full-stack transparency: the source, the build, the dependencies, the kernel, and the runtime environment. These technologies are complementary. ZKP technologies running on top of verifiable compute have better trust guarantees. **What can verifiable compute prove and what can it not prove?** Verifiable compute can prove exactly what code was used to build the software running in an enclave. It ties together the source code, which can be reviewed, and the code that's running on a server. It cannot prove that the code itself is free of bugs or vulnerabilities, that the logic does what you intend, that the hardware and firmware implementation is secure, or that external dependencies behave correctly. Verifiable compute proves what's running, not that what's running is correct. **Do I need special hardware to use verifiable compute?** Yes, verifiable compute relies on confidential compute and TEE hardware. This is what provides the hardware "trust anchors" for the system. These technologies span AWS Nitro, AMD SEV, Intel TDX, TPM2. ### Using Caution **How do I get started with Caution?** [Book 20 minutes](https://caution.co/contact.html#book) with one of our engineers. We’ll discuss your goals, answer technical questions, and help you get ready to deploy with Caution. **How do I verify what is running after deployment?** Caution provides two verification modes: reproduce (full verification) and PCR (quick verification). Reproduce mode is 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. PCR mode is faster. If you've already done a reproduce verification, you can verify future attestations against known PCR values without rebuilding. **Does verifiable compute slow down my workloads?** The overhead is minimal and typically negligible. Verifiable compute adds transparency, not overhead. The verification and attestation processes run alongside your workload and don't affect its runtime performance. ### Security and trust model **What threats does Caution protect against?** Caution protects against tampering with deployed software, unauthorised modifications by cloud providers or administrators, supply chain attacks where build artifacts are swapped, and situations where operators claim to run one thing but actually run another. It provides cryptographic proof that what's running matches what was built from a specific source. **What threats are outside the model?** Verifiable compute does not protect against bugs or vulnerabilities in the code itself, flaws in the hardware TEE implementation, compromised source repositories, or denial of service attacks. It also doesn't verify the correctness of business logic. **What happens if an attestation fails?** A failed attestation means the running enclave doesn't match what you expected. This could indicate tampering, a deployment error, or a version mismatch. You should treat it as a serious security event: stop interacting with the enclave, investigate the cause, and redeploy from known source if necessary. **Do I need to trust Caution to use verifiable compute?** No. Every deployment is verifiable: enclave images are reproducible (rebuild it yourself and check the hashes), all components are open source, and the CLI runs locally with verification happening on your machine. Even if Caution's infrastructure were completely compromised, an attacker couldn't deploy malicious code without it being detectable via reproduce verification. **Is Caution open source?** Yes. Caution is fully open source, which is essential for verifiable compute. You can't ask people to trust a verification system they can't inspect. Open source means you can audit the build process, verify our tooling does what we claim, and even run the entire system yourself if you prefer. **Can I run Caution entirely on my own infrastructure?** Yes. You can deploy Caution on your infrastructure under AGPLv3 or a commercial licence. Alternatively, you can host in your own AWS account with Caution-managed provisioning and deployment. --- # Documentation Full documentation: https://docs.caution.co/ --- ## Getting Started Caution is a verifiable compute platform for deploying confidential workloads to secure enclaves. Setup takes about 10 minutes. ### Prerequisites (all deployment types) - Access code — talk with a Caution engineer to get started: https://caution.co/contact.html#book - Smart card — YubiKey, NitroKey, or LibremKey (must have a FIDO PIN set) - Operating system — Linux or macOS - Git - Docker — with containerd image store enabled - A containerized application ### Install the CLI Follow the installation instructions in the CLI README: https://codeberg.org/caution/cli ### Create an account Via browser: 1. Go to https://dashboard.caution.co/ 2. Enter your access code 3. Insert your smart card or use another passkey method 4. Click Continue and approve the passkey interaction when prompted Via CLI: Run the CLI registration flow and provide your access code when prompted. ### Add an SSH key Register your SSH key to authenticate deployments: ``` caution ssh-keys add --from-agent ``` You can also add an SSH key via the browser. ### Select an application You can deploy your own containerized application or use one of the Caution demo apps. To use the hello-world-enclave demo: ``` git clone https://codeberg.org/caution/demo-hello-world-enclave.git cd demo-hello-world-enclave ``` Demo apps include a Procfile already. If deploying your own application, you will need to create one — see the Procfile reference: https://docs.caution.co/reference/procfile/ --- ## Deployment Options Caution offers bring-your-own-compute and fully managed deployment models. Because Caution is open source, teams can also self-host it if they want to operate deployments independently. --- ### Fully Managed Deploy to Caution's infrastructure with zero setup. Caution handles everything from builds to hosting. **Caution handles:** infrastructure and billing, building your application, deploying and hosting enclaves, network configuration and routing. **You control:** your application source code, Procfile configuration, custom domain (optional). **When to use fully managed:** - You want to get started quickly without infrastructure setup - You have no specific data residency requirements - You prefer Caution to handle operational concerns #### Deploy an application 1. Initialize your application from your application directory: ``` caution init ``` This creates a `Procfile` that defines how to build and run your application. 2. Configure your Procfile. At minimum, specify how to run your application: ``` run: /app/server ``` For source verification, add your repository URL: ``` run: /app/server app_sources: https://codeberg.org/myorg/myapp ``` 3. Deploy by pushing your code to Caution: ``` git push caution main ``` Caution builds a reproducible enclave image and deploys it. 4. Verify the deployment: ``` caution verify ``` --- ### Bring Your Own Compute Run Caution enclaves in your own cloud account, starting with AWS, while Caution manages the enclave infrastructure and verifiable deployments. **You control:** your AWS account and billing, network configuration and VPC, where your data resides. **Caution handles:** building your application, uploading EIFs to your S3 bucket, creating launch templates and orchestrating deployments, assigning Elastic IPs for stable addressing. **When to use bring your own compute:** - Data must reside in your own AWS account - You need control over your AWS billing - You have specific network or compliance requirements **Additional prerequisites:** AWS credentials with admin permissions (used only during setup). #### Setup **Option A: Caution CLI (recommended)** From your application directory, run the bring your own compute initialization flow in the Caution CLI. This detects your AWS credentials, provisions the required infrastructure, creates your app on Caution, and registers the credentials automatically. **Option B: Manual Docker setup** Use this if you need more control over the provisioning process. Clone the bring your own compute setup repository, configure your AWS credentials in the provided environment file, build the setup container, and run it to provision the required infrastructure. This creates all required AWS infrastructure and outputs `credentials.json.gpg` to the `out/` directory. Then initialize the app with the encrypted credentials: Run the bring your own compute initialization flow in the Caution CLI again, this time providing the generated `credentials.json.gpg` file. To use an existing VPC instead of creating a new one, set `VPC_ID=vpc-xxxxxxxx` in your `.env` file. #### What the setup creates | Resource | Purpose | |---|---| | VPC | Dedicated /16 VPC with public subnets across multiple availability zones, internet gateway, and routing | | S3 Bucket | Stores enclave image files (EIFs). Named caution--images | | EC2 Instance Role | Allows enclave instances to read EIFs from the S3 bucket | | Launch Template | Preconfigured template for enclave instances | | Auto Scaling Group | Manages enclave instances (starts at 0, Caution scales as needed) | | Scoped IAM User | Credentials for Caution, scoped to only these resources | #### Security model All resources are tagged with `caution:deployment-id = `. The IAM policy enforces scope using AWS condition keys. The scoped credentials CAN: - Read/write EIF images to the deployment's S3 bucket - Start/stop/terminate EC2 instances with the deployment tag - Create new instances via the ASG (automatically tagged) - Manage volumes, security groups, and EIPs with the deployment tag - Scale the specific Auto Scaling Group - Create and manage launch template versions The scoped credentials CANNOT: - Access any resources without the deployment tag - Access other S3 buckets - Modify other Auto Scaling Groups or launch templates - Access resources in other deployments - Escalate privileges or modify IAM policies - Access network resources outside the deployment VPC #### Instance types Caution automatically selects an appropriate Nitro Enclave-compatible instance based on your CPU and memory requirements. The host instance reserves approximately 2 vCPUs and 2 GB memory for the parent instance. | Instance | vCPUs | Memory | Enclave capacity | |---|---|---|---| | m5.xlarge | 4 | 16 GB | Up to 2 CPUs, 14 GB | | m5.2xlarge | 8 | 32 GB | Up to 6 CPUs, 30 GB | | m5.4xlarge | 16 | 64 GB | Up to 14 CPUs, 62 GB | | m5.8xlarge | 32 | 128 GB | Up to 30 CPUs, 126 GB | #### Maintenance To update the IAM policy for an existing deployment (e.g. after script improvements): ``` docker run --rm \ -e AWS_ACCESS_KEY_ID="your-admin-key" \ -e AWS_SECRET_ACCESS_KEY="your-admin-secret" \ -e AWS_REGION="us-west-2" \ -e DEPLOYMENT_ID="your-deployment-id" \ -e VPC_ID="vpc-xxxxxxxx" \ caution-provisioner-setup python setup.py --update-policy ``` To remove all resources created by the setup, follow the cleanup instructions in the bring your own compute setup repository. --- ## Verification Caution provides two verification modes: **Reproduce mode (full verification):** Rebuilds the enclave image from source and compares it against the live attestation. Confirms that the enclave is running on real Nitro hardware, the code matches the auditable source, and nothing has been tampered with. This is the gold standard. **PCR mode (partial verification):** Verifies future attestations against known-good PCR values without rebuilding. Faster, but requires trusting the source of the PCR file. Appropriate after an initial reproduce verification has been completed. Run verification with: ``` caution verify ``` --- # Blog posts ## The case for verifiable compute Published: 2025-09-29 URL: https://caution.co/blog/the-case-for-verifiable-compute.html Most of today's technologies are black boxes. From firmware and operating systems to compilers and cloud platforms, opacity is the default. Users can send requests to an API or server, but they cannot verify what software, or whose software, they are really interacting with. This is not just a usability issue, it is a systemic design failure. ### The real-world risk of unverifiability SolarWinds (2020) showed how a compromised software supply chain can cascade globally. Attackers injected malicious code into SolarWinds' Orion updates, which were then shipped to thousands of companies and U.S. government agencies. Because customers had no way to verify what software they were actually running, the backdoor spread silently through trusted update channels. ### The building blocks of true verifiability Three core technologies make end-to-end software verifiability possible: - **Reproducible builds.** Force software to be bit-for-bit identical when built from the same source code, eliminating certain categories of supply chain attacks. - **Secure enclaves.** Hardware-isolated execution prevents external processes, even privileged ones, from tampering with sensitive workloads. - **Remote attestation.** Measures the state of a machine and provides cryptographic proof of what software is running, anchoring trust at the hardware layer. Together, they form the foundation of true verifiable compute: the ability to verify software integrity from the toolchain it's built with to the hardware it runs on. ### Why existing platforms fall short Current offerings from the major cloud providers are demanding in terms of both expertise and time to set up. They lock users into a single vendor's ecosystem and force reliance and trust in one type of hardware or firmware. New players are building wrappers around enclave and attestation technologies, but most remain focused on narrow use cases, providing only surface-level verification. --- ## Caution: Verifiable compute made simple Published: 2025-12-01 URL: https://caution.co/blog/introducing-caution.html Attestation without reproducible builds is still a black box because there's no way to prove that the code in the enclave matches your source. Existing TEE solutions also rely on a single hardware root of trust like TDX, SEV, or Nitro, creating a single point of failure. Two key innovations that solve these problems: - Independently reproduce a deployed enclave image locally from source code and verify that's exactly what's running in an enclave. - Use multi-hardware attestation, where multiple vendors attest to the same thing to eliminate reliance on any single hardware. ### Why verifiable compute isn't mainstream - The tooling is fragmented and incomplete. - Reproducibility is an afterthought. - It requires expensive specialists. Companies end up having to hire 3+ security engineers at $300k+ to build and maintain custom enclave infrastructure. - Vendor lock-in is the norm. ### What is Caution? Caution is the generalized verifiable compute platform. 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. This is an industry first: no other platform provides end-to-end reproducible verification out of the box. ### How Caution works Three commands take you from code to verified enclave: ``` $ caution init # Initialize and generate a Procfile $ git push caution main # Deploy to a Nitro enclave $ caution verify # Verify the deployment matches source ``` ### Verification: The key innovation Caution provides two verification modes: **Reproduce mode (full verification)**: Rebuilds the enclave image from source and compares it against the live attestation. 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, and no one has tampered with the deployment. **PCR mode (partial verification)**: Verify future attestations against known-good PCR values without rebuilding. Faster but requires trusting the source of the PCR file. ### Platform architecture | Component | Purpose | |-----------|---------| | CLI | Local tool for managing deployments and verification | | Gateway | Authentication (FIDO2 passkeys or SSH) and request routing | | API Backend | Manages state, users, organisations, and orchestrates deployments | | Enclave Builder | Combines your application with EnclaveOS to produce reproducible enclave images | | EnclaveOS | Minimal, immutable, deterministic Linux OS that runs inside the enclave | ### EnclaveOS as the runtime foundation EnclaveOS is a minimal, immutable, deterministic operating system designed for high-security enclave deployments. It 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 ### 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. All components are open source and auditable. Attestations are rooted in hardware. **What you DO have to trust**: The attestation hardware (currently the AWS Nitro Security Module), your application code, and the cryptographic primitives (ECDSA P-384, SHA-384). ### Open source, not open core Caution is 100% freely licensed open source software, not "open core" with paid features hidden behind enterprise tiers. Dual-licensed under GNU AGPLv3 and a commercial licence. --- ## First fully verifiable AI/LLM deployment Published: 2026-02-04 URL: https://caution.co/blog/verifiable-llms.html We deployed an LLM to a secure enclave and verified exactly what code is running: an industry first for full source bootstrapped, deterministic, fully verifiable, and end-to-end encrypted AI inference. ### The problem with AI privacy Large Language Models have transformed nearly every industry, but a fundamental problem remains: how does one use an LLM without exposing sensitive data to third parties? Tech companies, and AI companies in particular, have a poor track record with user data. Prompts may be logged, used for training, shared with contractors, or retained indefinitely. Privacy policies can change at any time. When data leaves your control, there is no way to verify how it's handled. ### Current approaches fall short Some attempts use Trusted Execution Environments (TEEs) to isolate data, providing remote attestation as proof. But these solutions fall short: their "proofs" only demonstrate that the deployed code hasn't changed, not what that code actually is. Without full verifiability, the trust still lies with the operator alone. Additionally, many confidential compute solutions today terminate TLS outside of the enclave, leaving the data exposed on the host within which the enclave runs. This defeats the entire point of enclaves as the data is exposed to an untrusted system. ### The deployment The deployment uses the standard Caution platform workflow: ``` $ caution init $ git push caution main $ caution verify ``` After deployment, the CLI rebuilds the enclave image locally, sends a challenge to the attestation endpoint, fetches a fresh attestation from the running enclave, then compares the resulting hashes and verifies all signatures. ### What this proves With Caution platform, you can: - Deploy an LLM to a hardware-isolated enclave, ensuring your data never leaves the secure environment - Reproduce the exact deployment locally: rebuilding the enclave image from source, all the way down to the kernel - Verify the running code matches via cryptographic proof through PCR comparison This enables the first fully verifiable LLM deployment. No trust required: full verification covers every line of code down to the kernel, proving the LLM can't perform undesirable actions with your data. ### True end-to-end encryption with STEVE In typical enclave deployments, TLS terminates at a reverse proxy or load balancer outside the enclave. The traffic is then forwarded to the enclave in plaintext. This means the host system can read every request and response. Caution solves this with STEVE (Secure Transport Encryption Via Enclave), a freely licensed open source solution which adds a second encryption layer that terminates exclusively inside the enclave. STEVE uses X25519 key exchange with Ed25519 signatures bound to the enclave's attestation. The host never sees plaintext application data. For client-side applications, a service worker handles encryption transparently, requiring no application changes. For this LLM deployment, prompts and responses are encrypted from the browser all the way into the enclave. This combination of full verifiability and true end-to-end encryption is what sets Caution apart from other confidential compute solutions. --- ## Verify, don't trust Published: 2026-03-10 URL: https://caution.co/blog/on-transparency.html We've built the digital economy on blind trust: trusting vendors, contracts, and terms of service instead of verifying what software actually does. Trust is not a security property. Verifiable compute changes that: for the first time, you can get cryptographic proof that the code running on a server matches its auditable source. With major regulatory deadlines arriving in 2026, this is no longer theoretical or optional. ### We delegate trust constantly The default model for security today is delegation. You buy cybersecurity insurance. You pay for proprietary tools. You sign contracts with vendors. In every case, you're paying someone else to make the problem go away. This works until it doesn't. And it often doesn't. SolarWinds was supposed to be the company that kept others secure. They were the leading security and IT management vendor, trusted by Fortune 500 companies and U.S. government agencies alike. Then in 2020, attackers injected a backdoor into SolarWinds' own software updates. Because none of their customers could verify what code they were actually running, the compromise spread silently through trusted update channels to thousands of organisations. The company whose entire job was security became the attack vector. ### We hand over data and hope for the best You type a prompt into a chatbot. What happens to that data? Is it logged? Used for training? Shared with third parties? You have no way to know. The terms of service say one thing, but terms of service are a legal obligation, not a technical constraint. They describe what a company promises to do, not what the software actually does. The same problem exists at every scale. A financial institution deploys an AI model to analyse client data. What code is actually running on that server? Is it the model they audited? Has it been modified since deployment? The vendor's documentation says one thing, but documentation is a promise, not a proof. ### Trust is not security There's a widespread belief that well-funded proprietary tools are inherently more secure than open alternatives. This is a failure to reason clearly. If you can't inspect it, you can't verify it. If you can't verify it, you're just trusting. And trust is not a security property. It's the absence of one. Legal frameworks help, but they're reactive. They punish breaches after they happen. They don't prevent them. A contract that says "we won't misuse your data" does nothing to stop software from misusing your data. Only the architecture of the system can do that. ### What transparency actually means Real transparency means being able to verify what software is running on a server, what it's capable of, and what it does with data you send it. Not by reading a blog post or a privacy policy, but by inspecting the actual code and proving it matches what's deployed. Almost no system works this way today. ### Confidential compute changes the game Confidential compute hardware, specifically secure enclaves combined with remote attestation, makes it possible to provide cryptographic proof of what software is running behind a given domain or IP. Combined with reproducible builds, this means anyone can independently verify exactly what code a server is executing. This isn't theoretical. It's how Caution works today. The shift is fundamental: from "trust us" to "verify it yourself." Users no longer have to hope that companies are telling the truth about how their data is handled. They can check, and getting started takes three commands. ### Regulatory context Multiple major compliance frameworks are reaching enforcement milestones simultaneously. The EU AI Act's obligations for most high-risk AI systems take effect August 2, 2026, requiring organisations in healthcare, finance, government, and critical infrastructure to demonstrate how their workloads operate, not just claim they are secure. The HIPAA Security Rule overhaul (expected to be finalised in 2026) introduces mandatory, prescriptive cybersecurity controls across the entire healthcare sector for the first time, with stricter audit requirements and faster breach notification timelines. Verifiable compute is no longer a nice-to-have. It is a compliance requirement. ### Why this matters beyond security Verifiability is a missing building block. Not just for security, but for individual freedom and the entire digital economy. The ability to verify what software does is a prerequisite for trust in a digital world. Without it, even the most carefully architected systems are incomplete. This is also why the technology has to be truly open source. Not open core with the important parts behind a paywall. Not source-available with a licence that restricts use. Fully open, freely licensed, auditable by anyone. If the goal is to remove the need for blind trust, the tool that does it can't require blind trust either.