Attestation & verification

An enclave is only useful if you can tell it's real. Attestation is how you tell. The enclave's hardware signs a report that describes the machine and the software it runs, and the report includes a key that only the enclave holds. Your browser checks this report before it encrypts anything to that key.

The Verified badge#

In TEE mode, a model shows Verified only when all of these hold:

1. The server-side check passes. About once an hour, our server requests each TEE model's attestation with a fresh random nonce. It records whether the attestation verified and whether the same nonce came back.
2. Your browser's own check passes. At the start of a session, your browser fetches the attestation again, with a nonce it generates itself, and runs the checks below.
3. The response is signed. Each response carries the enclave's signature, which is checked against the key from that same attestation.

If any of these fails, there's no badge. The badge belongs to one model and one check, and it reflects the live state. A model that verified yesterday can fail today. Tacita never marks a model as verified in advance.

What your browser checks#

Your browser re-checks attestation at least once per session.

Enclave operators#

TEE models run in confidential-compute enclaves operated by two companies, on Intel TDX CPUs and NVIDIA confidential-computing GPUs. Every attestation report names its operator.

As of 27 October 2026, attestation verifies for 9 of the 12 TEE models. Kimi K3, Kimi K2.6 and Qwen 3.8 27B do not currently verify, so they show no Verified badge. You can still pick them, but you have no hardware proof for them. The operators and the list can change. The operator named in each live attestation report is the authority.

Check it yourself#

You don't have to take the badge on faith. These checks are listed from easiest to most thorough.

1. Watch the traffic#

Open your browser's developer tools, go to the Network tab and send a message in TEE mode. Find the request that carries your message:

• In the request body, every message's content is a long hex string, not your words. That includes earlier turns of the conversation.
• The body also carries two public keys: your session's key, and the model key your browser encrypted to.
• In the streamed response, each piece of the answer is also hex. Only the token counts are readable.

If you ever see your own words in a TEE request body, that's a bug. Please report it.

2. Read the attestation report#

In the same Network tab, open the attestation report your browser fetched for the model. It's a JSON document. Check that:

• The nonce in the report equals the random nonce your browser sent with the request for it.
• The signing key matches. The Ethereum address derived from the report's signing public key must equal the report's signing address, and that public key must be the model key from step 1.
• The report data starts with the signing address (bytes 0–19), and bytes 32–63 equal your nonce.
• The operator is named, Phala or NEAR AI.

For example, with viem:

import { publicKeyToAddress } from "viem/accounts";

// signingPublicKey: the uncompressed public key from the report (starts with 04)
// signingAddress, reportData, nonce: from the report and your request
const keyMatches = publicKeyToAddress(`0x${signingPublicKey}`).toLowerCase() === signingAddress.toLowerCase();
const rd = reportData.toLowerCase().replace(/^0x/, "");
const addressBound = rd.startsWith(signingAddress.slice(2).toLowerCase()); // bytes 0–19
const nonceBound = rd.slice(64, 128) === nonce.toLowerCase();               // bytes 32–63

3. Verify the hardware quote#

Steps 1 and 2 still trust the verifier's result. To remove that trust, verify the raw evidence in the report yourself:

• The Intel TDX quote. Verify it with a DCAP verifier, such as Phala's open-source dcap-qvl. Then check:
  • the quote's REPORTDATA field: the first 20 bytes must equal the signing address, and bytes 32–63 must equal your nonce;
  • the enclave is not in debug mode;
  • the enclave measurement (MRTD and RTMRs) matches the values the operator publishes for its software.
• The NVIDIA GPU evidence. Verify it with NVIDIA's attestation service (NRAS).

When these pass, the proof chains to Intel's and NVIDIA's signing keys, not to Tacita or anyone in between.

4. Check a response signature#

For each answer, the app fetches the enclave's signature for that response ID. You can see it in the Network tab. It's a standard EIP-191 signature, so any Ethereum library can verify it:

import { verifyMessage } from "viem";

const ok = await verifyMessage({ address: signingAddress, message: text, signature });

The signing address must be the one from the attestation report. There's a limit here. The signed text has the form sha256(request as the enclave saw it):sha256(response as the enclave saw it). The request and response are rewritten slightly on their way to and from the enclave, so you can't recompute those hashes. The signature proves that the attested enclave key produced the response with this ID. It doesn't prove the exact bytes.

What attestation doesn't cover#

• The web page itself. Attestation proves the enclave. It doesn't prove that the JavaScript you loaded encrypts correctly. Step 1 above is how you check that.
• Metadata. Model choice, timing, message sizes and token counts are visible outside the enclave.
• Hardware flaws. Attestation assumes that Intel TDX and NVIDIA confidential computing work as designed.

See Privacy modes for the full list.