Security
Security
Section titled “Security”Atlas holds a tenant’s business record, so isolation and authenticity are first-class.
Tenant isolation (RLS)
Section titled “Tenant isolation (RLS)”Every tenant-scoped query runs inside withTenant(db, tenantId, fn), which sets
a Postgres GUC the row-level security policies key on. The application database
role is NOBYPASSRLS, so a missing wrapper fails closed rather than leaking
across tenants. Entities, cross-references, mappings, and the ingest log are all
tenant-isolated.
Authentication
Section titled “Authentication”- Read / write-back surface — a short-lived per-tenant JWT on the
Authorizationheader, minted by platform and verified by Atlas via JWKS. The JWT-scoped tenant is the Atlas tenant. - Ingest surface — per-endpoint HMAC. Each ingest endpoint has its own
secret; the caller signs the raw body (
X-Synergy-Signature: sha256=<hex>). This lets external systems deliver without holding a tenant JWT while still proving authenticity. See Ingest.
Idempotency
Section titled “Idempotency”Ingest deliveries are idempotent: a replayed delivery is recorded once and
returns duplicate: true, so a retrying source never double-applies an event.
Audit & provenance
Section titled “Audit & provenance”Reconciliation records per-field provenance (which source set each value, and when) and surfaces open drift when sources disagree — disagreements are made visible, never silently overwritten. Changes are written to a tamper-evident audit trail (an HMAC-chained log, the stack convention) so no record can be silently dropped or rewritten.
Reporting a vulnerability
Section titled “Reporting a vulnerability”Email [email protected] with details and reproduction steps. Please do not open public issues for security reports.