IT & Security
Tenant isolation that doesn't depend on the application getting it right.
A multi-tenant compliance ledger is a natural target for a cross-tenant data leak. Isolation here is enforced by Postgres Row-Level Security, not by an application-layer WHERE clause that could have a bug.
Database-enforced isolation
Even the table owner is policy-bound.
Row-Level Security is enabled with FORCE, under a two-role model, so a policy gap in application code can’t become a cross-tenant read. The isolation boundary lives in the database, where it can’t be bypassed by a missing filter three layers up the stack.
ALTER TABLE ae_compliance.invoice_ledger FORCE ROW LEVEL SECURITY; CREATE POLICY tenant_isolation_ledger ON ae_compliance.invoice_ledger USING (tenant_id = current_setting('app.current_tenant_id')::uuid);The rest of the security surface
Every layer designed to fail closed.
Envelope-encrypted ASP credentials
Tenant-supplied ASP credentials (BYOK) are AES-256-GCM envelope-encrypted. The key-encryption key is held outside the database, injected at the platform layer, never stored alongside the data it protects.
TLS-only ingress
TLS 1.2/1.3-only; plain HTTP is dropped at the edge, not redirected.
Signed, replay-protected webhooks
HMAC-SHA256-signed webhooks in both directions, with timestamp freshness windows and nonce replay protection on inbound ASP callbacks.
Tamper-evident by design
The audit trail is append-only and trigger-enforced at the database: there's no application code path that can rewrite history.
Data residency
Deployed in the UAE.
Production runs in-country on Microsoft Azure's UAE North region. Residency was built into the deployment target from the start, not retrofitted after a customer asks where the data lives.