Skip to content

VEIL specification / 0001 · v0.1.0

Attestation

How an enclave proves which image, which weights and which keys are serving a request, and how the router and clients check that proof.
The VEIL specification is an open draft published so anyone can review or implement it. Nothing described here is deployed by the router yet unless a section says otherwise.
Status
Draft
Version
0.1.0
Updated
2026-09-30
License
Apache-2.0 (specification text)
Related
0002,0004,0005

Status of this document

This is a working draft of VEIL and not a standards-track document. It describes the evidence an enclave publishes and how it is verified as designed for Verify Route. None of it is deployed yet; when a part ships, this section will say which, and the changelog will record it.

Abstract

A VEIL enclave runs the sidecar in front of an OpenAI-compatible model server. At boot the sidecar measures the model weights, generates its keys inside the enclave and requests a hardware quote whose report data commits to those keys and measurements. The router verifies that quote before it sends any attested request, and publishes what it verified.

1. Conventions and terms

The words MUST, MUST NOT, SHOULD, SHOULD NOT and MAY are used as in RFC 2119 and RFC 8174 when written in capitals. Terms used across the documents:

  • Router: the Verify Route service that routes, prices and signs calls.
  • Enclave: a confidential VM, optionally with a confidential GPU, running the sidecar and a model server.
  • Sidecar: the process in the enclave that measures weights, holds keys and signs node receipts.
  • Quote: hardware-signed evidence of what was measured into the enclave.
  • Lane: the privacy floor of a request, one of standard, attested or blind.

2. The evidence document

An enclave MUST serve GET /attest returning a JSON evidence document with these fields:

  • quote: the raw hardware quote, base64.
  • bindings: the TLS public key hash, the receipt public key, the model digest and the image digest.
  • nonce: echoed from the verifier's request to prove freshness.

The quote's report data MUST equal SHA-256(canonical_json(bindings)) || nonce. A verifier that recomputes this and finds a mismatch MUST reject the enclave.

3. Measuring the weights

The model digest is a SHA-256 over the sorted list of weight files and their own SHA-256 values. The sidecar MUST compute it before the model server loads, and MUST refuse to start if it does not match the digest in the enclave's manifest. The manifest itself is part of the measured image.

4. Keys

The TLS key and the receipt-signing key (Ed25519) are generated inside the enclave and MUST NOT be exported. Rotating either key requires a new quote. The certificate served to clients SHOULD carry a name derived from the quote so that a client can bind the TLS session to the evidence.

5. Freshness and revocation

The router re-verifies each attested host at least every ten minutes with a new nonce. A host whose last good verification is older than the freshness window MUST be removed from the attested and blind lanes until it verifies again. A known-vulnerable hardware or firmware status MUST be treated as a failed verification.

6. Public record

Every measurement the router accepts is appended to a public registry with the time it was first and last seen. A change of image or weights shows up as a new version. The registry is designed to be anchored alongside receipts (see 0004).

7. Security considerations

  • Attestation proves what runs, not that it is free of bugs.
  • Trust rests on the hardware vendor's root keys and on the correctness of the confidential computing design.
  • GPU confidential computing evidence is collected separately from the CPU quote and MUST be verified on its own.