Trusted Execution Environments are secure. Here’s how we design systems to keep them that way.

I’ve been building with Trusted Execution Environments (TEEs) for over four years now, and I believe they’re a powerful infrastructure component that will be central to meeting the growing need for verifiable compute in the agentic era.

But to realize their full potential requires thoughtful design and careful implementation, and many teams lack the architecture needed to operate them securely.

Here are some of the lessons I’ve learned from building TEE infrastructure over the past four years, and how we’ve applied them to Turnkey Verifiable Cloud (TVC) to make operating TEEs correctly simpler and more accessible.

What are Trusted Execution Environments?

Trusted Execution Environments (TEEs) are isolated environments within hardware where sensitive code and data can run securely. When implemented correctly, they provide a highly secure foundation for non-custodial wallet infrastructure by keeping private keys protected, even from the teams operating the underlying infrastructure. 

At Turnkey, we use AWS Nitro Enclaves as the secure computing environment that powers our wallet infrastructure. This gives us an isolated and verifiable environment for running sensitive workloads, separate from the rest of the underlying system.

Lately, I’ve been seeing security audits of TEE deployments that reveal how surrounding infrastructure can undermine the guarantees this hardware is meant to provide. A recent independent audit of Venice’s end-to-end encrypted inference architecture is a good example.

This audit found that the encryption and attestation between the user and the first enclave are sound, but several architectural gaps weaken the broader confidentiality guarantees. 

For example, administrator access could be enabled without appearing in the system’s cryptographic attestation, the software running on the GPU server was not verified, and requests could continue even if the next server failed attestation checks.. 

The broader lesson here is that TEEs only protect what you measure, validate, and attest to. Everything outside that boundary remains a potential vulnerability.

Anyone can rent a TEE. Almost no one runs them correctly.

The security of a Trusted Execution Environment is only as strong as everything around it: how code gets approved, how secrets get provisioned, how builds get reproduced, and how upgrades happen. Turnkey Verifiable Cloud is the only enclave platform where the entire process is verified by the hardware itself.

Designing TEE infrastructure right: Trust minimization, not trust relocation

Most TEE platforms remove trust in the cloud provider and hand it to whoever operates the enclave. TVC removes trust in the operator too. To do this, we’ve implemented several architectural controls. These include:

• Quorum-approved code upgrades. No single admin, insider, or compromised account can ship code to an enclave. Every change requires m-of-n cryptographic approval.
• Quorum-based provisioning for core secrets. Core secrets only reconstruct inside enclaves running quorum-approved code. Each share holder independently verifies the attestation before posting their share.
• Fully reproducible everything. The operating system QuorumOS (https://github.com/tkhq/qos), the application, and the build system itself StageX (https://stagex.tools) are deterministically reproducible. Anyone can rebuild from source and confirm the running enclave matches, bit for bit.
• Verify the whole machine, not just the binary. Attestation covers the OS and application, plus every aspect of configuration: environment variables, CLI arguments, firewall rules, and the set of people who approved the code. The hardware root of trust (the Nitro Secure Module) accounts for all of it.
• Fully verified TLS. With TVC, all of the code that verifies TLS also rolls up into the Nitro Secure Module measurements, so even your connections to the outside world are part of the proof.
  

Together, these controls ensure the system can evolve without losing its trusted identity or giving operators access.

The Quorum Key: A stable identity that survives upgrades

The Quorum Key (https://github.com/tkhq/qos#quorum-key) gives your application a core secret that persists across software upgrades with zero downtime. Upgrades stay gated by quorum approval, but enclave-to-enclave attestation carries the key forward automatically, so fleets scale with no human in the loop.

This architecture cryptographically proves that operators cannot access encrypted user data. Customers, auditors, and regulators can independently verify that no unauthorized party has access, so the guarantee comes from cryptography, not policy.

Turnkey Verifiable Cloud is secure by default, open by choice

Most confidential VM offerings start as a general-purpose machine you must lock down. TVC starts from the most locked down possible configuration, built for processing targets holding billions of dollars. You selectively enable functionality like egress as you need it. 

Subtractive security fails quietly. Additive security fails safe.

Part of the Turnkey stack

TEEs are powerful, but the hardware alone is not enough. Their security depends on how code is approved, secrets are provisioned, builds are reproduced, connections are verified, and upgrades are managed.

Turnkey Verifiable Cloud brings these requirements together in a secure-by-default platform that works natively with Turnkey’s secret and key management system. This includes policy-gated key release, arbitrary consensus thresholds, and policies that bind key access to exact application hashes and attestation contents.

If you are building next-generation trust infrastructure or just TEE-curious, check out our docs on Turnkey Verifiable Cloud.

And get started with Turnkey today.