Skip to content

Attestation Verification

Attestations prove that an inference actually executed on the claimed infrastructure with the claimed properties. While receipts prove "this record is intact," attestations prove "this computation happened."

What Is an Attestation?

An attestation is a cryptographic proof generated during inference execution. It binds the execution environment, model, input, and output together into a tamper-evident record.

Property What It Proves
Execution integrity The inference ran to completion without interruption or substitution
Environment binding The computation ran on the claimed infrastructure
Temporal anchoring The execution occurred at the attested time
Input-output binding The attested output was produced from the attested input

Receipts vs. Attestations

A receipt is the document you receive and can verify. An attestation is the underlying proof that the execution happened. The receipt contains a reference to the attestation and inherits its integrity guarantees.

How Attestations Work (Conceptual)

Your Request
     |
     v
Sovereign Compute Environment
     |
     |--- Execution begins
     |    Attestation generation starts
     |    Input hash recorded
     |    Environment state captured
     |
     |--- Inference executes
     |
     |--- Execution completes
     |    Output hash recorded
     |    Attestation finalized
     |    Signed and sealed
     |
     v
Attestation Bound to Receipt
     |
     v
Receipt Returned to You

The attestation is generated during execution, not after. This means the proof is contemporaneous with the computation -- it cannot be fabricated retroactively.

Attestation Properties

Execution Integrity

The attestation proves the inference executed completely and correctly:

  • The model processed your full input
  • The output was generated by the model, not substituted
  • No intermediate modification occurred between input and output

If an attacker attempted to intercept the response and substitute a different output, the attestation would be invalid because the output hash would not match.

Tamper Detection

Attestation tamper detection works at multiple layers:

Layer Protection
Field-level Any modification to individual fields invalidates the attestation
Commitment-level The cryptographic commitment binds all fields -- partial changes are detectable
Signature-level The digital signature prevents forgery of the entire attestation
Temporal Timestamps are bound to the attestation -- backdating is detectable

How Tampering Is Detected

                Original                  Tampered
             +-----------+            +-----------+
Input Hash:  | abc123... |  ------>   | abc123... |  (same)
Output Hash: | def456... |  ------>   | xyz789... |  (CHANGED)
Commitment:  | 04a7f3... |  ------>   | 04a7f3... |  (same, but now INVALID)
Signature:   | 0x69c8... |  ------>   | 0x69c8... |  (same, but now INVALID)
             +-----------+            +-----------+

Verification result: FAILED
Reason: Commitment does not match recomputed value from fields

Any modification -- no matter how small -- cascades into a verification failure. There is no way to "fix" the commitment or signature without access to the signing key.

Verifying Attestations

Via the API

Attestation verification is included in the standard verification endpoint:

curl https://six-sov.com/v1/verify/rcpt_f8c505ce3a... \
  -H "Authorization: Bearer $SIX_API_KEY"

The response includes the attestation status:

{
  "status": "verified",
  "attestation": {
    "integrity": "valid",
    "timestamp": "2025-01-15T14:32:00Z",
    "settlement": "anchored"
  }
}

Interpreting Attestation Results

Field Value Meaning
integrity valid Execution attestation is intact and untampered
integrity tampered Attestation has been modified -- investigate immediately
settlement anchored Settlement is recorded on the immutable ledger
settlement pending Settlement is processing (typically resolves within minutes)
settlement unsettled Settlement has not been recorded -- may indicate an issue

Via CLI

six verify --attestation receipt.json

Attestation Verification:
  Integrity:   VALID
  Timestamp:   2025-01-15T14:32:00Z
  Settlement:  ANCHORED
  Environment: sovereign

Status: VERIFIED
Attestation Internals
The attestation generation algorithm, binding protocol, and hardware attestation integration are documented in the full technical specification for NDA partners.

Request attestation documentation →

Settlement Anchoring

Every attestation is anchored to an immutable ledger, creating a permanent, publicly auditable record that the execution occurred. This provides:

Property Benefit
Permanence The record cannot be deleted or modified
Independence The ledger is not controlled by SIX
Auditability Any party can verify the anchor exists
Temporal proof The ledger timestamp provides independent time verification

Why settlement matters for compliance

Settlement anchoring means your audit trail does not depend on SIX continuing to operate. Even if SIX ceased to exist, the ledger anchor would remain, and the receipt could still be verified using published public keys and the ledger record.

Common Scenarios

Scenario: Auditor Requests Proof of AI Usage

  1. Retrieve the receipt from your audit log
  2. Verify via CLI (independent, no SIX network dependency)
  3. Show the attestation integrity result
  4. Provide the settlement anchor reference for ledger verification
  5. The auditor can independently verify the anchor on the public ledger
  1. Produce the receipt as evidence
  2. Demonstrate that the cryptographic commitment binds all fields
  3. Show that the signature was issued by authorized SIX infrastructure
  4. The opposing party can verify independently -- the proof is mathematical

Scenario: Suspicious Output

  1. Compare the output you stored with the attested output hash
  2. Verify the receipt and attestation
  3. If verification fails, the output was modified after execution
  4. If verification succeeds, the output is authentic

Next Steps