Security
Where the record lives, who can reach it, and what is not in place yet.
This is the page a security reviewer asks for. It says what is enforced, where, and by whom — and it lists the things a larger vendor would have that we do not have yet, because discovering those in month three of a pilot is worse than reading them here.
- Data residency
- United States
- Sign-in
- One-time links. No passwords.
- SOC 2
- Planned. Not begun.
Who can see a placement
Access is granted per placement room, never per organization. Every table that holds part of a placement carries a database policy checking that the person asking holds a seat in that specific room. A room you were not invited to returns nothing rather than an error, so a URL cannot be used to confirm a placement exists.
A broker never sees another broker’s placements. A market never sees a room it was not invited to, and a risk taken to several markets is a separate room per market, so no carrier sees another carrier’s terms. These rules are in Postgres, beneath the application: a bug in our code cannot widen them, because the query would still return nothing.
The one read that reaches past a room is the names of the people at your own firm, on the settings page, so a firm can see who is in it. It reaches sideways and no further — never a counterparty’s people, never a room.
The two assistants read and write with a service credential that bypasses those policies, because an assistant has no session to be scoped by. What holds there is that every query they make names a room, and a static check in our test suite fails the build if one does not. Nothing either assistant produces is binding; what stops them committing anything is described on the governance page.
The record
Every state change writes one row to an append-only trail — who did it, whether they were a person or an assistant, which firm they acted for, and a hash chained to the row before. Update and delete are refused by trigger for every role, including the service credential and including us.
The chain is an internal integrity check. It is not a cryptographic guarantee against a party with control of the database, it is not notarized, and it is not anchored anywhere outside Slipstream. The exported placement file says exactly that on its first page, because an exported file is where somebody would over-read it.
Either firm placing a risk can export the whole placement at any time as one self-contained file, without asking us: every term, quote, condition and document, with a SHA-256 computed from each stored object at that moment, and the full trail. The export is itself recorded, so who took a copy and when is answerable.
Who else sees it
Six providers can see some part of a placement. All are US-hosted; there is no EU-resident deployment, which matters if a counterparty’s data cannot leave the EEA. Say so early and we will tell you plainly that we are not ready for that.
| Provider | For | What it sees |
|---|---|---|
| Supabase (on AWS, us-east-1)Postgres, authentication, file storage | Postgres, authentication, file storage | Everything in the record: the slip, every term, quote, condition, document and trail row, and each person’s email address. |
| VercelApplication hosting and request logs | Application hosting and request logs | Requests in flight. Nothing about a placement is stored there; logs carry paths and timings, not slip values. |
| LiveblocksThe live slip’s shared state and who is present | The live slip’s shared state and who is present | The twenty slip fields as they are being edited, and the names of the people in the room. |
| AnthropicReading a submission, and the two assistants | Reading a submission, and the two assistants | The submission’s text and the slip’s terms, on a paid API whose terms do not use prompts or outputs to train models. Which model read a given submission is on that submission’s own audit row. |
| ResendSign-in links and notification email | Sign-in links and notification email | Email addresses and the placement’s name. A notification says what kind of thing happened — a term countered, a quote given — and never what was said. |
| TallyThe pilot request form on this website only | The pilot request form on this website only | What you type into that form. It is never loaded inside the product. |
A second model provider, Google, exists in the code as a fallback for a deployment with no Anthropic key. Production has one. Because the provider and model that read each submission are written to that submission’s audit row, the answer to “which model saw this” is in the record rather than on this page. No analytics or session-recording script runs anywhere in the product.
Sign-in, sessions and encryption
No passwords, anywhere
People sign in with a one-time link sent to their work email. There is no password to be phished, reused or leaked, and nothing for us to store. Sessions are server-side cookies, refreshed on every navigation and ended from the settings page — on this device or on all of them.
Invitations are credentials, and treated as such
A market joins a placement through a single-use link that expires in seven days. The token is minted by the database, never written to the trail that both firms can read, and spent the moment it is claimed. Binding authority travels on it only within the inviting firm.
Encrypted in transit and at rest
Every connection is TLS, including the ones between our application and each provider. Data at rest is encrypted by the providers that hold it. Filed documents are served through a short-lived signed URL minted per click, never a link that outlives the page.
Backups: managed, not yet rehearsed
The database is backed up by Supabase on a schedule we did not set and have not yet restored from. We will confirm the retention window and rehearse a restore before a live pilot, and we would rather say that than imply a recovery posture we have not tested.
Not in place yet
What a larger vendor would have, and we do not.
Each of these is a question procurement will ask. Here is the answer before they do.
SOC 2 Type II
Planned before general availability. No audit has begun and we are not going to describe a control environment we have not been assessed against.
SSO, SAML and SCIM
Not built. Our authentication provider supports SAML on a paid plan, so nothing in the design blocks it; it is scheduled for the first enterprise pilot rather than ahead of one.
Third-party penetration test
None yet. The governance mechanisms are tested on every build against a real Postgres, including tests that deliberately break each one; that is our own testing, not an outside firm’s.
EU data residency
None. Everything is hosted in the United States.
Deletion on request
Not available, by design. The trail cannot be edited or removed, and neither can a room. A firm whose policy requires deletion on demand cannot use Slipstream as it stands; the honest form would be redaction, and it is a design change rather than a setting.
Bug bounty
None. Vulnerability reports go to the address below and are answered by a founder.
Reporting a vulnerability
Write to mhk127@rutgers.edu with what you found and how to reproduce it. A founder reads that inbox and answers within two business days. Please do not test against placements that are not your own; a demo room can be arranged for anyone who asks.