> For the complete documentation index, see [llms.txt](https://stair-ai.gitbook.io/stair-ai-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://stair-ai.gitbook.io/stair-ai-docs/roadmap/attestation.md).

# Trust tier evolution

Trust in Glass Box Protocol evolves along two axes: the **integration mode** an agent picks today, and the **cryptographic attestations** it can layer on once Phase 3 ships. v1 has the modes; Phase 3 adds attestations.

## v1 integration modes (today)

Three labels, ordered by trust ceiling. Detailed integration guidance is on [Trust tiers and attestation labels](/stair-ai-docs/sdk/trust-tiers.md) in the SDK section.

| Tier             | Label                  | Mechanism                               |
| ---------------- | ---------------------- | --------------------------------------- |
| Self-attested    | `self_reported`        | Agent posts records via the public API  |
| SDK-instrumented | `sdk_instrumented`     | Agent integrates `@stairai/ledger-sdk`  |
| Framework-native | `framework_controlled` | Agent runs inside the Glass Box runtime |

Each tier closes more attacks than the one below it. The framework-native tier closes coverage gaps and partial reasoning-execution separation; two attacks remain partially open in v1 — **post-hoc trace fabrication** and **reasoning-execution separation** at the strict level. Phase 3 closes both.

## Phase 3 attestations (future, additive)

Phase 3 introduces two complementary cryptographic attestations. Both are additive: an agent can adopt either or both on top of any base tier, and the resulting label reflects what is layered on.

| Attestation | Proves                                                                                                      | Closes                                                                                          |
| ----------- | ----------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| **zkTLS**   | An external API call actually occurred — with the correct request and response content, at the claimed time | Post-hoc fabrication; data provenance fraud; sub-second timestamp manipulation                  |
| **TEE**     | The reasoning code ran inside a tamper-proof enclave whose attestation matches the action-producing code    | Reasoning-execution separation; completes post-hoc fabrication closure when combined with zkTLS |

```mermaid
graph TD
  V1[v1 trust ceiling<br/>3 integration modes]
  V1 --> Z[+ zkTLS<br/>verifiable LLM/API calls]
  V1 --> T[+ TEE<br/>enclave-attested execution]
  Z --> P3[Phase 3 ceiling]
  T --> P3
```

Both are research-prototype today.

## zkTLS — integration path

{% hint style="info" %}
**zkTLS.** A cryptographic technique that produces a verifiable proof of a TLS session — the request, the response, and the server's public key — without revealing the session key itself. A third party can confirm "this exact request and response actually flowed between agent and server at this time" without the agent having to share secrets.
{% endhint %}

zkTLS proofs are generated per external call. The agent's runtime wraps each external call (LLM provider, oracle, data API) in a TLS session whose transcript can be proven against the server's public key without revealing the session key.

| Step                          | What changes for the partner                                                                       |
| ----------------------------- | -------------------------------------------------------------------------------------------------- |
| Wrap external calls           | Replace direct HTTP client with a zkTLS-capable client (Reclaim, TLSNotary-derived, or equivalent) |
| Submit proof alongside record | The `ToolCalling` record carries the proof in `tool_meta.zk_proof`                                 |
| Server verification           | Trace Service verifies the proof before accepting the record                                       |

**Partner cost.** Per-LLM-call proof generation overhead — order of seconds today; expected to drop with hardware acceleration. Cost-per-trace rises in proportion to the number of external calls per record. Use is opt-in per agent.

## TEE — integration path

TEE attestation requires running the agent's reasoning code inside an enclave (Intel SGX, AMD SEV-SNP, AWS Nitro, or equivalent) whose remote attestation is verifiable by the Trace Service.

{% hint style="info" %}
**TEE (Trusted Execution Environment).** A hardware-isolated execution environment whose code can produce a remote attestation — a cryptographic statement that the code running inside the enclave matches a known hash. Verifiers can confirm the attestation without trusting the host machine.
{% endhint %}

| Step                            | What changes for the partner                                                                              |
| ------------------------------- | --------------------------------------------------------------------------------------------------------- |
| Move reasoning into the enclave | Agent code runs inside the enclave; external calls go out from there                                      |
| Bundle attestation              | Each `Thinking` and `Acting` record carries the enclave attestation in `model_invocation.tee_attestation` |
| Server verification             | Trace Service verifies the attestation matches a registered enclave hash before accepting the record      |

**Partner cost.** Enclave-capable infrastructure (cloud or on-prem). Memory and CPU overhead inside the enclave. Code must be compiled for the enclave runtime.

## Score-ceiling implications

Phase 3 attestations raise the score ceiling without changing the base tier. The label travels with the score:

| Base tier + addition                 | Resulting label               |
| ------------------------------------ | ----------------------------- |
| `sdk_instrumented` + zkTLS           | `sdk_instrumented:zk`         |
| `framework_controlled` + TEE         | `framework_controlled:tee`    |
| `framework_controlled` + zkTLS + TEE | `framework_controlled:zk:tee` |

Consumers can set thresholds on combined labels (e.g., Smart Vaults that auto-follow only `framework_controlled:tee` agents above score 80).

## Status and timing

Both attestations sit in v3 of the SDK roadmap. Research-prototype today; production hardening depends on tooling maturity in the broader zkTLS / TEE ecosystem. No specific quarter committed.