Skip to main content
Nito gathers attestation evidence for every Confidential request, binds it to a challenge, and returns it in full. Nito does not verify the hardware signatures. The raw evidence comes back to you so that you are the final verifier.

Supply a fresh challenge

Generate a fresh value from a cryptographically secure source, exactly 32 bytes, hex encoded, never reused. Your challenge is what ties the evidence to this request. See the challenge and the report data.

Fetch the attestation

In the Browser App, the same evidence is on the Attestation Report of each Confidential or Encrypted reply and can be downloaded there.

Run the structural checks

  1. The response names the model you asked about, with attestation reported as available.
  2. The returned challenge matches the one you sent. If not, stop: the evidence is not bound to your request.
  3. The raw evidence is present and non-empty.
  4. The proof metadata is present: a proof-format label, a signing algorithm, and the model public key.
  5. verified is false. That is expected. Do not build on any field that claims verification.
If any check fails, stop there and do not send the sensitive workload. Passing these checks tells you the envelope is well formed. The hardware checks come next.

Complete the hardware verification

Today’s backends run Intel TDX with NVIDIA GPUs, and proof_format names the evidence layout.
  • The Intel TDX quote. Validate it with Intel’s DCAP quote-verification library: the certificate chain to Intel’s root, collateral, revocation status, trusted-computing-base status, and the measurements of what was running. This is what proves a genuine sealed environment produced the evidence.
  • The NVIDIA GPU evidence, where the envelope carries one. Validate it with the NVIDIA Remote Attestation Service (NRAS) at https://nras.attestation.nvidia.com/v3/attest/gpu. The Browser App’s Attestation Report shows the command.
  • The freshness binding. Locate the report_data field inside the signed TDX quote and confirm it carries your challenge, laid out the way that backend documents. This is what proves the evidence was made for this request.
  • The model binding. Confirm the signing identity and, where the backend commits to it, the model public key inside the evidence match the summary fields, and that the model named is the one you asked for. This is what proves the evidence belongs to the workload you meant to run.
Only after these pass do you have a verified result. Until then you have an attested one.
For Encrypted, complete this procedure before encrypting with the model public key. The key comes with the evidence, and the model-binding check is what ties it to the sealed hardware.

​
Response Signatures

After verifying attestation, an Encrypted API client can request Response Evidence on supported nonstreaming calls. The returned original body bytes and signature proof let your client check whether the response is bound to the verified signing identity. Nito leaves verified as false; this requires a separate client-side signature check.

How Attestation Works

What Nito enforces, and what comes back.

What's a TEE

Why step 1 comes first.

Glossary

Quote, measurement, report data, subject.