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

# Per-Provider Attestation

> Why attestation evidence can look different depending on which sealed-compute backend served your call, and why the guarantee is the same across all of them.

Nito can route a Confidential call to more than one sealed-compute backend. Each runs its own hardware and its own way of vouching for the workload it sealed, so the evidence they produce is not byte-for-byte identical. The guarantee does not change: a signed proof you can verify independently.

## The Attestation Subject

A signed statement has to say what it is vouching for. The **attestation subject** is that identity anchor: the name the proof is bound to, so you can confirm the evidence belongs to the workload you meant to run.

Each backend has its own way of naming the workload it sealed. Nito normalizes everything else, and surfaces this difference in the result rather than hiding it.

## Where Backends Differ

| Aspect                        | Varies by backend                                             |
| ----------------------------- | ------------------------------------------------------------- |
| How the subject is named      | The field naming the attested workload can differ             |
| Whether a subject is required | Some always carry one; others treat it as optional            |
| Default proof format          | Each labels its evidence with its own proof-format identifier |

None of this changes what the proof means. It changes how you read the fields.

## What Stays the Same

Whichever backend served the call, the evidence flows through the same [attestation pipeline](/privacy/tee-attestation/attestation-pipeline), the same [seven-gate baseline](/privacy/tee-attestation/seven-gate-baseline), and the same result shape. The [verify-yourself path](/privacy/tee-attestation/verify-yourself-recipe) applies unchanged.

In the result, a proof-format label tells you which backend produced the evidence, and a subject field, where present, carries the name the proof was bound to. Read the fields on the result you actually received rather than assuming a fixed shape.

Which backend serves a given model is discovered at runtime and reported per model, so read it from the model's own attestation metadata rather than a static list. Each model is served by exactly one backend, so there is never ambiguity about which format applies.

## Related Resources

<CardGroup cols={3}>
  <Card title="Attestation Pipeline" icon="arrows-left-right-to-line" href="/privacy/tee-attestation/attestation-pipeline">
    The flow every backend feeds into.
  </Card>

  <Card title="The Seven-Gate Baseline" icon="door-open" href="/privacy/tee-attestation/seven-gate-baseline">
    The checks that run regardless of backend.
  </Card>

  <Card title="Verify It Yourself" icon="memo-circle-check" href="/privacy/tee-attestation/verify-yourself-recipe">
    Completing the hardware verification.
  </Card>
</CardGroup>