The full account
Eóin Forker, Immiscible
Where your data lives
This is the EU (Frankfurt, Germany) region, on Fly.io. A workspace is created in the region its owner picks at sign-up and its records stay there: each region is a separate deployment with its own database, encrypted backups under its own storage prefix (a restore refuses a backup from another region), and its own signing key. Only public signing keys are shared, so a receipt from any region verifies against either region's published key set. Your workspace’s records are kept in one database on a volume attached to that region’s machine. If you would rather nothing left your own network, the Enterprise plan can run the gateway in your own cloud account, which adds no sub-processor at all.
Every hour, a copy of the database is checked, encrypted on the machine with AES-256-GCM, and sent to object storage away from it, so the most we could lose is about an hour of changes. Each copy is kept at least 35 days. The service never deletes a backup itself; old copies are removed only by the operator, separately. A restore checks every hash and recomputes each workspace’s evidence chain before it touches anything live, and that full restore runs in our automated tests on every build.
Running now: build 2530cb491bcc, made 2026-10-10 at 10:51 UTC, which /version also reports. Off-machine backups: every hour; last good backup 2026-10-10 at 18:52 UTC.
We keep as little as we can. Prompts and model answers are stored as SHA-256 fingerprints, not text, unless you choose to keep the text for a particular kind of task. You bring your own model provider keys: the gateway forwards each request under your contract with the provider, and never buys or resells inference on your behalf.
You can take everything with you: an owner can download the whole workspace as one file, evidence and signatures included. When an owner deletes a workspace, its keys stop working at once; 30 days later every record of it is erased, the evidence ledger included, and the owners get a signed certificate of erasure. Until then an owner can change their mind.
Encryption
Everything between you and the service travels over HTTPS, and every response tells browsers to insist on it for two years.
Inside the database, the things that would hurt most if they leaked are sealed with AES-256-GCM: your model provider keys, single sign-on client secrets, authenticator secrets, the tokens for each tool or service you connect, vault fields, and the private key we sign receipts with. Each sealed value is bound to what it belongs to, a workspace, a person or a purpose, so a value copied from one place to another will not open. The key that seals them lives only in the running service’s environment and is never written to the database; we can rotate it and re-seal everything with one command.
To be plain about the limit: the application does not encrypt the database file as a whole. The rest of what is in it, such as rules, approvals and the evidence ledger, is protected by access to the machine, not by our own encryption.
Signing and evidence
Every decision the engine makes, and every approval, rule change and model call, is written to a ledger before the response goes back. Each entry carries the SHA-256 hash of the one before it, so changing or deleting any entry breaks the chain from that point on, and a check shows where.
Receipts and ledger checkpoints are signed with Ed25519. The public key is published at /.well-known/immiscible-keys.json, so you, or your auditor, can verify a receipt offline without asking us anything. When we rotate the signing key, the retired key stays published, so what it signed still verifies, and the change is written to every workspace’s ledger. Signed evidence records are never purged by retention; export access windows depend on plan.
The receipt above is in the same format, signed with a demonstration key whose public half is in the page, so your browser can check it without us.
Access
These controls apply to every workspace, and an owner can tighten most of them.
| Control | How it works |
|---|---|
| Passwords | Hashed with scrypt and a salt for each password; at least ten characters. Sign-in attempts are limited to 10 a minute from one address, and counted per account wherever they come from. |
| Two-factor | Authenticator apps and passkeys, with single-use recovery codes. A workspace can require two-factor for every member. |
| Single sign-on | OpenID Connect with PKCE, for Okta, Microsoft Entra, Google Workspace and other OIDC providers, or SAML 2.0 with signed assertions, started from our side. A workspace can require it for the email domains it has proven by DNS. |
| Provisioning | SCIM 2.0 for users and groups, with a token for each workspace. Deactivating someone in your directory removes their access and revokes their keys within the same request. |
| Roles | Owner, admin, analyst, auditor, member, approver and security admin. Every workspace route checks the caller’s role before it reads or changes anything. |
| Two people | In a workspace of more than one person, above the line it sets, the person who approves a payment must be someone other than the person the agent acts for and the person who wrote its mandate. Lifting an incident hold, overriding an agent’s standing and widening what money can move each need a second person too. |
| Step-up | Approving a payment or other amount above the workspace’s line, releasing personal data, changing single sign-on, changing the security policy, changing retention, making someone an owner, admin or security admin, minting a provisioning or service token, exporting or deleting the workspace and removing a second factor each need proof of who is at the keyboard from the last 5 minutes: a passkey or authenticator code, or a password or emailed code for those without one. |
| Sessions | A session ends after 24 hours idle and 14 days after sign-in, whichever comes first; a workspace can set shorter limits. Cookies are HttpOnly and SameSite, and stored on our side only as a digest. |
An audit log records sign-ins, role changes, rules, approvals, settings, keys and integrations, each with who did it, from which address and in which browser. It can be filtered and exported, and its entries are chained into the evidence ledger as well.
Sub-processors
Three companies process data for the hosted service. The model providers you connect are not among them: they work for you, under your own contract.
| Company | What for | Where |
|---|---|---|
| Fly.io, Inc. | Application hosting (hosted plans only) | EU (Frankfurt) |
| Stripe Payments Europe Ltd | Payments and invoicing | EU / US |
| Resend, Inc. | Transactional email (account email only; never prompt content) | US |
The product itself runs on Node.js with no third-party runtime packages, which leaves less code that someone else could compromise.
What we have not done yet
We hold no security certification today, and no independent firm has tested the service yet. Both are planned, and we will say so here, with the report available on request, when they are done. Until then, we will not suggest otherwise. The full list, with where each item stands, is at the top of this page.
If a breach ever affected your personal data, we would tell you without undue delay and within 48 hours, as our Data Processing Agreement sets out (on request until it is published).
Report a security issue
If you find a security problem, please use the security form. Tell us what you found and how to reproduce it. We acknowledge every report within two working days and keep you informed until it is fixed. Please do not test against other customers’ workspaces. Our security.txt carries the same details for tools that look for it.
Documents
The security review pack answers the usual questionnaire in advance: architecture, access control, incident response, continuity and sub-processors, with trust.json generated as you download it. It is free and needs no form.
For a security review, trust.json lists the controls this deployment enforces, generated from its own configuration, and is available now. The sub-processor list is published. Our Data Processing Agreement, privacy notice and terms are available on request, as is help with your questionnaire: ask through the contact form. How evidence and receipts work is documented in full in the docs.
