Canonical Reference

Cryptographic Controls

A single reference for every cryptographic claim ThetaZero makes — what is hashed, what is signed, which algorithm is used at each layer, and exactly how a compliance reviewer can independently verify each guarantee.

Contact Security Team

✓ AES-256-GCM at Rest ✓ SHA-256 Record Integrity ✓ RSA-4096 Package Signing ✓ HMAC-SHA256 TEE Attestation ⧗ Hardware TEE Attestation — Q3 2026

🗺️

Layer Overview

All cryptographic layers in one table — what each one does and why

ThetaZero uses five distinct cryptographic layers. They are complementary, not contradictory — each layer addresses a different threat at a different point in the evidence chain. The table below shows how each layer fits together.

#	Layer	Algorithm	What it protects	Independently verifiable
1	Data at Rest	AES-256-GCM	OAuth tokens, secrets in DB — unreadable if DB is breached	No (symmetric key held by ThetaZero)
2	Record Integrity	SHA-256	Input & output of every agent action — detects single-record tampering	Yes — recompute hash from exported record
3	Audit Log Anchoring	SHA-256 Merkle	Batch of 60-second audit records — retroactive deletion or modification detectable	Yes — recompute Merkle tree from leaf hashes
4	TEE Attestation	HMAC-SHA256	Proof that execution ran on a specific Theta EdgeCloud node under policy	⧗ Hardware attestation Q3 2026 (see §5)
5	Evidence Package Signing	RSA-4096	Exported ZIP package — proves the bundle was produced by ThetaZero and not modified after export	Yes — verify signature against public key

💡

Why there are multiple algorithms: Each layer solves a distinct problem. SHA-256 detects tampering at the record level. Merkle anchoring detects retroactive log deletion or reordering. RSA-4096 authenticates the export package itself. HMAC-SHA256 attests which compute node executed a task. AES-256-GCM protects stored credentials. They work together — not as redundant claims, but as a chain.

🔒

Layer 1 — AES-256-GCM (Data at Rest)

Protecting stored credentials and secrets from database exposure

Symmetric Encryption for Stored Secrets

AES-256-GCM

Algorithm

AES-256-GCM (256-bit key, authenticated encryption)

What is encrypted

OAuth tokens (GitHub, Gmail, etc.), user secrets, API credentials stored in the service_connections table

Key management

Encryption key stored in environment vault, never committed to source control or logged. Key rotation supported via re-encryption migration scripts.

Purpose

If the database file is exported or breached, no credential is readable in plaintext. AES-GCM also provides integrity — a tampered ciphertext fails decryption.

🔍 Independent Verification

This layer is not directly verifiable by a third party — the encryption key is held exclusively by ThetaZero. Verification requires trusting ThetaZero's key management practices, which you can review in our security controls documentation. You can confirm the structure of encrypted fields (ciphertext + IV + auth tag) in an audit export, but you cannot decrypt without the key.

🔗

Layer 2 — SHA-256 (Record Integrity)

Every agent action hashed at execution time for individual record tamper detection

Per-Record SHA-256 Hashing

SHA-256

Algorithm

SHA-256 (FIPS 180-4)

What is hashed

Input data, output data, and result of every agent tool call — each event individually. Hashes computed inside the TEE at execution time.

Hash fields in export

input_hash, output_hash, record_hash — present on every audit record

Purpose

Detects modification of any individual execution record after it was written. A changed input or output produces a different hash.

// Example: audit record fields in the evidence export
{
  "event_type": "tool_call",
  "tool": "identity_db.read",
  "timestamp": "2026-04-15T14:23:07.581Z",
  "input_hash": "sha256:a3f8c2d9...",   // SHA-256 of the tool input
  "output_hash": "sha256:7e91b4fa...",  // SHA-256 of the tool output
  "record_hash": "sha256:d4e1...b882"   // SHA-256 of the full record
}

🔍 How to Verify Independently

1 Export the audit trail via GET /api/v1/executions/:id/audit-export or download from the evidence pack ZIP.

2 For any record, recompute SHA-256(record_payload) and compare to the stored record_hash. A match confirms the record is intact.

3 Any standard SHA-256 utility works: sha256sum on Linux/macOS, PowerShell Get-FileHash, or any cryptographic library.

⛓️

Layer 3 — SHA-256 Merkle Tree (Audit Log Anchoring)

Batched every 60 seconds — retroactive deletion or reordering detectable

Tamper-Evident Merkle Anchoring

SHA-256 Merkle

Algorithm

SHA-256 Merkle tree (standard binary Merkle construction)

What is anchored

All audit records written in the past 60 seconds. AuditChain collects their record_hash values as Merkle leaves and computes a root.

Batch interval

Every 60 seconds. The Merkle root is sealed and stored — it cannot be updated retroactively.

Hash fields in export

merkle_leaf_hash (per record), merkle_root_hash (per batch), merkle_path (proof path for verification)

🧠

Why this matters: SHA-256 per-record hashing tells you a single record wasn't changed. Merkle anchoring tells you records weren't deleted from the log or reordered. An attacker who removes a record changes the Merkle root — which was already sealed. Both layers are necessary.

// Merkle fields in the audit export
{
  "record_hash": "sha256:d4e1...b882",       // this record's leaf
  "merkle_leaf_hash": "sha256:d4e1...b882",  // same (or derived)
  "merkle_root_hash": "sha256:7f3c...a119",  // sealed batch root
  "batch_id": "batch-20260415-142300",
  "batch_sequence": 47
}

🔍 How to Verify Independently

1 Export all records for a batch. Collect each record's merkle_leaf_hash.

2 Build a binary Merkle tree: sort leaves, hash pairs as SHA-256(left || right), recurse to root.

3 Compare your computed root to merkle_root_hash in the export. A match confirms no records were added, removed, or modified after sealing.

4 For individual record inclusion, use the merkle_path array to walk the proof without processing all leaves.

🏰

Layer 4 — HMAC-SHA256 (TEE Attestation)

Proves which node executed a task and that policy was enforced — hardware attestation on roadmap

TEE Execution Attestation Token

HMAC-SHA256

Current algorithm

HMAC-SHA256 (keyed hash, TEE_SIGNING_KEY held by ThetaZero)

What is attested

Each execution within a Theta EdgeCloud TEE node — proves node identity, execution timestamp, and policy compliance hash.

Token format

tz_tee_v1:{ts_hex}:{record_hash[0:16]}:{hmac[0:24]}

Where it appears

tee_attestation_id field in execution records and evidence ZIP manifests

⧗ Roadmap — Q3 2026: HMAC-SHA256 is a transitional mechanism used while ThetaZero's Theta EdgeCloud hardware TEE integration is finalized. In Q3 2026, attestation will upgrade to AMD SEV-SNP hardware attestation reports — cryptographically verifiable by any third party against AMD's public endorsement key without trusting ThetaZero's signing key. We will update this page when hardware attestation is live.

🔍 Current Verification Scope

The attestation token proves the execution was recorded by a known ThetaZero TEE node at a specific time. Because it uses a shared HMAC key (not a hardware root-of-trust), verification currently requires trusting ThetaZero's attestation service. Full third-party hardware attestation verification — requiring no trust in ThetaZero — will be available with Q3 2026 AMD SEV-SNP upgrade.

📦

Layer 5 — RSA-4096 (Evidence Package Signing)

The exported ZIP is signed — proves provenance and post-export integrity

RSA-4096 Signed Evidence ZIP

RSA-4096

Algorithm

RSA-4096 with PKCS#1 v2.1 (RSASSA-PSS) signature scheme

What is signed

The complete evidence export ZIP — including all execution logs, Merkle roots, control mapping, and TEE attestation records.

Signature location

manifest.json inside the ZIP contains SHA-256 checksums of every file; manifest.sig is the RSA-4096 signature over manifest.json.

Public key

Published at /trust/signing-key.pem. Contact security@ for key fingerprint verification.

✅

This is the primary verifiable guarantee for a compliance reviewer. The signed ZIP is the artifact your auditor or legal team should inspect. It proves the package came from ThetaZero and was not modified after export — independently of ThetaZero's live systems.

🔍 How to Verify Independently

1 Download the evidence ZIP. Extract manifest.json and manifest.sig.

2 Retrieve ThetaZero's public key from https://thetazero.app/trust/signing-key.pem.

3 Verify: openssl dgst -sha256 -verify signing-key.pem -signature manifest.sig manifest.json

4 Optionally verify individual file checksums: sha256sum -c <(jq -r '.files[] | .sha256 + " " + .path' manifest.json)

5 "Verification OK" from step 3 confirms the package is authentic and unmodified. No trust in ThetaZero's live systems required.

❓

Reviewer FAQ

Common questions from compliance officers, auditors, and security teams

The homepage says "SHA-256 signed ZIP" but the enterprise page says "RSA-4096 signed ZIP." Which is correct?

Both, at different layers. SHA-256 is used to hash the contents of each file inside the ZIP — producing the checksums in manifest.json. RSA-4096 is used to sign manifest.json itself (the manifest.sig file). The SHA-256 hashes prove individual file integrity; the RSA-4096 signature proves the manifest (and therefore the whole package) came from ThetaZero and was not modified after export. See Layer 5 — RSA-4096 for verification steps.

The sample evidence page shows TEE attestation as "HMAC-SHA256 Signed." Is that weaker than the RSA-4096 signing on the enterprise page?

They're different things. HMAC-SHA256 is used for TEE attestation tokens — proof that a specific compute node ran a specific task under policy. RSA-4096 is used for evidence package signing — proof that the export ZIP is authentic. Neither is a substitute for the other. The HMAC-SHA256 attestation is a transitional mechanism; Q3 2026 it upgrades to hardware-level AMD SEV-SNP attestation. See Layer 4 for current scope.

What can I verify without trusting ThetaZero?

Two things are independently verifiable today with no reliance on ThetaZero's systems:

1. SHA-256 record integrity — recompute SHA-256(record_payload) and compare to record_hash in the export. If they match, the record was not modified after it was written.

2. RSA-4096 package signature — verify manifest.sig against ThetaZero's public key using any standard openssl command. If valid, the export is authentic and unmodified.

SHA-256 Merkle verification is also possible from the export (see Layer 3). AES-256-GCM at-rest encryption and HMAC-SHA256 TEE attestation currently require trusting ThetaZero's key material.

Where does Merkle hashing fit relative to per-record SHA-256?

Per-record SHA-256 (Layer 2) detects whether a single record was modified. Merkle hashing (Layer 3) detects whether records were deleted, added, or reordered in the log. You need both: an attacker who deletes a record without changing others would defeat Layer 2 alone. Merkle anchoring, once sealed, makes any structural change to the batch detectable.

How do I get the evidence export for a specific agent run?

Via API: GET /api/v1/executions/{execution_id}/audit-export — returns JSON or ZIP depending on Accept header.
Via dashboard: navigate to any execution → "Download Evidence Pack".
Enterprise plans also support scheduled delivery to S3/GCS. See API docs for full reference.

Can I see a sample evidence package before committing to ThetaZero?

Yes. The Sample Evidence Package page shows a fully populated KYC exception review execution including execution logs, control mapping, Merkle audit trail, and TEE attestation records — the same format your auditor would receive.

Questions for Our Security Team?

Compliance reviews, custom verification procedures, or questions not answered here — we respond within 2 business days.

Email Security Team Full Trust Pack Enterprise Plans