Architecture and tenancy

Understanding how the platform stores and separates data helps you reason about security and compliance questions before an auditor asks them.

Tenant isolation

Each customer is a tenant. Data is stored in PostgreSQL with row-level security enforced by the database, not only by the application: every row carries its tenant, and the database refuses to return rows from another tenant even if application code is wrong. A private deployment keeps everything in your own environment.

Secrets

Credentials you provide — cloud reader roles, write identities, API keys — are encrypted at rest with tenant-bound keys and are never shown again after you enter them. Read-only assessment and write-capable remediation use separate identities, so turning remediation off removes all write access.

The audit trail

Every meaningful action is written to a hash-chained audit trail. Each entry links to the one before it, so any later edit or deletion breaks the chain and is detectable.

MSP and multi-tenant access

Managed service providers manage customer tenants with act-as sessions. The session is re-validated on every request and recorded in each customer’s own audit log, so a provider’s staff can help a customer without quietly gaining standing access. Provider staff cannot manage a customer’s people or approve changes on their behalf.

Deployment

The same architecture runs hosted by us or privately on your own infrastructure. Nothing about tenant isolation or secret handling changes between the two.