Trust Model & Zero-Knowledge Proofs

Volidator operates under a Zero-Knowledge (ZK) Security Architecture. Traditional SaaS analytics and logging tools require you to send plaintext telemetry, which introduces compliance liabilities and security risks. Volidator solves this by encrypting all sensitive audit logs locally — on your servers — before ingestion.

This document defines our trust model, outlining the security boundaries and what guarantees protect your data.

---

The Core Trust Boundary

Our security guarantees are enforced by cryptography, not policy.

Data Type	Processed & Stored By Volidator	Visibility to Volidator	Protection Mechanism
Audit Payload (Actor, Action, Target, Metadata)	Ciphertext only	Zero Visibility	Local AES-256-GCM
Search Indexes (Actor, Tenant, Action)	Hexadecimal HMAC Blind Indexes	Zero Visibility	HMAC-SHA256 with project keys
Network IP Address	Anonymized Index or Skip (Standard/Strict)	Zero Visibility	Hashed or skipped at client-side
Large Log Contexts (>30KB)	Encrypted bytes in R2 bucket	Zero Visibility	AES-256-GCM (Claim Check pattern)
User Identities (JIT Hydration)	Database primary key (e.g. [REF:usr_123])	Zero Visibility	Stored as non-PII token; resolved in browser
Project & Account Metadata	Admin email, project names, billing details	Full Visibility	Stored in admin database (standard SaaS data)

---

1. Verifiability (Open Source SDK)

Because all cryptographic actions happen before the payload leaves your host server, you do not have to trust our SaaS backend to keep your data secure. You can verify exactly what leaves your servers by inspecting the open-source @volidator/node code:

1. Local Encryption: Payloads are stringified and encrypted via AES-256-GCM using WebCrypto APIs. The Data Encryption Key (DEK) is never sent in the HTTP payload body or headers.
2. Blind Indexing: Search parameters (like actor or action) are converted into secure blind indexes using HMAC-SHA-256. The server receives only random 64-character hex strings: $$H = \text{HMAC-SHA256}(\text{value}, \text{hashed_project_key})$$
3. PII Scrubbing: If redactKeys or referenceKeys are configured, values are scrubbed or tokenized before entering the encryption function.

---

2. Breach Impact & Blast Radius

If Volidator’s databases, infrastructure, or Cloudflare accounts were to experience a complete security compromise, your data remains secure:

• Attacker View: An attacker gaining full read access to the D1 SQLite databases or R2 storage buckets will see only randomized base64-encoded ciphertexts and hexadecimal HMAC hashes.
• Decryption Feasibility: Without your local VOLIDATOR_ENCRYPTION_KEY (which lives strictly in your environment variables and never enters our network), decrypting historic log payloads is mathematically infeasible.
• Search Parameter Leaks: Because blind indexes are computed using a secret key derived from your project encryption key, an attacker cannot reverse the blind indexes to read your actor names or action patterns.

---

3. Web Widget Key Isolation

When you embed the customer-facing audit log widget inside your React frontend, the widget must decrypt historic logs in the user’s browser. To do this securely without exposing keys:

1. Hash Fragment Isolation: The signed JIT token URL generated by the SDK appends the decryption keyring as a URL hash fragment (e.g., https://dash.volidator.com/embed/token#v1:key).
2. No Network Transmission: According to the RFC 3986 specification, browsers never send URL hash fragments to the host server during HTTP requests. The key fragment remains strictly client-side.
3. Iframe Handshake Sandboxing: The iframe decrypts the logs completely in-browser. Any postMessage identity resolution (JIT Hydration) strictly verifies origin domains (hostOrigin) on both sides to prevent cross-frame scripting attacks.