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 recorded in internal staff access audit logs. Customers may request a copy of staff access events for their tenant.