Attestation

On the Enterprise plan, redaction runs inside a Treza Enclave (AWS Nitro) instead of the managed software pipeline. Hardware attestation lets you cryptographically verify where your prompts were redacted — before any of them left your trust boundary for the LLM provider.

TEE-attested redaction is an Enterprise entitlement. Starter and Pro accounts always use managed software redaction (x-treza-mode: standard) and never route through a Treza Enclave. See Plans & Pricing.

Redaction modes

Mode	Plans	Where redaction runs	Attested
standard	Starter, Pro	Managed software redaction	No
tee	Enterprise	Treza Enclave (AWS Nitro), hardware-isolated	Yes

The mode is reported on every request:

• POST /api/redact/chat/completions — the x-treza-mode response header

• POST /api/redact/run — the mode field, plus an attestation object (enclaveId, region, attested) on Enterprise

• GET /api/redact/log — each audit entry's attestationRef records which environment performed the redaction (shared-software-redaction for standard mode, the enclave id for TEE mode)

x-treza-mode: tee is only set when the redaction actually ran inside an attested enclave. If the enclave cannot be reached, the proxy fails closed (502 redaction_failed) rather than silently downgrading — your unredacted messages are never forwarded upstream.

What the attestation proves

A Treza Enclave produces a signed attestation document with Platform Configuration Register (PCR) measurements. For the redaction service this proves:

• Code identity — the exact redaction enclave image (pcr0), kernel and bootstrap (pcr1), and application (pcr2) that processed your text

• Isolation — redaction ran inside a hardware-isolated Nitro Enclave with no operator or host access to the plaintext

• Engine versions — the modelVersion and recognizerVersion of the redaction engine, matching what is stamped on your audit entries

It does not attest the upstream LLM provider — only the Treza redaction step that runs before your request is forwarded.

For background on PCR measurements and attestation documents, see Attestation & Verification.

Get the attestation summary

GET /api/redact/attest — requires a Treza API key with the redact:run scope.

curl https://trezalabs.com/api/redact/attest \
  -H "Authorization: Bearer $TREZA_API_KEY"

{
  "enclaveId": "eg-0a1b2c3d4e5f6a7b8",
  "region": "us-west-2",
  "pcr0": "e3b0c44298fc1c149afbf4c8996fb924...",
  "pcr1": "9f86d081884c7d659a2feaa0c55ad015...",
  "pcr2": "2c26b46b68ffc68ff99b453c1d304134...",
  "modelVersion": "1.4.2",
  "recognizerVersion": "2.1.0",
  "attested": true
}

Field	Meaning
enclaveId	The Treza Enclave performing your redaction (matches attestationRef in the audit log)
region	AWS region the enclave runs in
pcr0 / pcr1 / pcr2	PCR measurements of the enclave image, kernel, and application
modelVersion	Redaction model version running in the enclave
recognizerVersion	Entity recognizer version
attested	true when the summary comes from a verified enclave attestation

On non-Enterprise plans the endpoint returns 403 with code: "PLAN_FEATURE":

{
  "error": "Hardware attestation requires an Enterprise plan.",
  "code": "PLAN_FEATURE"
}

Tying attestation to individual requests

Every redaction request — proxied or standalone — writes an audit entry whose attestationRef is the id of the environment that redacted it. To build an auditable chain:

1. Capture the x-treza-request-id response header on each proxied request.

2. Look the request up in GET /api/redact/log (or the CSV export); its attestationRef, modelVersion, and recognizerVersion identify the redaction environment.

3. Compare attestationRef against the enclaveId from GET /api/redact/attest and verify the PCR measurements against your approved values.

Related

• Quickstart — send your first redacted request

• Usage & Billing — audit log export

• Attestation & Verification concepts