Security
Where your data lives, who can reach it, and what is not in place yet
What is enforced, where, and by whom, plus the things a larger vendor would have that we do not yet.
- Data residency
- United States
- Sign-in
- Email links. No passwords.
- SOC 2
- Planned. Not started.
Access
Who can see a placement
- Access is granted per placement, never per firm. Every table that holds part of a placement checks, in the database, that the reader holds a seat in it.
- A broker never sees another broker’s placements. Each market gets its own room, so no carrier sees another carrier’s terms.
- The one wider read is the names of colleagues at your own firm, on the settings page.
- The assistants use a service credential, so every query they make must name a placement. A static check fails the build if one does not. See Governance.
The record
An audit trail nobody can edit
- Every state change writes one row: who, person or assistant, which firm, and a hash chained to the row before. Update and delete are refused for every role, including ours.
- The hash chain is an internal integrity check. It is not notarized and is not a guarantee against someone who controls the database. The export says so too.
- Either firm can export a placement at any time as one file, with a SHA-256 for every document. The export itself is recorded.
Subprocessors
Who else sees it
Six providers, all hosted in the United States.
| Provider | Used for | What it sees |
|---|---|---|
| Supabase (AWS us-east-1)Database, sign-in, file storage | Database, sign-in, file storage | The full record: slip, terms, quotes, conditions, documents, audit trail and email addresses. |
| VercelApplication hosting | Application hosting | Requests in flight. Logs carry paths and timings, not slip values. |
| LiveblocksLive slip editing and presence | Live slip editing and presence | Slip fields while they are edited, and the names of people in the room. |
| AnthropicReading submissions, the two assistants | Reading submissions, the two assistants | Submission text and slip terms, on a paid API that does not train on them. |
| ResendSign-in links and notifications | Sign-in links and notifications | Email addresses and placement names. Notifications never include terms. |
| TallyThe pilot request form on this website | The pilot request form on this website | What you type into that form. Never loaded inside the product. |
Google’s model API exists in the code as a fallback for a deployment with no Anthropic key. Production has one. No analytics or session-recording script runs in the product.
Controls
Sign-in, sessions and encryption
No passwords
People sign in with a one-time link sent to their work email. Sessions can be ended on every device from settings.
Single-use invitations
A market joins through a link that expires in seven days and is spent when claimed. The token never appears in the audit trail.
Encrypted in transit and at rest
Every connection uses TLS. Documents are served through signed links that expire after 60 seconds.
Backups: managed, not yet rehearsed
Supabase backs up the database. We have not yet restored from a backup, and will before a live pilot.
Not in place yet
What a larger vendor would have, and we do not
Each of these is a question procurement will ask.
- SOC 2 Type II
- Planned before general availability. No audit has started.
- SSO, SAML and SCIM
- Not built. Our auth provider supports SAML, so nothing in the design blocks it.
- Penetration test
- None yet. Our own tests break each governance control on every build.
- EU data residency
- None. Everything is hosted in the United States.
- Deletion on request
- Not available. The audit trail and placements cannot be deleted, by design.
- Bug bounty
- None. Reports go to the address below and are answered by a founder.
Responsible disclosure
Report a vulnerability
Write to mhk127@rutgers.edu with what you found and how to reproduce it. A founder replies within two business days. Test only against your own placements; we can set up a demo for you.