Skip to main content
Attestation is how a Confidential or Encrypted call proves where it ran. The sealed hardware signs a statement of what is running inside it, Nito fetches that evidence, binds it to a challenge, checks it against the route, and returns it to you in full. Its purpose is to turn “the model ran in sealed hardware” from something the provider says into something you hold and can check.

​
On Every Confidential Call

Before a Confidential call reaches the provider, Nito fetches fresh evidence from the hardware serving that model with a challenge of its own, checks that the evidence is present and that it names the provider, the model, and the workload the call is routed to, and refuses the call otherwise. A Confidential call never runs on an unattested route and never downgrades. An Encrypted call starts from the attestation fetch on your side instead, because the key your device encrypts with comes from the evidence. Nito then checks the key and relays ciphertext.

​
Holding Evidence Yourself

The evidence from Nito’s own pre-call check is not attached to the API chat response. To hold evidence bound to a challenge you chose:
  • Browser App. The evidence is fetched again for each Confidential or Encrypted reply and shown as the Attestation Report, with the raw evidence to download.
  • API. Call GET /api/v1/attestation with the model and your own challenge. Reference: Get attestation.
  • Plugin. Runs Confidential calls under the same rule and does not show the evidence yet.

​
What You Provide

The challenge is never stored or logged.

​
What Nito Checks

  1. Resolves the model to an attestation-capable sealed backend. Unknown models, models that are not attestation-capable, and unsupported query parameters are rejected before any backend is contacted.
  2. Fetches the hardware evidence from that backend.
  3. Checks the envelope. Nito refuses to return a result when the evidence is empty, when the backend echoes a different challenge, or when the signing material conflicts with the signing_algo or signing_address you asked for. For encrypted, it also requires a model public key of the right shape for the declared algorithm.
  4. Returns it in full, with the challenge always populated.

​
What Comes Back

  • The model you asked to attest (model) and the backend’s own model binding (provider_model_id).
  • The privacy level and whether attestation is available for the model.
  • The attestation subject, where the backend names one: the workload the proof is bound to.
  • The challenge (nonce).
  • The proof format (proof_format) and signing algorithm the evidence declares. The proof format names the backend’s evidence layout, which tells you how the challenge and keys are bound.
  • The signing address, signing key, and model public key, as observed from the backend.
  • verified, always false: Nito hands the evidence to you and leaves the hardware verification to you.
  • The raw hardware evidence in full: the Intel TDX quote and, where the backend runs a GPU, the NVIDIA GPU evidence.
Every response is served with Cache-Control: no-store and is never persisted by Nito.

​
The Challenge and the Report Data

Freshness lives inside the signed hardware evidence. The workload binds your challenge into the report data before the hardware signs, so a different challenge produces different report data and the signature would not match. The nonce field on the response is what Nito sent, returned for convenience. Reading only that field tells you nothing about whether the backend honored it. Locate the report data inside the signed quote, recompute the binding the way that backend documents it, and confirm your challenge is in it. Nothing stores challenges between requests, so a value is never rejected for having been used before. Freshness comes from choosing a fresh, unpredictable value each time: 32 bytes from a cryptographically secure source, hex encoded, never reused. Omit it and Nito generates one the same way. The evidence is still bound to the request, but the value was chosen on your behalf.

​
The Evidence Shape

Nito can route a Confidential call to more than one sealed backend. Each runs its own hardware and binds the challenge in its own documented way, so the evidence is not byte-for-byte identical across backends: the proof format differs, the subject is named differently, and a model-bound request may omit the subject. What it means does not change: a signed proof you can verify independently. Read proof_format and the fields on the result you received. The layout follows the backend. Each model is served by one backend, discovered at runtime.

​
Verifying It

Nito checks the envelope and the binding to the route. The hardware quote, the certificate chain, revocation status, and the measurement policy are verified by you on the raw evidence, with Intel’s and NVIDIA’s tooling, which is why verified is always false on the response and why nothing of Nito’s stands between you and the evidence. The procedure is on Verify It Yourself.

Verify It Yourself

The procedure.

Get Attestation

The API reference.

Glossary

Quote, measurement, report data, subject.