Security
What follows describes how the software actually works today. It is not a certification, and Rivet holds none — a pre-launch product claiming an audit it has not had would be exactly the kind of overstatement this product exists to catch.
Tenant separation
Every record belongs to one organization, and every query is filtered by an organization identifier taken from the signed-in session. No route, form or link in the application accepts an organization as a parameter, so a request cannot ask for another tenant’s data — there is nothing to ask through. This is verified by automated tests that attempt cross-tenant reads and assert they return nothing.
Separation is enforced in the application today, not by the database. Database-level row-level security is a planned addition, and this page will say when it lands.
Sessions
Session tokens are stored hashed, never in plain text, so a database copy yields hashes rather than usable sessions. Cookies are HTTP-only, same-site, and secure in production.
How findings are produced
Every amount Rivet reports is calculated deterministically from the records provided. No language model produces, adjusts or estimates a figure, and the product makes no external model calls. A finding can always be traced back to the specific contract line, work record and invoice line that produced it.
The public site
This marketing site loads no analytics, no third-party scripts and no external fonts, and sets no cookies. Opening the example product sets a single session cookie.