> For the complete documentation index, see [llms.txt](https://canary-1.gitbook.io/canary/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://canary-1.gitbook.io/canary/how-it-works/trusted-execution.md).

# Trusted execution

What runs inside the enclave, what it guarantees, and where it is going.

Every verification runs inside an AWS Nitro Enclave, a hardware-isolated environment where the CPU itself enforces separation from the host operating system. Isolation is a property of the silicon, not a software policy.

<figure><img src="https://2589044420-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FpsBN7WLVynXZJOLD5eCk%2Fuploads%2FfNqOw7pUXhcsK6Tq1azf%2Fenclave-boundary.png?alt=media" alt="Inside the enclave: the verification code, the signing keys, the sealed policy and the pinned certificates. Outside, unable to read or modify it: the host operating system, the hypervisor, the server operator and Canary&#x27;s own engineers. The enclave emits only an attestation and, when every check passes, a signature."><figcaption><p>Code, keys and policy live inside the enclave, and nothing outside it can read or modify them.</p></figcaption></figure>

## What the enclave guarantees

**Hardware-level isolation.** The host operating system, the hypervisor and the server operator cannot read or modify enclave memory. Enclave memory is sealed even from Canary.

**Cryptographic attestation.** The enclave produces a signed attestation of exactly which code ran and what it computed. Any tampering with the binary produces a different measurement, and the attestation fails. A verdict is only meaningful if the thing producing it is the thing that was audited, and attestation is how that is established rather than assumed.

**Operator exclusion.** Canary's own engineers cannot inspect or manipulate a verification in flight. This is the point. You do not have to trust Canary, because the hardware does not let Canary cheat.

**Keys never leave.** Signing keys are generated inside the enclave and never exported. Key management is hardware-backed, sensitive material is held in guarded memory containers, and any memory segment that temporarily contains key material is zeroed the moment it is consumed.

**Configuration is part of the image.** Thresholds, check sets and policy are fixed at deploy time and sealed into the enclave image. There is no runtime path to loosen them. Nothing an operator, an attacker or Canary itself does at runtime can weaken the policy a protocol or issuer agreed to. Changing policy is a deployment, and a deployment produces a new measurement.

## The same boundary for every product

Canary DVN, the Cipher security engine and Canary Cosigner all run their checks and hold their keys inside this boundary, and all three are held to the same standard. The checks behind Canary Collateral Proofs are designed to run inside trusted execution environments as well. Attestation shows which code processed an offchain record, but it cannot make the record true, which is why Collateral Proofs keep each record's source and limits visible, as described on [Collateral Proofs verification](/canary/how-it-works/collateral-proofs-verification.md).

## From attestation to onchain proof

An attestation can be checked by anyone who trusts the hardware vendor's attestation chain. For the highest-value actions, Canary can go further and wrap the attestation in a zero-knowledge proof that a contract verifies onchain, so the release of funds depends on the proof as well as on a key. Even if every private key in the system were compromised, an attacker could not produce a valid proof without the correct code executing inside a genuine enclave. The binding rules are described on [Collateral Proofs verification](/canary/how-it-works/collateral-proofs-verification.md).

## Where this is going

Canary is expanding towards multi-cloud, multi-region and multi-hardware infrastructure with independent TEE technologies. AWS Nitro is live in production. AMD SEV-SNP is in final integration across additional cloud providers, with Intel TDX to follow. Once live, compromising the enclave layer would require breaking more than one independent silicon vendor at the same time.

{% hint style="info" %}
This section is forward-looking, and will be updated as each vendor goes live.
{% endhint %}