We cannot read your sealed spaces.
Your security review asks who reads your company's pages. This page answers for each space: who it is shared with, what each AI reaches, and what our server can read. Our server reads an open space on purpose, so Claude on the web and the phone can read it; a sealed space is encrypted on your computers. For the person who runs your security review: every claim is one they can check.
# pricing/floors.md
enterprise floor: $40k / yr
never discount past 15%
approval: two founders
renewal risk: acme, q4
Each AI reads only the spaces its person gives it.
An AI you connect in the browser reaches nothing. You pick each space for it on Devices, to read or to write, never above your own role. Claude Code on a linked computer reads as you, the spaces that computer syncs.
A space is shared whole, with people, groups, and agents. Before each share, you see every page the newcomer would read, with the guard's findings.
An unshare takes effect at once, in the cockpit, every agent, and every computer. Pages already on a computer stay there. Each page read stays on the space's read trail for 30 days, with who read it and through what; each write names the person, computer, AI, or agent that made it.
The guard refuses a password before it is saved.
It reads the new text of every write, on our server for an open space and on the computer before each save. A secret is refused in any space, and the refusal shows no part of it.
In an open space it also refuses a card, IBAN, passport, or social security number, and a
server login outside projects/. Pay, an assessment, or health stays out of a
space others read until its owner allows it.
It matches patterns and checksums, with no model, so a secret of another shape passes.
Every primitive is a standard one, from Node 24 itself.
No third-party crypto. Content uses Node's ChaCha20-Poly1305, and one key per page keeps the nonce safe.
| Layer | Choice | Why this one |
|---|---|---|
| Content | ChaCha20-Poly1305 | A key per page and epoch keeps a random nonce far from collision |
| Key wrap | X25519 + ML-KEM-768 | A wrap breaks only if the curve and the lattice fall |
| Page keys | HKDF-SHA256 | Rotation is a new epoch, not a new secret |
| Membership | Ed25519 | Signs each chain entry that decides who holds the key |
| Recovery | Argon2id | Turns your passphrase into the key that opens a backup |
Your computers make the keys; our server holds none it can open.
Keys are made on the device. One leaves only wrapped for another device, or sealed in your backup.
X25519 + ML-KEM-768 to receive wraps, Ed25519 to sign chain entries.
256-bit, one per sealed space and epoch.
Derived for each page, never a secret of its own.
One per device. Useless without that device's private key.
Content and path, padded into size buckets.
A breached server cannot read a sealed page.
Assume the whole server, and an admin in bad faith. Five of these hold; the sixth we will not claim.
- Read a pageCiphertext, under a key it never held.blocked
- Read a pathPaths are encrypted too.blocked
- Merge two editsIt cannot merge what it cannot read. It answers 409.blocked
- Share a space with itselfA forged entry breaks the signed chain.blocked
- Decrypt it laterX25519 and ML-KEM-768 must both fall.blocked
- Learn nothing at allNames, ids, counts, size buckets, timing. Name a space
layoffs, and we see it.leaks
Space names, ids, counts, and timing leak. What a sealed space says does not.
Our server cannot add itself to a sealed space.
If the server decided who holds a key, it could share the space with itself. A chain that only your devices sign decides instead. A removal is forward-only: a new key locks out what comes next, and what was pulled stays pulled.
- entry 1
Genesis
The founding device signs it.
the root - entry 2
An admission
A manager's device signs it, after the newcomer's fingerprint is approved: their first computer on a manager's, a later one on their own. A new key, and every live page sent up again under it.
Ed25519 - on our server
Stored
We keep the chain. We cannot sign an entry.
no signing key - every sync
Verified
Each signature and link, from the first, before a key is taken.
by the sync client - a forgery
An invented entry
The chain breaks. The sync client refuses it.
refused
Each claim names where it holds and where it fails.
What holds, what is open in a named case, and what is false.
| Claim | Verdict |
|---|---|
| A breached, seized, or rogue-admin host gets ciphertext only | holds |
| The operator shares a sealed space with itself — open if you pin without comparing the founder's fingerprint, or after a server restore | blocked — open in two cases |
| A quantum adversary decrypts captured ciphertext later | blocked |
| Server-side processes read a sealed page | impossible by design |
| A newly admitted device reads earlier versions, removals, or old paths — it gets a new key and live pages only | blocked — open for a device admitted before sync client 0.0.23 |
| Any of the above covers an open space | false — we read it, by design |
| No system anywhere sees plaintext | false |
| Metadata is hidden — names, ids, counts, sizes, timing, and a moved page's earlier plain versions remain | false |
Someone outside a space learns it exists — only a reused page id answers id_taken, and ids are random | blocked — open for a page id |
| Revocation is retroactive — pulled copies stay | false |
| Your unlocked device is inside the guarantee — malware running as you reads it | false |
Your keys are encrypted on disk — any process running as you reads keys.json | false |
| A used key leaves the sync client's memory — Node cannot wipe one | false |
| The chain proves a device is the teammate you mean — only if the person approving compares the fingerprint | yours to check |
| The sync client you run is the one we wrote — the owner's computer rebuilds each release from its commit and signs only the same bytes; open for whoever changes the commit, and for a first install, which runs the installer our server serves | proven for the commit — open in two cases |
| A first sync spots a sealed space our server changed — later syncs do; a first sync trusts what it is served | false |
| Our server pairs a sealed page's ciphertext with another page, key, or version — each is bound to its page's id, key, version vector, and whether it is a removal | blocked |
| An older version of a sealed page is always refused — not by a device meeting the page first | false |
| A device sees every version and removal — our server can withhold one | false |
A removal happens only when our server lists it — managers also remove the unlisted, but keep whom it lists; key members shows who | partly |
| Every device learns of a removal — our server can withhold it, or show a fork, for a time | false |
| A removed member's writes are refused at once — devices refuse them a week after the new key | false |
| A lost laptop reads what is written after a restore — open in a space until its managers sync, or with an older sync client | blocked — open in two cases |
| Computers and AIs work while the account plane is down — for fifteen minutes, then refused | for fifteen minutes |
| A page one member writes cannot steer another's AI — sharing a space trusts them with your AIs | false |
| A member's tool edit runs elsewhere unreviewed — only the approved hash runs, unless a file is run by hand or another way | blocked — open in two cases |
| Only a manager changes a sealed space's policy — our server cannot refuse an editor's edit there | false |
| Summarising spans a sealed and an open space — it runs on a member's device, over what they read | false |
| We can restore a sealed space whose every device and recovery bundle are gone | false — nobody can, us included |
The host cannot read your sealed spaces. Not no system anywhere sees plaintext: your device and the model do.
Hardware enclaves are a weaker guarantee
SEV-SNP, TDX, and confidential GPUs are trust in silicon, not trust in mathematics. Strictly weaker, and never presented as the same.
Your reviewer checks every artifact here.
Every artifact a vendor review asks for, absences in the same type.
| Artifact | State |
|---|---|
| Security design, with its limits | This page, in full |
| Responsible disclosure | Below, and /.well-known/security.txt per RFC 9116 |
| Where the data sits | Rented servers in Europe, one host; sealed spaces are ciphertext there |
| Backups | Nightly dumps on the same server, encrypted as they stream to a key that is not on it, fourteen kept; a copy of who may reach what each minute, a day kept |
| AI sign-in | OAuth with PKCE, S256 only; a client registers itself, and every client is public, so a token is not bound to its sender; the approval page runs no script and sits in no frame |
| AI tokens | An access token lasts an hour, a refresh token thirty days, and the chain ends ninety days after the approval; a refresh token used twice ends the whole chain |
| Computer requests | Each signed with the computer's own key, within two minutes of the brain's clock; a nonce works once |
| Sessions | Each person sees every live session with its browser and address; signing the others out, a password change, or a reset ends every AI grant made before it |
| Transport | HTTPS on every host, with HSTS for two years |
| Passwords | 12 to 200 characters, never one of 72,985 common ones, never built on the address; ten failures in fifteen minutes block an address's sign-in until the window passes |
| Containers | Every capability dropped, a read-only root, only the networks its work needs, base images pinned by version and digest; only the edge publishes a port |
| Releases | Each part passes its typecheck and tests before it gets a number; a service that fails its health goes back to the number it ran; two brain processes are replaced one after the other, so a release drops no request, and the account plane's restart is a pause |
| Two-step sign-in | TOTP or ten recovery codes, each kept as a hash; staff resets are on the trail |
| Staff trail | Every staff change, sign-in, and page view is a row, kept a year, never edited |
| Management cockpit | IP-listed, with staff logins apart from every customer's |
| Third parties on the account plane | None; see the privacy page |
| Third parties on this site | None. default-src 'none', no analytics, no access log |
| Penetration test | None commissioned |
| SOC 2, ISO 27001 | None |
| Bug bounty | None. Reports are read and answered |
| Data processing agreement, subprocessor list | None signed, none published |
| Source code, signed builds | The sync client's source is at /download/instibrain-sync-client-latest.tgz; the owner's computer rebuilds each release from its commit and signs it, and our server holds no release key; the server's source is unpublished |
Found a hole? Tell us first.
This is the whole policy.
Email security@webwork.ai with the details. The people who build instibrain read it.
Two requests, not conditions:
- Give us reasonable time before you disclose.
- Do not access data that is not yours. Describe the path, and we will reproduce it.
No bug bounty, no promised payment or response time. The machine-readable contact is /.well-known/security.txt.
Bring this page to your security review.
Every claim on it is one your reviewer can check.