Lumenrate is secured at the architecture level — in the database, the protocol, and the audit chain — not by policy statements. Every claim on this page is enforced in code and traceable to a source file.
Your book never mingles with anyone else's. Isolation is enforced by the database itself, keyed to your verified identity — not by an application filter a future change could miss.
Every tenant table has PostgreSQL RLS enabled and forced, so isolation applies even to the table owner. The runtime database role is provisioned non-bypassing, and a Postgres integration test proves cross-tenant queries return zero rows.
The tenant is read from your signature-verified OIDC token and checked against an allow-list. Any tenant supplied in a request body must equal it, or the request is rejected — a caller cannot target another tenant's data.
Objects are written under SSE-KMS with a specific key; every read re-fetches and fails closed unless the object reports that exact key. Encryption is verified, not merely requested.
Production refuses any database URL without TLS verify-full, and the identity layer refuses any non-HTTPS issuer. No plaintext data paths.
Objects are written once via conditional PUT; every read recomputes SHA-256 and enforces byte length. The store's health check requires bucket versioning and all public-access-block flags.
Isolation is logical — shared schema and bucket, separated by forced RLS and per-tenant key prefixes, region-pinned. A dedicated per-tenant data plane is available as a deployment option on the roadmap.
Only your identity provider's signed tokens get in, and every action is checked against a named permission.
Production forces OIDC and verifies every token against your IdP's remote key set — pinned issuer and audience, asymmetric-only algorithms (no symmetric, no none), required claims, and a one-hour maximum token age.
Tokens must satisfy a configured MFA / assurance-level policy or are rejected. Production will not boot without an MFA policy configured.
Every operation checks the caller against an explicit named permission derived from a frozen role table (33 permissions across 15 roles). Unknown roles or malformed identifiers are rejected at the door.
Propose, challenge, and approve are separate permissions. The same person cannot request and approve a connector or a data-pack promotion; extending actor-level four-eyes to every approval type is on the roadmap.
The decision record is tamper-evident by cryptography, not by trust. This is the same ledger that answers "why this price?" for your regulator.
Each event is SHA-256-hashed over a canonical encoding that includes the previous event's hash, chaining from a fixed genesis. Altering any past record breaks the chain visibly.
Every read and every append replays the whole chain and fails closed with an integrity error on any mismatch of hash, link, sequence, tenant, or governance transition.
In the production Postgres backend, database triggers reject UPDATE, DELETE, and TRUNCATE on the ledger independently of the application, and force the chain to advance exactly one step per insert.
A replayed write with identical content returns the original record; the same key over different content is rejected — no silent overwrite, no duplicate.
Recovery is signed and rehearsed, not assumed.
A restore manifest cryptographically binds ledger head hashes, metadata digests, and object inventories into one signed digest, verified against a pinned trust policy before a restore is trusted.
A coordinated database-plus-object recovery drill and a multi-replica resilience drill run on every build against a real PostgreSQL service. The protocols are proven continuously; production infrastructure is provisioned per deployment.
Automation is cumulative: each stage requires every preceding stage's evidence to hold, and a breach at any point reverts the platform to a safer stage. Every deployment begins at Stage 1; the reference tenant operates there today. What follows is what each gate actually requires.
What it requires: a governed competitive data source with declared freshness and quality contracts, and coverage normalisation so comparisons are like-for-like.
Clears when: a market pack validates against its schema and its freshness contract holds.
What it requires: deterministic decision artefacts, an evidence status on every recommendation, named-human authority on every decision, and an immutable record of the cycle.
Clears when: the tenant has a persistent, immutable recommendation-lifecycle record and the advisory artefacts assemble from governed data.
What it requires: all-in economics joined at the decision grain — premium, selected ultimate claims, acquisition cost and conversion — plus a reviewed actuarial method behind any indication.
Clears when: a governed data contract, all-in profitability, actuarial method, ultimate claims, and demand and distribution evidence are each in place.
What it requires: a jurisdiction position for every market in scope — filed rating plans, permitted rating factors, prohibited objectives — and the ability to run a controlled experiment rather than an uncontrolled change.
Clears when: regulatory authority is evidenced per jurisdiction and a controlled-experiment capability is operating.
What it requires: model monitoring with defined drift and performance thresholds, a promotion process with independent review, and an assurance case whose claims are supported rather than merely asserted.
Clears when: optimiser and model controls are in force and the approval and assurance chain is complete.
What it requires: an execution envelope with hard caps, dual control, a kill switch, and an immutable audit of every automated action — with jurisdiction and assurance both permitting automation.
Clears when: every preceding gate holds and the execution envelope, dual control and kill switch are all in force. Human approval remains required regardless of stage.
Stage status is computed from the platform's own governance artefacts, not set by configuration. The live source of truth for a deployment is its pricing-automation readiness endpoint.
The reason a model here cannot mis-price a customer is not a setting — it is that no execution path exists. The boundary is enforced four independent ways:
executable:false and the execution boundary as fixed schema constants, validated on every result.advisory_only and "no production write path" on its own health endpoints.A small, conservative dependency list is a security property.
Eight well-known first-party dependencies across the whole platform, pure Node with no build step. Exact version pinning and automated vulnerability scanning are on the near-term roadmap.
External data connectors ship disabled and do no network or auth work until a provider-managed adapter is supplied; credentials are referenced by opaque ID, never inlined.
A CI step blocks committed credentials and any customer data before code lands. Environment files and customer data are excluded from version control and container images.
Every event payload is checked against an exact key allowlist, so a secret or stray field cannot be smuggled into the immutable audit record.
Precisely worded, because the distinction matters: these are self-assessments and a build-time standard, not third-party certifications.
A complete CAIQ v4 self-assessment — 17 domains, every "yes" citing its enforcement point in code — is drafted and submission-ready for the public CSA STAR Registry. Listing pending submission.
Our build-time application-security standard. A published traceability matrix maps ASVS chapters to enforcement points in the codebase; CI fails the build if a verified row's cited code stops existing.
On the published roadmap, triggered by the first enterprise engagement that requires them — and priced into that engagement rather than promised in advance.
A living standards register and jurisdiction matrix map platform capabilities to the NAIC AI Model Bulletin, Colorado SB26-189, APRA CPS 230/510, and NY DFS guidance.
Lumenrate is a pre-deployment product. The controls above are built and continuously tested in CI. The following are roadmap, in order, and we would rather you read this list than discover it:
Every item on that list hardens a system that already fails closed — not one that is currently open. That is the distinction between security by architecture and security by assurance.
We will answer it against the code, control by control, and take your security and compliance teams through the architecture in detail.
Start a security review