An independent offline verifier for cloud-api attestation reports and signed completions

[tomjwxf]

We built and published a verifier that checks a NEAR AI Cloud attested run offline, with no call to your API, and I wanted to put it in front of you for two reasons: to ask whether it reads your evidence the way you intend, and to ask whether it is worth a link from the docs for users who want a second, independent implementation.

What it verifies, per npx @veritasacta/verify manifest.json --model-calls model-calls.jsonl --model-attestation model-attestation.json (npm, Apache-2.0, source at https://github.com/VeritasActa/verify):

• Each completion's signature over {model}:{sha256(request)}:{sha256(response)} (secp256k1 over the EIP-191 digest, or Ed25519), recovered to its signing address.
• Each attestation report: the Intel TDX quote (v4 and v5) checked offline to the Intel SGX Root CA (quote signature, the quoting enclave's report binding the attestation key, the QE signature by the PCK certificate, the PCK chain and its validity); report_data carrying the signing address (and the TLS fingerprint when bound) plus the request nonce; the compose hash against MRCONFIGID; the model named in the report against the one expected.
• That every signed call's key is bound by a verified report, and that the calls are the ones the run's manifest pins.

What it does not verify, and says so in its output: TCB status and revocation, which need Intel's current collateral, and the NVIDIA evidence, which is carried and named but whose verdict is your online service.

A real run on Qwen/Qwen3.8-27B through cloud-api.near.ai (22 signed calls, one report, made in GitHub Actions with provenance) is at https://github.com/ScopeBlind/verified-runs/tree/main/runs/attested-qwen-qwen3.8-27b-ci-attested-ac952151a1c59a40, and https://legate.scopeblind.com/verify?sample=run shows the same checks in a browser. The README there has the one command.

Three observations from integrating, in case they are useful:

1. We call GET /v1/signature/{id} with signing_algo=ecdsa explicitly, since the model evidence in the report is ecdsa; Align default signing_algo between attestation reports and signature lookup #1014 looks like the same default mismatch.
2. The signature is cached per node, so a lookup right after a completion sometimes needed a retry before it returned.
3. Our harness uses non-streamed completions so the exact bytes can be hashed. If you document the canonical bytes for streamed responses, we will add them.

If anything above misreads the shape of the reports or the signatures, tell me and I will change the verifier to match. Thanks for making the attestation reachable in the first place; it is the reason the model route in these runs is evidence rather than a declaration.