# Pins for checking AugmentEV's live service offline

`augmentev-verify` and `augmentev-verify.html` check everything offline. They
need three inputs that you pin yourself. A pin is only as trustworthy as where
you got it, so each section says how to obtain or re-derive it **without
trusting us**.

## `expected-td.json`: the trust domain you expect

The measurements an Intel-signed quote must show for the service to count as
ours. Fields and where to check them independently:

| Field | What it is | How to check it |
|---|---|---|
| `compose_hash`, `mr_config_id` | SHA-256 of the deployment manifest (every container pinned by digest, the names of the allowed environment variables) | Ask us for the manifest (security@augmentev.com); hash it and compare. The quote binds this hash, so a different manifest cannot match. |
| `mr_td`, `rt_mr0`-`rt_mr2`, `os_image_hash` | Firmware, kernel and OS image of the confidential VM | The confidential-computing OS image release we run (named on request); rebuild it or compare with its published measurements. |
| `app_id` | The application's identity with our confidential-computing provider | Appears in every quote; stable across deployments. |
| `key_provider` | The KMS root CA public key that derives the application's keys | Our provider's published KMS key (on request). |
| `min_tcb_evaluation_data_number` | Oldest Intel TCB recovery level accepted | Intel PCS. |

`mr_kms` is deliberately absent. In the OS image we run it measures whichever
KMS replica served the boot, and it changes when the provider's KMS fleet changes.
The KMS is pinned by its CA public key (`key_provider`) instead. Add `mr_kms`
yourself if you want to require one exact replica build.

The expected TD changes with every deployment that changes the manifest. When
it does, we publish a new one; you re-derive and compare.

## `intel-collateral.json`: Intel's signed data, dated

Intel's certificates, revocation lists and TCB information for the quote's
platform, as fetched from Intel PCS on the `fetched_at` date. It is signed by
Intel and checked against Intel's root, so it does not matter who fetched it.
You can fetch your own with a DCAP collateral client (for example the open-source `dcap-qvl`). It stops
being valid at the date the verifier shows as "Intel collateral valid until";
after that the result is `COLLATERAL_EXPIRED` and you need a fresh one.

## `sigsum-generic-2025-1.policy`: whose logs and witnesses count

The Sigsum trust policy (logs and the 2-of-3 witness quorum) used to check the
log evidence. It is Sigsum's published vetted policy, unchanged.

## What a VALID result proves, and what it does not

**Level 2 (key receipt) proves:** a genuine Intel TDX trust domain, with the
measurements you pinned, generated and held the live signing key when the
quote was made, with Intel's collateral evaluated at your clock.

**Log evidence proves:** that exact receipt was recorded in public, append-only
Sigsum logs (and Rekor when listed) before the key signed anything, so a key we
did not publish cannot be used without the logs showing it.

**Neither proves:**
- what the software computed (attestation identifies the software, not the
  correctness of its output);
- anything about GPUs or any machine other than the attested VM;
- revocation Intel published after the snapshot's `fetched_at`;
- that AugmentEV cannot access the VM. **Today we keep administrative (SSH)
  access to the confidential VM for operations.** You can see this yourself:
  the measured manifest allows an environment variable that installs an
  operator SSH key; its value is sealed and not measured. The TEE protects the workload from the cloud host and its
  operators, not from us. Removing that access (so the manifest no longer
  allows the variable, which attestation then proves) is on our roadmap.