TEE Check
Our guarantee
Two guarantees on this page. First: the user's credentials never reach our servers — the session lives on their device or inside an isolated TEE-hosted client even our team cannot access. Second: the code generating verifications in production is provably the same code published on GitHub. Both confirmed by hardware, not by our word.
Where the credentials actually live
There are two SDK paths and the credential never leaves the trusted side of either:
- In-app SDK (mobile, browser extension). The user signs into the source site directly on their own device, in a webview or browser the user controls. Credentials, cookies, and session tokens never cross the network to us — we only ever see the redacted, signed claim that comes back out.
- Node SDK (server-side). When the verification has to run server-side, we host the user's browser session inside
TEE_REMOTE_BROWSER— a confidential VM. The credentials live entirely inside the enclave; even our own engineers, our cloud provider, and the host OS cannot read or modify what's in there. The hardware attestation below proves the enclave is running the published code, not a backdoored copy.
The threat model
Software alone cannot prove what code it's actually running. Any server can lie. The integrity guarantee has to hold even when an adversary controls the server, the operating system, the cloud provider, or us.
How it’s enforced
Our verification services run inside AMD SEV Trusted Execution Environments on Google Cloud Confidential VMs. Every verification carries a hardware attestation: a statement signed by the CPU itself, confirming that the running image matches exactly the open-source build we publish on GitHub. Not even our own team can inspect a running verification, modify its behavior, or swap in a different implementation.
How you verify
The attestation chain is independently checkable: verify the CPU's signature, then confirm the attested image hash against the one published on GitHub. Per-session attestations are listed on this page (TEE_K and TEE_A tabs below). The video walks through the end-to-end trust path.
What you still trust
AMD's SEV silicon (the hardware root of trust) and Google Cloud's Confidential VM platform. Both are independently audited and widely deployed in regulated industries: finance, healthcare, government.
The components
Each critical component runs inside its own TEE. TEE_K and TEE_A handle key material and verification orchestration. TEE_REMOTE_BROWSER hosts the user's browser session when the verification doesn't happen on the user's own device, so credentials still never leak to us. It's only used in the nodejs-sdk; the inapp-sdk uses the local in-app browser, where this is unnecessary.
Last checked: 17h ago
reclaim-tee
Verify your own session
Run the same verification on a session of your choice. We look up the hardware attestation hashes recorded for that session and confirm they match the canonical images Reclaim publishes for the moment the session ran.
JunJulAug
Monitoring started · May 8Aug 5
Today · Jul 13· 23 days ahead are placeholders for future runs