The encryption layer for AI apps.

The token — for example [SSN_8e21] — not the plaintext. Your database column stores a short string with no sensitive information in it. The real value exists only inside the Subzero vault, encrypted under your KMS key. An attacker with full database access sees only tokens.

No. Your raw values and your tokens never pass through Iceberg's infrastructure in readable form — raw values are encrypted in the browser before they reach us, and tokens live in your own database. What Iceberg holds in the vault is encrypted ciphertext, wrapped under a key that lives in your cloud KMS account. Without a live call to your KMS — using credentials we don't hold — that ciphertext is unreadable. We have no path to your plaintext.

No. Tokens are strings. You store them in whatever column you already have — VARCHAR, TEXT, any string-compatible type. No migrations, no new tables, no structural changes to your existing data model.

Yes. The browser Element is optional. If your backend already holds a sensitive value, send it directly to POST /v1/tokenize using a server-scoped sz_live_... key. The response is the token. You can also batch-tokenize up to 100 values per request via POST /v1/tokenize/batch for ETL pipelines and data migrations.

Your server mints a reveal grant — a single-use, 60-second token scoped to a specific vault token and the allowed browser origin. The browser passes the grant ID to a Subzero reveal iframe, which decrypts the value inside the iframe and displays it. Plaintext never enters your DOM or appears in your network tab.

You can migrate it using the batch tokenize endpoint. Read the existing values, send them in batches of up to 100 to POST /v1/tokenize/batch, and write the returned tokens back. If you register the entity type as deterministic, retries always return the same token for the same value — so the migration is idempotent and safe to re-run.

Subzero works with your existing KMS on AWS (KMS), GCP (Cloud KMS), Azure (Key Vault), or a hardware HSM. You create a customer-managed key in your existing account and give Subzero permission to call Encrypt and Decrypt on it. No key migration, no new cloud account.

No. Subzero is entirely whitelabeled and controlled from your existing platform. Your clients never see the Subzero name, never create an account, and never interact with any Subzero interface. Onboarding happens through your existing client setup flow — you provision the encryption namespace per client on the backend.

You provision a KMS namespace per client — either in your own cloud account (one key per client, fully isolated) or in the client's own cloud account if they want to bring their own key. Either way, each client's data is encrypted under a key that cannot decrypt any other client's data. A breach of one namespace doesn't touch the others.

Only if you've explicitly granted that role reveal access in your policy configuration. You define the rules — which roles, for which clients, under what conditions. Subzero enforces them and logs every access. This means you can give support staff access where they need it while keeping it revocable and auditable.

Each client's KMS key is in an isolated namespace. Your platform holds no master key that can decrypt across clients. You can demonstrate this to a client by showing them their KMS key ARN and the policy that gates who can call Decrypt on it. The claim "even we can't read your data without your authorization" becomes a verifiable technical fact, not a marketing promise.

Rotate the key in your KMS, then call Subzero's re-wrap endpoint. Re-wrapping re-encrypts every data key under the new KMS key without touching the vault data itself — no data migration, no re-tokenization. Once complete, the old key can no longer decrypt anything, and any attacker holding encrypted blobs from before the rotation is locked out.

Timestamp, caller identity (the IdP JWT subject), the token revealed, entity type, the policy rule evaluated and its result, and the KMS call ID. The KMS call ID means you can cross-verify every Subzero reveal log entry against your own CloudTrail or audit log — confirming the decrypt actually happened, at that time, for that caller.

Yes. Subzero can be deployed inside your VPC so that no sensitive data transits the public internet before tokenization. The vault and tokenization service run in your infrastructure; your KMS keys stay in your cloud account. Contact us to discuss deployment options for your environment.