ZK KYC in a Trusted Execution Environment: Cryptographic Identity for the Agentic Era

Identity verification is a strange problem. The goal of KYC — Know Your Customer — is fundamentally about confidence: confidence that the person or entity on the other side of a transaction is who they say they are, and that they're allowed to be there.

But the way most KYC systems achieve that confidence involves collecting, storing, and repeatedly exposing data that was never meant to travel: passport scans, date of birth, full legal name, nationality, government ID numbers. That data gets uploaded to verification vendors, ingested into compliance databases, and duplicated across systems — each copy a new liability, each transfer a new risk.

Zero-knowledge proofs offer a different answer to the same question. And when you run ZK verification inside a Trusted Execution Environment, you get something that didn't exist before: cryptographic proof of an identity claim, verified in hardware, with no PII ever touching your infrastructure.

What Zero-Knowledge KYC Actually Means

A zero-knowledge proof lets a prover demonstrate that they know a fact — or that a statement about their data is true — without revealing the underlying data.

Applied to identity, the pattern looks like this:

1. A user presents their government-issued identity document (passport, national ID)
2. The document's digital signature — issued by the government's signing authority — is verified cryptographically
3. A ZK circuit generates a proof over specific claims: I am over 18, I am a citizen of country X, my document is valid and unexpired
4. The proof is sent to the verifier, who can confirm the claim is true without learning anything else about the document

The key property: the government's signature on the document becomes the root of trust. The verifier doesn't need to see the document. They verify the proof about the document, backed by the government's cryptographic authority.

This is a fundamental shift from "send us your passport" to "prove your passport is valid and you meet the criteria." The user's raw data never leaves their device.

Projects like ZKPassport are building open-source implementations of this pattern using passport chip NFC data and Noir ZK circuits, with verification available both as SDKs and Solidity smart contract verifiers.

The Gap: Who Verifies the Verifier?

ZK proofs solve the user-side problem elegantly. But they introduce a question on the verifier side that most implementations don't address:

How does anyone know the verification ran correctly?

When an enterprise compliance system accepts a ZK proof, they're accepting it from a verification service — a process running somewhere in a cloud environment. That environment might be correct. It might have been patched, modified, or logged without the operator knowing. The proof is valid, but can you prove what code ran to verify it?

This matters more than it might seem. Regulators and compliance officers increasingly want to see not just that a check was performed, but how it was performed. A "we ran the check" assertion from a software service isn't the same as a hardware-signed record of what code ran, what inputs it received, and what it concluded.

This is exactly where Trusted Execution Environments close the loop.

TEE-Attested Verification: The Dual Trust Layer

A TEE is a hardware-enforced isolation boundary in the CPU. Code running inside a TEE — an AWS Nitro Enclave, an Intel TDX Trust Domain, or an AMD SEV-SNP confidential VM — executes in encrypted memory that the host operating system, hypervisor, and cloud operator cannot read or tamper with.

More importantly, the TEE produces an attestation document: a hardware-signed certificate that proves exactly what code is running inside, what kernel is loaded, and that the environment hasn't been modified. The attestation signature traces back to a key embedded in the CPU at manufacturing time — it cannot be forged.

Combining ZK proof verification with TEE attestation creates a two-layer trust architecture:

Layer	What it proves	Root of trust
ZK Proof	The identity claim is true (age, nationality, document validity)	Government signing authority (CSCA/DSC certificate chain)
TEE Attestation	The verification ran in an isolated, tamper-proof environment	CPU hardware (AWS Nitro, Intel, AMD)

The ZK proof proves the claim. The attestation proves the verification. Neither layer alone is sufficient for enterprise compliance requirements; together, they produce an audit trail that's hardware-anchored at both ends.

How the Verification Flow Works

The integration pattern has three stages:

Stage	Where it runs	What happens	What leaves
1 — Proof Generation	User's mobile device	NFC reads the passport chip → verifies the government signature chain (CSCA → DSC → document) → ZK circuit generates a proof over declared claims (age, nationality, validity)	The ZK proof only — raw document data stays on-device
2 — TEE-Attested Verification	Secure enclave (Nitro / TDX / SEV-SNP)	Receives the ZK proof → verifies against the trust anchor registry → produces structured claims → signs the result with the TEE attestation key	Attested claims + hardware-signed attestation document. No PII.
3 — Downstream Consumption	Enterprise system or AI agent	Verifies the TEE attestation is valid and untampered → consumes the structured claims to authorize the action	Authorization decision — no raw document, no PII ever present

The attestation document from Stage 2 is hardware-signed evidence that a specific, measured binary produced this specific result in an isolated environment. The agent in Stage 3 never sees a passport number, date of birth, or full name — only hardware-verified claims. That's a fundamentally different trust model than "the user told us."

The Agentic Identity Problem

This architecture matters especially for AI agents because agents have a specific problem that humans don't: there's no principled way to verify who an agent is acting on behalf of.

Today, when an AI agent executes a financial transaction, submits a compliance document, or accesses a regulated service, there's typically no cryptographic link between the agent's action and the verified identity of the human it's acting for. The agent was told to act for a given user; there's no evidence chain that survives the interaction.

TEE-attested ZK identity changes this. The pattern:

1. Identity is established once, on the user's device, using their government document
2. The ZK proof + TEE attestation produces a dual-trust claim: hardware-verified, PII-free
3. The AI agent is issued this attested identity token
4. Every action the agent takes can be cryptographically linked back to a verified human identity

The chain is auditable and non-repudiable. A regulator asking "prove this agent transaction was authorized by a verified identity" gets a hardware-signed attestation document, not a log entry from a database that an admin could edit.

What This Enables for Regulated Industries

For financial services, the implications are direct. AML and KYC requirements demand that institutions know who their customers are and keep records proving it. TEE-attested ZK KYC provides a compliance record that is:

• Privacy-preserving: No PII stored on the institution's infrastructure
• Tamper-evident: Hardware-signed attestation that the verification ran correctly
• Auditable: Every verification event produces a structured, hardware-anchored record
• Portable: The same attested claim can be used across multiple services without re-running verification

For healthcare workflows where patient identity needs to be verified before an agent accesses records, or for government services where nationality and age must be proven before granting access, the same architecture applies. The claim changes; the trust model doesn't.

Layered Confidentiality

The TEE adds a third property beyond privacy and auditability: confidentiality of the verification logic itself.

Compliance verification often involves business logic that organizations don't want disclosed: specific risk thresholds, watchlist matching algorithms, country-based restrictions. Running verification inside a TEE means the logic is protected from external inspection — only the result is visible.

Combined with the attestation mechanism, this creates an interesting property: external parties can verify that the check ran correctly and what code ran it, without being able to reverse-engineer the policy embedded in that code.

This is the basis for what we call a compliance vault — a TEE-sealed environment where sensitive PII can be temporarily handled for legal compliance purposes, accessed only through policy-controlled interfaces, with every access cryptographically logged.

Getting the Architecture Right

A few practical considerations for production deployments:

Start with TEE-attested verification, not proof generation. Running ZK proof generation inside a TEE is technically feasible on AWS Nitro and AMD SEV-SNP (which have no enclave page cache constraints), but it's engineering work. TEE-attested verification is straightforward today — the verification SDK runs headlessly inside an enclave, and Nitro Enclaves fully support it.

The trust anchor registry needs to be accessible from the TEE. Verification requires access to the set of known government signing certificates. The TEE either bundles a pinned registry snapshot or fetches it over an attested TLS channel. Both approaches work; pinning is simpler for getting started.

Key custody for server-side flows. In mobile flows, keys live in the device keychain — the device is effectively a TEE for this purpose. For server-side and agentic flows where there's no user device present, key custody needs explicit design: Treza's hardware root of trust seals keys to the TEE, binding them to a specific software measurement so they can only be used by attested code.

The Compliance Story

For CISOs and compliance teams, the pitch is simple:

The conventional answer to "how do you protect user PII during KYC?" is: encryption at rest, access controls, audit logs, and trust us. That answer depends entirely on organizational controls — processes that can fail, be bypassed, or be falsified.

The ZK + TEE answer is: the PII never reached your infrastructure. Here is hardware-signed evidence of what code ran and what it concluded. The evidence was produced by a CPU that neither you nor the cloud operator can tamper with.

One of these answers survives a regulator asking hard questions. The other requires them to trust your internal controls.

---

Treza builds privacy infrastructure for crypto and finance. Deploy workloads in hardware-secured enclaves with cryptographic proof of integrity. Learn more.