> ## 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.

# Verify It Yourself

> Confirm the baseline, then complete the hardware verification so you, not Nito, are the final verifier.

Nito performs a **baseline** verification: it confirms the evidence is present, well-formed, carries its signing material, is bound to a fresh value you supplied, and is bound to the model that served the call.

Nito does **not** perform the full hardware verification. Validating the raw hardware evidence and its certificate chains is yours to do on top of the baseline. That is the point of this path: the raw evidence comes back to you so that you, not Nito, are the final verifier.

<Steps>
  <Step title="Supply a fresh value" icon="1" iconType="solid" stepNumber={1} titleSize="h2">
    Generate a fresh, unpredictable value from a cryptographically secure source, at least 32 bytes, and never reuse one. Replay protection is caller-driven, so this is what makes the freshness gates meaningful. See [the report-data binding](/privacy/tee-attestation/freshness-binding).
  </Step>

  <Step title="Fetch the attestation" icon="2" iconType="solid" stepNumber={2} titleSize="h2">
    Request the attestation backing a Confidential call, passing the value from step 1. What comes back is a signed statement plus the raw hardware evidence.
  </Step>

  <Step title="Run the independent checks" icon="3" iconType="solid" stepNumber={3} titleSize="h2">
    Do not take a `verified` flag at face value. Re-check these in your own code:

    1. **The response arrived cleanly** and is the attestation you asked for.
    2. **A model is named** and the result reports the Confidential level as available.
    3. **The echoed value matches** the one you sent. If it does not, stop: the proof is not bound to your request.
    4. **The raw evidence is present** and non-empty.
    5. **The proof metadata is present:** a proof-format label, a signing algorithm, and the model public key.
    6. **The baseline verification passed.**

    If any check fails, treat the attestation as untrustworthy and do not proceed with the sensitive workload.
  </Step>

  <Step title="Complete the hardware verification" icon="4" iconType="solid" stepNumber={4} titleSize="h2">
    Steps 1 through 3 give you a baseline-verified result. For full assurance, verify the raw hardware evidence yourself: validate the hardware quote and any accelerator evidence it contains, walk the certificate chains up to the vendor certificates, and check them against current revocation and trust policy. See the scope limit on [the seven-gate baseline](/privacy/tee-attestation/seven-gate-baseline).
  </Step>
</Steps>

## Related Resources

<CardGroup cols={3}>
  <Card title="The Seven-Gate Baseline" icon="door-open" href="/privacy/tee-attestation/seven-gate-baseline">
    What the baseline covers, and what it does not.
  </Card>

  <Card title="Report-Data Binding" icon="connectdevelop" href="/privacy/tee-attestation/freshness-binding">
    Why step 1 comes first.
  </Card>

  <Card title="Per-Provider Attestation" icon="plug-circle-check" href="/privacy/tee-attestation/per-provider-attestation">
    Why evidence can differ by backend.
  </Card>
</CardGroup>