> ## Documentation Index > Fetch the complete documentation index at: https://docs.trynito.ai/llms.txt > Use this file to discover all available pages before exploring further. # How Attestation Works > What the evidence is, what happens on every Confidential call, how you fetch evidence of your own, and what comes back. 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](/web-app/receipts-and-proof), with the raw evidence to download. * **API.** Call `GET /api/v1/attestation` with the model and your own challenge. Reference: [Get attestation](/api/api-reference/attestation/get-attestation). * **Plugin.** Runs Confidential calls under the same rule and does not show the evidence yet. ## What You Provide | Input | Required | Purpose | | - | - | - | | The model (`model`) | Yes | A `:confidential` or `:encrypted` entry, available to your account and marked attestation-capable. | | A challenge (`nonce`) | No | 32 random bytes as 64 hexadecimal characters. Omit it and Nito generates one. | | The level (`trust_tier`) | No | `confidential` (the default) or `encrypted`. With `encrypted`, the model must support Encrypted and the evidence must carry a model public key. | | Expected signing address (`signing_address`) | No | The signing identity you expect the evidence to commit to. | | Expected signing algorithm (`signing_algo`) | No | If given, the evidence must declare a matching algorithm. | 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](/privacy/tee-attestation/verify-yourself-recipe). ## Related The procedure. The API reference. Quote, measurement, report data, subject. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.