Subzero

Meet Subzero.

Product

Subzero is a tokenization API with browser SDKs, server SDKs, and warehouse connectors. Drop it into your stack at any capture point — a form field, an API endpoint, a data pipeline — and it replaces sensitive values with stable tokens your app can store, query, and pass to LLMs without ever touching the real data.

Tokenization & data custody

→ Browser Elements — iframe-isolated fields that tokenize before your JavaScript ever sees the value

→ Server SDK + API — tokenize server-held values, mint one-time reveal grants

→ Warehouse connectors — batch tokenize via Fivetran, dbt, Snowflake external functions, BigQuery remote functions

→ Customer-owned KMS — envelope encryption, your AWS / GCP / Azure key wraps every data key

Subzero can be breached, and your data still isn't.

Subzero is an embeddable data protection layer you ship as part of your own product. Your clients never interact with Subzero directly — they use your UI, your branding, your dashboard. Behind the scenes, each client's sensitive data is encrypted under keys only they control.

Embeddable tokenization & client data isolation

Subzero

→ Whitelabel — fully embedded in your product; clients never see the Subzero name

→ Per-client key isolation — each client gets their own KMS namespace; you can't read one client's data with another's key

→ You control access policy — define which roles in your platform can reveal plaintext, under what conditions

→ No client setup required — clients don't need a Subzero account; onboarding is entirely through your existing flows

A breach of your platform can't expose a client's data. That's a guarantee you can put in a contract.

Subzero is an encryption layer that sits between your application and your data stores. It intercepts sensitive values at capture, wraps them cryptographically under your own KMS keys, and stores only tokens downstream. Plaintext can only be recovered through a policy-gated, identity-verified, fully audited reveal call.

Encryption layer & access control

Subzero

→ Your KMS, your keys — Subzero never holds key material; every decrypt is a live call to your AWS / GCP / Azure account

→ Policy-gated reveals — define exactly who can access plaintext, under what conditions, time-bounded

→ Immutable audit trail — every tokenize and reveal logged, cross-verifiable with your KMS CloudTrail / audit logs

→ Blast radius containment — a leaked database, a compromised service account, or a rogue LLM call returns tokens, not data

Iceberg can be fully compromised. Your data still can't be read.

How it works

Integration

Three surfaces, one model: tokenize at capture, store tokens everywhere, reveal only under policy.

Embed Subzero into your product in three steps. Your clients never touch the integration — it's entirely managed through your existing platform.

Three questions that matter: who can access plaintext, under what conditions, and what's recorded when they do.

Browser Elements

Plaintext never touches your JavaScript.

Sensitive fields render inside an isolated iframe. The user types in Subzero's sandbox — not your page. On tokenize, your code receives only the vault token via onTokenize.

1 User types inside the Subzero iframe — value never enters your DOM
2 Value encrypts in the browser, sent as POST /v1/tokenize
3 Your page receives [SSN_8e21] — store or submit it

Social Security Number

Secured by Subzero

const sz = Subzero('sz_pub_...', { apiBaseUrl: '/v1' });

const ssnField = sz.createField({
  entityType: 'SSN',
  container:  '#ssn-field',
  format:     { type: 'ssn' },
  onTokenize: (token) => {
    document.getElementById('ssn_token').value = token;
    // token = "[SSN_8e21]" — plaintext never left the iframe
  },
});

Server SDK / API

Tokenize server-side or mint one-time reveal grants.

If your backend already holds a value, tokenize it directly. When a real value is needed, mint a short-lived grant — your server controls who can reveal and when.

1 Tokenize server-held values via POST /v1/tokenize with sz_live_...
2 Store only tokens in your database — never plaintext
3 Mint a reveal grant on demand — single-use, 60s TTL, origin-locked

Your server holds value

POST /v1/tokenize

Subzero returns token

store token only

Your DB [SSN_8e21]

from subzero import SubzeroClient

client = SubzeroClient(api_key="sz_live_...")

# Tokenize
token = client.tokenize(entity_type="SSN", value="123-45-6789")
# token → "[SSN_8e21]"

# Mint a reveal grant when a real value is needed
grant = client.create_reveal_grant(
    token=token,
    allowed_origin="https://app.yourcompany.com",
    client_public_key_jwk=jwk,   # from browser
)
# grant.grant_id → pass to browser — single-use, 60s TTL

Bulk & Warehouse

Connect your pipeline. Tokens flow in, plaintext never does.

Batch tokenize up to 100 values per request for ETL ingest. Reveal via Snowflake external functions, Databricks UDFs, or BigQuery remote functions — gated by policy and role.

1 Batch tokenize during ingest — POST /v1/tokenize/batch
2 Warehouse stores tokens natively in Snowflake / BigQuery / Databricks
3 Analysts reveal via SQL function — only authorized roles, fully audited

Snowflake BigQuery Databricks Fivetran dbt

Raw data in

123-45-6789 john@example.com Jane Doe

POST /v1/tokenize/batch

Stored in warehouse

[SSN_8e21] [EMAIL_c4d1] [PERSON_a8f3]

{
  "items": [
    { "index": 0, "entity_type": "SSN",    "value": "123-45-6789" },
    { "index": 1, "entity_type": "EMAIL",  "value": "john@example.com" }
  ],
  "context": { "source": "fivetran", "pipeline_id": "crm-contacts" }
}

// Response
{ "items": [
    { "index": 0, "token": "[SSN_8e21]" },
    { "index": 1, "token": "[EMAIL_c4d1]" }
]}

01

Embed the SDK into your product

Add Subzero's server SDK to your backend and optionally drop in browser Elements for client-facing forms. Your product's UI stays entirely unchanged — Subzero intercepts sensitive values before they ever reach your database.

02

Provision a KMS namespace per client

When you onboard a new client, you provision a dedicated encryption namespace — either in your own cloud account or in theirs. Each client's data is encrypted under keys that are entirely isolated from every other client. You configure this through your existing admin dashboard; no client-side Subzero setup required.

03

Set access policy — then let Subzero enforce it

Define which roles in your platform can reveal plaintext for which clients, under what conditions. Subzero enforces those rules on every reveal call and logs everything. Your support team accesses what they're authorized to — nothing more.

What your clients experience

Nothing different.

Clients log into your product, fill in your forms, see your dashboards. Subzero is invisible to them. The only difference is that their sensitive data is now encrypted under keys they own — and you can prove it.

Who can access plaintext?

Only callers your policy explicitly allows.

Every reveal call is evaluated against a policy rule you define: caller identity (via your IdP's JWT), entity type, and time bounds. There is no ambient access — a service account, a compromised API key, or an over-permissioned LLM call returns a token, not the underlying value.

Under what conditions?

Policy-gated, identity-verified, time-bounded.

Reveal grants are single-use and expire in 60 seconds. They are scoped to a specific token and an allowed origin. There is no bulk-reveal path that bypasses policy. Your KMS must authorize the unwrap — which means a real-time call to AWS / GCP / Azure on every single reveal.

What's logged when they do?

Everything, cross-verifiable with your KMS.

Every tokenize and reveal is logged with timestamp, caller identity, token, entity type, and the policy rule evaluated. The corresponding KMS call ID is recorded — so you can verify in your own CloudTrail that the decrypt actually happened, when, and by whom.

Blast radius if something goes wrong

A leaked database returns tokens. A compromised service account returns tokens. A misconfigured LLM returns tokens.

Plaintext is only recoverable through a live KMS call, against a valid policy, from an authorized identity. Removing any one of those three breaks the chain.

✗

Database breach

Attacker sees [SSN_8e21] — useless without your KMS

✗

Subzero infrastructure compromised

Attacker sees encrypted blobs — no key material stored here

✗

Over-permissioned LLM / agent

No reveal policy match — returns token, reveal denied

How it holds together

Architecture

Two things move through the system: tokens — meaningless placeholders that flow freely through apps, databases, and LLMs — and the encrypted mapping back to real values, which only unlocks through a key the customer controls.

Five stages, each with a defined security boundary. At no stage does Iceberg hold both the encrypted data and the key needed to decrypt it. The KMS call happens in your cloud account — we only ever see the result.

Capture

Frontend Elements

Drop-in fields render as isolated components. Sensitive values go straight from the browser to Iceberg's tokenization endpoint — they never transit your servers or logs.

browser → tokenize() → app receives [TOKEN] only

Tokenize

Format-preserving placeholders

Each value becomes a stable token with enough shape for an LLM or SQL query to reason about — without ever seeing the value.

"John Smith" → [PERSON_a8f3] · 123-45-6789 → [SSN_8e21]

Encrypt

Envelope encryption, customer-owned keys

The token → real-value mapping is encrypted with a data key wrapped by your KMS. Iceberg never holds a master key — every unwrap is a call to your cloud account.

DEK encrypts mapping · DEK wrapped by customer KMS

Store & run

Tokens everywhere downstream

Databases, vector stores, embeddings, and every LLM call operate on tokens. A leaked log or over-permissioned query returns placeholders — not data.

Postgres / Snowflake / vector DB / LLM ← tokens only

Reveal

Policy-gated rehydration

When a real value is genuinely needed, Iceberg checks the caller's identity against policy, calls your KMS to unwrap, and returns the value for that single, audited moment.

request + identity → policy check → KMS unwrap → value (once)

An agent can't leak what it never had.

Agent fabric

Multi-agent systems are delegation chains. Today, context travels that chain as plaintext. Iceberg makes tokens the default unit of exchange — and lets every hop only narrow what the next one can see.

As AI features enter your product, the delegation chain grows. Subzero ensures that sensitive client data stays tokenized at every hop — your orchestrator, your retrieval agent, your third-party tools — so a misconfigured agent or a prompt injection can't exfiltrate real data.

AI agents are a new attack surface. Context passed to a third-party model, an MCP tool, or a retrieval pipeline is context that can be exfiltrated. Subzero ensures that context is always tokens — and that reveal is a privileged, audited action, not ambient access.

Orchestrator

full grant
(user-authorized)

Research agent

reveal:
SSN-last-4 only

3rd-party agent

tokens only
no reveal

Tool / MCP server

tokens only
no reveal

Each hop attenuates the grant — capability tokens narrow down the chain, never expand

Same primitive, four blast radii

Tokenize → attenuate → reveal-under-policy → audit. One loop, applied from a single field to an entire organization.

Same primitive, four blast radii

Tokenize → attenuate → reveal-under-policy → audit. One loop, applied from a single field to an entire organization.

Containment at every scope

Subzero applies the same model at any scope. A breach at any level returns tokens, not data.

Field-level

A single value — SSN, account number — tokenized at capture.

Blast radius: one field

Document-level

Sensitive spans within a document tokenized; structure and context stay usable.

Blast radius: one document

Org-to-org

Tokenized data crosses boundaries; detokenization only at authorized endpoints, under the sender's keys.

Blast radius: one relationship

Agent-to-agent

Delegation chains exchange tokenized context by default. Reveal is a privileged, audited tool call — never ambient context.

Blast radius: the trust fabric

Model training & embeddings

Data sent to an LLM for fine-tuning or embedded into a vector store is tokenized first. A stolen model or a compromised vector index returns token strings — not the values that trained them. You can rotate a leaked key. You can't un-train a model.

Blast radius: the model itself

Model training & embeddings

When you build AI features over client data — fine-tuning, RAG, embeddings — that data is tokenized before it reaches the model. Client values never bake into your model weights or your vector store. A stolen index returns tokens, not their data.

Blast radius: the model itself

Model training & embeddings

Plaintext in a model's training set or a vector store is permanent. You cannot rotate it out. Subzero ensures that data ingested into LLMs — for fine-tuning, RAG, or context — is always tokenized. A model exfiltration or a vector store breach returns token strings. Training contamination becomes a non-event.

Blast radius: the model itself

Custody model

Your KMS. Your keys. Nothing in our infrastructure is readable without you.

Every value Iceberg holds is wrapped by a data key that only your KMS can unwrap — on AWS, GCP, Azure, or an HSM you manage. Six components carry a value from capture to authorized reveal. At no point does Iceberg hold a key that could decrypt your data without a live call to your cloud account.

01

Edge SDKs

Browser Elements, server SDKs, pipeline connectors.
02

Tokenization service

Stateless API — value in, token out.
03

Vault store

Encrypted mappings and sealed document blobs.
04

Key layer

Your KMS wraps every data key — GCP, Azure, AWS, or HSM.
05

Policy & identity

Your IdP's JWT evaluated on every reveal.
06

Audit pipeline

Every tokenize and reveal logged — cross-checked with KMS.

Iceberg can be fully compromised. Your data still can't be read.

Self-serve vault · BYOK from day one · SOC 2 aligned