Security and privacy
A twin holds your accounts, your customer list, your contracts and your plans. This page says exactly how they are kept, who can reach them, what leaves and what never does, and then says plainly what has not been certified yet.
What happens to your filesThe privacy policy
No SOC 2. No penetration test yet. The section near the bottom of this page explains both.
The eight promises
Each of these is a specific behaviour of the software, not a posture.
Files go into a store that belongs to your account, one folder per twin, with a random prefix on every name and a rule that refuses any request to fetch them over the web. They are never published, previewed or resized.
Every file, fact, number, run and answer carries the twin it belongs to, and every request checks that you own that twin or hold a seat on it before it reads or writes anything. There is no query anywhere that crosses accounts.
Owner, reviewer, analyst and viewer. A viewer cannot change anything anywhere. Approving needs a reviewer. Keys, hooks and seats are the owner's alone.
Uploads, rebuilds, edits, approvals, keys minted and seats granted are written to the twin's record with who did them and when, and nobody can edit that record.
The simulation and the network are arithmetic on your own twin. Nothing about your company is pooled, compared with anybody else or used to improve a model somebody else uses.
The simulation, the graph and the network never call out. A language model only sees the text the rules could not read, and only if one is configured. A connection you make to Stripe, QuickBooks or another system reads your figures from it and sends nothing of yours back.
Every page, every upload and every request travels over an encrypted connection. Each page tells the browser exactly which scripts it may run, so a script slipped in by anybody else is refused. Hook calls are signed so your systems can tell they came from us.
Deleting a file removes it from disk with its chunks and its facts in the same step. Deleting a twin removes everything under it. It is not a flag and not a soft delete.
Who can see it
You, and whoever you give a seat to, at the role you give them. Nobody else on the service can find your twin, list it or open it, because no route answers without checking ownership first.
On the hosted service the operator can reach the database the way the operator of any hosted software can. Nobody looks at a customer's files as a matter of course, and support asks you for what it needs rather than going to look. On a private deployment on Enterprise, the only people who can reach it are your own administrators.
Access control
| Situation | What you get back | Where the check lives |
|---|---|---|
| Not signed in | 401, sign in first | One permission check, on every route but the public boot call |
| Signed in with no plan | 402, with the message about picking a plan | The same check, via the plan resolver |
| Signed in, asking for somebody else's twin | 403, not yours | Resolved per request before any read or write |
| A viewer trying to change anything | 403, read only | The same resolver, on every request that writes |
| An analyst approving a decision or a proposal | 403, needs a reviewer | The reviewer check on those routes |
| Idle for longer than the site allows | 401, signed out | The same check, against the last request the session made |
| Two step sign in required and not set up | 403, set it up first | The same check; the application opens on the set up steps |
| A company that requires its own sign in, and a password tried instead | Refused, and sent to the company sign in | The sign in check, for every address on a proved domain |
| Switched off in the company identity provider | The seat is suspended and every session ends | Provisioning, the moment the provider says so |
| Twin does not exist | 404 | Resolved per request |
| Over the twin or file limit for your plan | 403, naming the limit | Checked on create and on upload |
| Over the monthly run or sweep allowance | Refused, with the allowance named | Metered per account per calendar month |
Anybody with administrator access to the server a deployment runs on can reach everything on it. On the hosted service that is the operator; on a private deployment it is your own administrators. Who holds that access is the decision that matters most.
Keys and secrets
The keys a connection holds, the tokens QuickBooks and Xero hand back, a company's sign in secret and every two step secret are sealed before they are stored, with keys kept in the server configuration rather than the database. A copy of the database alone does not give them up. Feed keys and provisioning tokens are kept only as a hash and shown once.
A language model key is the exception. A key for the whole service is kept in the application settings, and a member key, where bring your own key is switched on, is kept against that account. Both are stored as they are, without that extra layer, and saying otherwise would be inventing a control that is not there.
What follows from that is practical. Give every key the smallest scope the provider offers: a restricted Stripe key that can only read, a HubSpot private app with read access, a model key with a low spend cap. Rotate on the provider side when somebody leaves. With no model key at all the product still works, because the simulation never calls a model.
This is new software. The following certifications and assurances do not exist yet, and no page on this site implies they do.
There has been no audit of any kind. There is no Type I and no Type II report, no statement of applicability, no auditor. If your procurement process requires one of these, this product does not pass it today, and the correct answer to that question in a questionnaire is no.
No third party has been paid to attack this software. There is no report to share and no remediation log, because there has been no test. The code follows ordinary secure development practice for web applications, which is not the same thing as having been tested by somebody trying to break it.
If you find something, the contact page reaches a person directly and a security report gets answered the same day. That is a commitment about responsiveness, not a programme with a policy and a payout table.
Connections are encrypted in transit. Apart from the sealed secrets above, files sit on disk as ordinary files and rows sit in the database as ordinary rows; encryption at rest is a property of the hosting underneath, not something the application adds. On a private deployment, check that yours has it rather than assume.
There is no service level agreement and no published availability target. The terms say the same thing in the same words.
In order of what to do first: a penetration test by an outside firm with the report summarised on this page, including what was found. Then a written incident response process with a named responder and a notification window. Then, only when there are customers whose procurement requires it, the long and expensive work of a SOC 2 Type II. Each of those will appear on the changelog with a date when it is real, and not before.
On a private deployment
Force it at the server. A checkout on plain HTTP is refused by payment providers and a sign in on plain HTTP is a gift to anybody on the same network.
The application writes a rule refusing web requests for its private folder, and most web servers honour it. Try to fetch one of your own files over the web and confirm you cannot; if you can, add the rule to the server itself.
Administrator access to the server is access to every twin on it. That is the control that matters. Keep the list short and use two factor authentication on all of them.
A setting controls whether removing the application removes the data and the files. It ships switched off, so data survives an accidental removal. If you need removal to be complete, switch it on deliberately.
The facts and the ledger are in the database, the original files are on disk. A database only backup restores a twin whose sources cannot be read again.
Copying production to staging copies the settings. Clear the key in the copy, or use a separate key with a low cap for anything that is not production.
It walks the whole path: what is stored, what a chunk is, what the quote is for, what deletion removes, and exactly when anything leaves the application.