EOA wallets — TEE mode

In TEE mode, key generation and signing happen inside a Google Confidential Space workload backed by AMD SEV-SNP. The reconstructed private key only ever exists inside the TEE’s encrypted memory, for the milliseconds a signing operation takes. Sigil operators, CI pipelines, and every other service account are explicitly denied KMS decrypt access to the shares.

This is the right choice for:

• Institutional custody where compliance demands a hardware-attested signing boundary.
• AI agents and backend automation that need to sign without a user in the browser.
• Treasury workflows triggered by cron / webhooks.

Address shape, network coverage, and SDK ergonomics are identical to a client-mode EOA. The difference is purely where the key lives.

What is a TEE?

A Trusted Execution Environment is a hardware-enforced isolation boundary. The CPU encrypts the workload’s memory with keys that the host operating system, hypervisor, and cloud operator cannot access. Even an attacker with physical access to the server cannot read the contents of a running TEE.

Google Confidential Space builds on AMD SEV-SNP (Secure Encrypted Virtualization — Secure Nested Paging):

• Memory encryption — every page of the workload’s RAM is encrypted with a key managed by the AMD Secure Processor.
• Hardened OS — a minimal, read-only container runtime with no SSH, no shell, and no package manager.
• Integrity measurement — the firmware, OS, and container image are measured at boot and any tampering breaks the attestation chain.

The two shares

Share	Where it lives
TEE share	Encrypted, decryptable only by the attested TEE workload
Provider share	Sigil database, envelope-encrypted with Cloud KMS

A 2-of-2 threshold replaces the 2-of-3 SSS scheme used in client mode. There is no device share, no recovery share, and no recovery flow — because no share ever lives on an end-user device, there is nothing for the user to lose.

If the TEE workload is replaced (e.g. during a version upgrade), the new image is re-attested before it can access any key material. See the KMS lockdown section below.

Attestation

When the TEE workload starts, Google issues an OIDC attestation token that cryptographically proves:

1. The exact container image digest running in the enclave.
2. The workload is executing on genuine AMD SEV-SNP hardware.
3. Debug mode is disabled (no memory inspection is possible).
4. The Confidential Space environment has not been tampered with.

Sigil uses this token to gate access to encrypted key material via Cloud KMS.

KMS lockdown

Cloud KMS is configured so that the decrypt permission for wallet shares is granted exclusively to the attested TEE workload via a Workload Identity Pool condition:

• The condition matches the exact container image digest, the Confidential Space attestation issuer, and the secboot flag confirming SEV-SNP is active.
• Sigil operators, CI pipelines, and every other service account are explicitly denied decrypt access.
• Even with full access to the Sigil database, an attacker cannot decrypt any share without running the correct, unmodified container on real TEE hardware.

Caution

Updating the TEE container image requires updating the Workload Identity Pool condition to trust the new image digest. This is an intentional safeguard — unauthorized code changes cannot silently gain access to key material.

What the TEE does

The TEE workload has a narrow, auditable scope:

• Generate a new private key using the hardware RNG.
• Split the key into two shares (2-of-2 threshold) and encrypt each share before it leaves the TEE.
• Reconstruct the key from its two shares when a signing request arrives.
• Sign the transaction or message per the target network’s canonical format.
• Wipe all plaintext key material from memory before returning the response.

The private key exists in unencrypted form only inside the TEE’s encrypted memory, for the duration of a single operation.

What the TEE cannot do

• Exfiltrate keys — network egress is restricted to the Sigil API response path. No outbound access to arbitrary endpoints.
• Persist keys to disk — the workload runs on an ephemeral filesystem. Nothing survives a restart.
• Be silently modified — any change to the container image produces a different digest, which breaks the attestation and revokes KMS access.
• Operate without attestation — the workload cannot obtain decryption keys unless Google’s attestation service confirms the hardware and software measurements.

How an agent or backend signs

TEE wallets unlock the server-to-server signing API: your backend or an AI agent can request signatures using a secret key (sk_live_…) or a session token (as_live_…), without any browser interaction.

import { SigilS2S } from '@sigilkeys/sdk';

const sigil = new SigilS2S({
  apiBaseUrl: 'https://api.sigilkeys.com',
  secretKey: process.env.SIGIL_SECRET_KEY!,
});

const { signature } = await sigil.sign({
  walletId: 'WALLET_UUID',
  network: 'base',
  message: 'audit-log-2026-06',
});

For agent workloads — limited-scope, policy-gated session tokens that can sign only specific shapes of transaction — see Agents quickstart.

Dependencies

• Sigil Confidential Space deployment (already managed by Sigil): VM running the attested image, behind a VPC-internal load balancer.
• Cloud KMS (already managed by Sigil): wraps the TEE share’s DEK with a key the WIP condition gates to the attested workload.
• Nothing on your side: no browser, no user, no recovery webhook. Provision an organisation in TEE mode and you can sign immediately from your backend.

Comparison with other approaches

Several wallet infrastructure providers use similar enclave architectures. The table below contrasts the two most common cloud-native models.

	Sigil (Confidential Space)	AWS Nitro Enclaves
Hardware	AMD SEV-SNP	AWS Nitro
Attestation format	OIDC token (Google)	Attestation document (AWS)
KMS integration	Google Cloud KMS + WIP condition	AWS KMS + enclave policy
Memory encryption	Full VM memory	Enclave memory partition
Key access control	Workload Identity Pool	IAM policy on enclave PCRs

Both achieve the same core guarantee: the cloud operator and the wallet provider cannot access plaintext keys.

Caveats

• No recovery flow. A TEE wallet’s shares are sealed to the workload’s identity. There is no end-user OTP path. If the TEE deployment is destroyed without rotating shares to the new deployment, the keys are unrecoverable. Sigil’s operational procedures keep at least two attested deployments in parallel during upgrades to prevent this.
• Per-tx latency is slightly higher than client mode (signing goes over the wire to the TEE), typically +100–200 ms. For agent workloads this is negligible; for interactive UX, client mode is often the better choice.