Security

Verify our confidential computing claims yourself

Most AI providers ask you to trust their security page. Enclave42 gives you the evidence and the verification script, so you don't have to.

Every model in the Enclave42 catalogue runs as a confidential workload. When you send a request, it is processed inside an Intel TDX trust domain on an NVIDIA GPU. You can obtain cryptographic proof of this — proof bound to a random value you generate yourself, and which you verify on your own machine against Intel and NVIDIA, not against us.

Why a nonce makes the proof yours

An attestation report you did not influence proves nothing: it could have been captured once, on genuine hardware, and replayed forever.

Enclave42 solves this the way remote attestation is meant to work. Before requesting evidence, your browser generates a 64-character hexadecimal nonce. That nonce is sent to the confidential runtime and embedded in the hardware-signed report. Specifically, the TDX quote's report_data field contains SHA256(nonce + e2e_pubkey) — the hash of your nonce concatenated with the runtime's end-to-end encryption public key.

Two properties follow. The report cannot predate your nonce, so replay is ruled out. And the encryption key that protects your traffic is bound to the same attested runtime, so the proof covers the actual instance that will serve you — not a different, cleaner one.

What the bundle contains

Requesting a bundle produces four files:

  • enclave42-verification-manifest.json — model, runtime instance ID, your nonce, the runtime's E2E public key, and the SHA-256 of the evidence file
  • enclave42-tee-evidence.json — the raw Intel TDX quote and the NVIDIA GPU evidence, as returned by the hardware
  • verify-tee.py — the verification script, readable in full
  • README.md — the procedure

The bundle contains no Enclave42 secrets and no provider credentials. It contains only evidence and the verifier.

What the script checks

verify-tee.py is roughly a hundred lines of Python. Read it before running it — the point is that you don't have to take our word for what it does.

Intel TDX quote validation

The script decodes the quote and passes it to dcap-qvl, which fetches collateral directly from Intel's Provisioning Certification Service and verifies the signature chain. Verification fails unless the resulting TCB status is UpToDate. This step involves no Enclave42 infrastructure: your machine talks to Intel.

Nonce and key binding

The script extracts bytes 48 to 632 of the quote — the TD report — and compares its report_data field against SHA256(nonce + e2e_pubkey) computed locally from your manifest. A mismatch aborts verification with report_data mismatch: nonce + E2E public key binding is invalid.

NVIDIA GPU attestation

The GPU evidence is passed to NVIDIA's Attestation SDK, using the same expected report data as the nonce. This confirms the GPU was operating in confidential computing mode and is bound to the same session.

Running the verification

Verification requires Python and three packages: dcap-qvl, nv-attestation-sdk, and cryptography. The procedure below was verified on Python 3.12.

python -m venv venv
./venv/bin/pip install dcap-qvl nv-attestation-sdk cryptography
./venv/bin/python verify-tee.py \
  --manifest enclave42-verification-manifest.json \
  --evidence enclave42-tee-evidence.json

A successful run prints four lines and exits with status 0:

Intel TDX quote: PASS (status=UpToDate)
Nonce + E2E public key binding: PASS
NVIDIA GPU attestation: PASS
TEE verification: PASS

Any failure prints FAILED: with the reason and exits 1. There is no partial pass.

What this does and does not prove

It proves that a specific runtime instance was executing inside an Intel TDX trust domain on an attested NVIDIA GPU at the moment your nonce was issued, and that the encryption key offered to you belongs to that instance.

It does not prove anything about instances you have not attested, and it does not replace your own review of what the workload does with your data once decrypted inside the enclave. Attestation establishes the boundary. It does not audit the code inside it.

Getting a bundle

Bundle generation requires an account, because it consumes confidential compute. Bundles are issued per runtime instance, and an instance must be actively serving the model at the time of the request — if none is available, the request is refused rather than answered with stale evidence.

Verification itself requires no account: once you hold a bundle, everything above runs offline against Intel and NVIDIA. Any auditor you hand the bundle to can reproduce the result independently.

Attestation proves the runtime serving you is genuine — it says nothing about how fast that runtime is under load. For that, see our measured TTFT, total latency and throughput figures, published with the raw data and the script that produced them.