Tenant Isolation
SaaS Multi-Tenant Isolation
In SaaS mode, Veriproof is a multi-tenant platform. All customer data is co-located in shared infrastructure but isolated via:
Database Row-Level Security (RLS)
Every table in veriproof_transaction.*, veriproof_customer.*, and veriproof_worker.* schemas has a customer_id column and a PostgreSQL RLS policy that restricts each connection to only see rows where customer_id matches the application user’s tenant UUID:
CREATE POLICY tenant_isolation ON sessions
USING (customer_id = current_setting('app.current_tenant')::uuid);The [CustomerIsolated] attribute on Azure Function endpoints automatically sets app.current_tenant from the authenticated JWT before executing any query. Cross-tenant data access is impossible at the database layer, not just the application layer.
Encryption Envelope Isolation
All session payloads are encrypted with per-data-subject keys derived from a per-customer pepper. Even if the RLS policy were somehow bypassed, an attacker would need the target tenant’s pepper key to decrypt the payload.
Application & API Key Scoping
API keys are scoped to a specific application within a specific tenant. A key for Tenant A cannot be used to ingest data into Tenant B’s namespace.
Enterprise Single-Tenant Isolation
In enterprise self-hosted deployments, the concept of multi-tenant isolation is replaced by single-tenant ownership: you own the entire PostgreSQL instance, Key Vault, and Function Apps. There are no other tenants to isolate from.
The security model shifts to:
| Threat | Control |
|---|---|
| Unauthorized internal access | Azure role-based access control on the PostgreSQL server and Key Vault |
| Compromised application credentials | Managed Identity (no passwords); RLS even within single-tenant DB |
| Compromised DBA access to DB | Encrypted payloads — raw DB access does not expose session content |
| Compromised Key Vault access | Audit logs; Defender for Key Vault; purge protection |
Cross-Application Isolation Within a Tenant
Within a single enterprise tenant, each application is isolated from others. An API key issued for Application A cannot read sessions from Application B. Application-level RLS and application-scoped API keys enforce this at both the database and API layers.
A CustomerAdmin can view and manage all applications. Use RBAC to restrict non-admin users to the applications relevant to their role.
Staff Access Isolation
Veriproof platform operators (staff) have no access to customer data in enterprise Hybrid/LocalFirst/Disconnected deployments — they do not hold the pepper key and your database is not in their infrastructure. Any staff access to your self-hosted portal would require credentials that you control.
In SaaS mode, staff access to customer data is strictly audited, requires elevated approval, and is logged in the 7-year staff audit log. Customers may request a copy of staff access events for their tenant.