How to verify you are talking to TeeChat’s secure OpenAPI service

What is TeeChat OpenAPI?

TeeChat OpenAPI is an OpenAI-compatible HTTP API at openapi.teechat.ai. You point an existing client (OpenClaw, WorkBuddy, …) at our base_url, keep a normal API key, and keep calling /v1/chat/completions the way you already do. No proprietary SDK is required for that path. For a product walkthrough with WorkBuddy, see OpenAPI GA with WorkBuddy.

Unlike a typical cloud model API that terminates TLS on ordinary servers (where operators or a compromised host could read prompts), TeeChat’s OpenAPI service is designed so that:

1. TLS ends inside confidential hardware (a measured SEV-SNP / SGX environment), not on a plain host reverse proxy.
2. You can independently check that the live endpoint matches published open-source measurements (this post).
3. The product promise is “verifiable TEE proxy” — prompts are processed for inference inside that boundary, then discarded for the OpenAPI path (no chat history product on that API). After TLS decrypt, plaintext appears only briefly inside the confidential container; that is not end-to-end encryption (the gateway never sees plaintext).

How that helps protect your data in practice

It is not end-to-end encryption in the strict sense. Stronger client-enforced confidentiality is TeeChat ope.* + the TeeChat SDK (confidential chat). OpenAPI is for integration convenience with optional verification.

Most OpenAI clients never call attestation — that is intentional. This post is for people who do want proof: security reviewers, monitors, and integrators who can run a few extra HTTPS calls (or use TeeChat Settings → Inference → OpenAPI verify).

Canonical technical pin (byte layout + JSON): docs/attestation-challenge.md in teechat-openapi.

What you can verify

You want confidence that:

1. TLS terminated inside TeeChat’s measured OpenAPI service (SGX enclave or confidential VM), not a random proxy.
2. Challenge–response returns fresh data — not an attacker’s cached old quote.
3. Your TLS connection uses a certificate public key that the hardware quote attested — so no middlebox can intercept the data.

Quick paths

Comparison of the four paths:

Desktop — full verification

1. Install the TeeChat desktop app and sign in.
2. Open Settings → Inference → OpenAPI verify.
3. Click Verify OpenAPI.

The client runs the challenge on this TLS session, verifies quote cryptography and golden digests / SHA256SUMS, and binds the peer certificate SPKI. On success, open View field details.

This is the full-verification path for most users. The browser cannot read the peer certificate, so the web Settings check cannot replace desktop full verify.

Web light preview (same as curl — not full verification)

Open this link in a new browser tab:
https://chat.teechat.ai/app?settings=inference&sub=openapi

Path: Settings → Inference → OpenAPI verify (sign in to TeeChat first). Then click Fetch challenge evidence. Against the public challenge API this returns the same class of JSON as curl below; the difference is the web Settings page needs you signed in, while curl hits the public endpoint with no sign-in. The light check only runs structural checks and explains fields — not full verification.

For full verification: see Desktop — full verification above, or use teechat-openapi-attest below.

Evidence-only curl (not full verification)

NONCE=$(openssl rand -base64 32 | tr '+/' '-_' | tr -d '=\n')
curl -fsS -X POST https://openapi.teechat.ai/v1/attestation/challenge \
  -H 'Content-Type: application/json' \
  -d "{\"nonce_b64\":\"${NONCE}\"}" | tee /tmp/openapi-challenge.json

For full verification, use the full verifier or TeeChat desktop.

Full verifier (recommended)

Clone teechat-openapi and run from that repository root:

cargo run -p teechat-openapi-attest -- verify https://openapi.teechat.ai

Or, after installing the binary:

teechat-openapi-attest verify https://openapi.teechat.ai

The verifier will:

1. Prefer: fetch openapi-edge-attest.json and SHA256SUMS from GitHub Releases.
2. Open a TLS connection, read the peer leaf SPKI, and POST a fresh challenge on the same session.
3. Verify the hardware quote (public VIP is an SNP report today; remotely verifiable SGX DCAP ECDSA is also accepted) plus collateral.
4. Recompute report_data from your nonce and the JSON identity fields.
5. Match build_version, code_hash, measurement, and policy_hash against the app allowlist row for this hostname; if SHA256SUMS is present, require code_hash to appear there.
6. Resolve the row’s golden_version against the public golden digests channel (TEE / image pins).
7. Bind edge.tls_cert_spki_sha256 to the live TLS peer (VIP monitors may pass --skip-session-spki).

Exit code 0 and "ok": true mean all checks passed. Exit code 2 means verification failed — inspect stderr and the JSON verdict.

Trust: GitHub primary, teechat.ai fallback

Because OpenAPI (like OPE and the Inference Engine) is open source, GitHub Releases are the primary pin:

• Release page: https://github.com/Lightec-AI/teechat-openapi/releases
• Assets: openapi-edge-attest.json (measurement allowlist) and SHA256SUMS (binary digests)

If GitHub is unreachable, the verifier falls back to TeeChat’s Ed25519-signed www mirror:

• manifest.json
• manifest.sig

In that case the JSON verdict sets "trust_source": "teechat_fallback" and fills trust_fallback_tip (also printed on stderr). When you can reach GitHub again, open the release page, download openapi-edge-attest.json / SHA256SUMS, and confirm they list the same build_version, code_hash, and measurement as your result.

Interpreting a pass

When verification succeeds, you get JSON similar to (public openapi.teechat.ai is an SNP CVM today; field names match teechat-openapi-attest and desktop full verify):

{
  "ok": true,
  "endpoint": "https://openapi.teechat.ai",
  "hostname": "openapi.teechat.ai",
  "quote_format": "snp_report",
  "build_version": "0.8.1",
  "code_hash": "<64 hex>",
  "measurement": {
    "kind": "launch_digest",
    "launch_digest": "<64 hex>",
    "image_digest": "<64 hex>"
  },
  "golden_version": "openapi-golden-…-seal-sync-app-0.8.1",
  "policy_hash": "<64 hex>",
  "tls_cert_spki_sha256": "<64 hex>",
  "peer_spki_sha256": "<64 hex>",
  "session_bind_mode": "spki",
  "manifest_epoch": 1,
  "manifest_key_id": "github:teechat-openapi:v0.8.1",
  "trust_source": "github",
  "golden_trust_source": "github",
  "github_release_url": "https://github.com/Lightec-AI/teechat-openapi/releases/tag/v0.8.1",
  "trust_fallback_tip": "",
  "hardware": {
    "kind": "snp_report",
    "product": "…",
    "launch_measurement": "<96 hex>",
    "challenge_canonical_launch_digest": "<64 hex>",
    "policy_debug": false,
    "guest_svn": 0
  },
  "verified_at_unix": 1750000000
}

What a pass proves: you reached a host whose TLS certificate matches the quote, the quote is fresh for your nonce, the hardware signature verifies, and the running OpenAPI service matches both the app Release row and golden digests (GitHub primary; teechat.ai signed mirrors if GitHub was down).

What it does not prove: prompt confidentiality beyond TLS-in-TEE (that is the OPE / confidential-chat path — see the intro).

Threat model

Monitors probing a VIP without owning the client TLS socket may use --skip-session-spki and only check “live endpoint looks allowlisted.” Serious integrators should bind SPKI.

We omit protocol and binding detail here — interested users and security researchers should read the open-source repo and the links below.

Further reading

• teechat-openapi SECURITY.md
• Attestation challenge wire format
• How to verify confidential chat (OPE / in-app Settings path)

← All posts