Security
CrewCert is operated by SoloFive LLC, a California limited liability company. It holds other companies' insurance documents — that is a liability product, and it is built accordingly. Here is what actually protects your data.
Tenant isolation at the database, not in application code
Every table holding your vendors, certificates, documents, templates, reviews and audit history carries an organization id and has PostgreSQL row-level security enabled and forced. The connection is scoped to your organization before any query runs, so a query that forgets its filter returns nothing rather than somebody else's rows — it fails closed. A cross-organization leakage check runs in our test suite.
Two tables are deliberately outside that policy, and we would rather say so than round the claim up. Support and contact messages can be sent by people who are not signed in, so those rows may have no organization to scope to. Vendor upload links must be resolvable from the token alone before any organization is known — that lookup is by unguessable token, and every action it permits is then re-scoped to the one vendor it names. Neither table holds insurance documents.
The AI never decides anything
Extraction is strictly one-way: the model transcribes a certificate to structured data and has no tools, no network, and no authority. Ordinary code then validates that data and scores it against your requirements. Nothing downstream reads free text from a document, so instructions hidden inside an uploaded PDF — a real attack against document-processing systems — cannot influence a compliance decision. We have a test that asserts exactly this.
Your documents are not used to train AI models.
Uploads are treated as hostile
File type is determined by inspecting the bytes, not by trusting a filename or a declared content type. Storage keys are generated server-side and cannot be steered by a filename. Documents live in private storage and are served only through short-lived signed links — there is no public URL for a certificate.
Authentication and access
Sign-in is by emailed magic link (or Google SSO where enabled) — there are no passwords for us to lose. Link tokens are stored only as hashes and are single-use. Sessions are HMAC-signed with a sliding window and an absolute expiry. Access is deny-by-default at a single middleware choke point, and every write is checked against your verified role on the server; the browser is never trusted to say what role it has.
An audit log you cannot quietly edit
Consequential actions — a review approval, a compliance decision, a document deletion, a waiver granted — are written to an append-only audit log. Update and delete are revoked on that table at the database level, so the record survives even the deletion of the thing it describes.
Payments
Card details are handled entirely by Stripe on Stripe-hosted pages. We never see, store, or transmit a card number. Subscription state is written only by Stripe's signature-verified webhook — never by anything a browser sends us.
Infrastructure
Traffic is TLS-only with HSTS, a content security policy, and strict referrer and content-type headers. Data is encrypted at rest by our database and object-storage providers. Rate limits apply to sign-in, the public vendor portal, and inbound email, and a per-organization daily processing ceiling caps what an abusive sender can cost.
What we are still working on
We would rather tell you than let you assume. Currently in progress: replacing the remaining inline-script allowances in our content security policy with per-request nonces, optional two-factor authentication, formal third-party penetration testing, and a published subprocessor list and DPA. If you need any of these before you can adopt CrewCert, write to us and we will tell you honestly where it stands.
Reporting a vulnerability
Email [email protected]. Please include enough detail to reproduce the issue, and give us a reasonable chance to fix it before publishing. We will acknowledge your report, keep you updated, and credit you if you want the credit. We will not pursue legal action against good-faith research that respects customer data and avoids service degradation. Machine-readable contact details are at /.well-known/security.txt.
Privacy
What we collect and why is on the privacy page; data questions go to [email protected].