A store holding your margins, your mistakes, and your reasoning is worth attacking, so the design assumes we are the adversary: a fully compromised instibrain server should reveal no content from a brain's secure area. That sentence is provable, and narrower than it sounds. This page draws the line for the person who runs your security review: every claim is one they can check, and the holes are listed so they do not have to find them.
# pricing/floors.md
enterprise floor: $40k / yr
never discount past 15%
approval: two founders
renewal risk: acme, q4
Same secure-area node, same instant. The right pane is what a breach, a subpoena, or a rogue administrator gets.
A brain has an open area and a secure area, and you choose per page which one it lives in. The open area is markdown we read on purpose, so a surface holding no key can reach it. Everything below describes the secure area, and none of it is a claim about the open one.
Unaudited cryptography fails review and nobody can verify it. Every primitive below ships with Node 24, so there is no third-party crypto dependency to trust. What is ours is the assembly, not the mathematics.
| Layer | Choice | Why this one |
|---|---|---|
| Content | ChaCha20-Poly1305 | The key is derived per node and per epoch, so one key covers a handful of messages and a random 96-bit nonce stays nowhere near the birthday bound |
| Key wrap | X25519 + ML-KEM-768 | Both shared secrets feed one HKDF, so a wrap breaks only if the elliptic curve and the lattice fall. These records have a decade-long lifetime, which is the harvest-now-decrypt-later target |
| Node keys | HKDF-SHA256 | Derived from the scope key, so rotation is a new epoch rather than a new secret to track |
| Membership | Ed25519 | Signs each entry in the chain that decides who may read a scope |
| Recovery | Argon2id | Derives the recovery key from a passphrase you hold, so a backup opens on a new device |
The design note named XChaCha20-Poly1305 for its 192-bit nonce.
Node ships the IETF variant, and the code uses it. At one key per node per epoch
the nonce space is not the constraint, so pulling in libsodium to recover XChaCha
would buy nothing. We would rather write this line than let a reader find the
gap themselves.
Keys are generated on the device, and none reaches us in a form we can use. The
database stores wraps and a key_id — a name for a key, never a
key. A key leaves your device only wrapped for another device, or sealed under your
passphrase in a backup you keep. Where a key sits on your device is a
separate question, and the first card answers it honestly.
X25519 + ML-KEM-768 to receive wraps, Ed25519 to sign.
256-bit, one per scope.
Derived for each node, never a secret of its own.
One per device. Useless without that device's private key.
Content and path, padded into size buckets.
Generated on the device, and it never reaches us. The private half stays in the device's own keystore: the Keychain on a Mac, the TPM on Linux and Windows. It receives wraps, signs membership entries, and signs every write the device makes.
never leaves the deviceA random 256-bit key, one per scope, wrapped once for each authorised device. The server stores only the wraps. Holding all of them teaches an eavesdropper nothing.
one per scope, wrapped per deviceDerived as HKDF(scope key, node id, epoch). No node carries an
independent secret, so rotating one is a new epoch rather than a new secret to
track. Rolling a scope key moves every node it covers to the next epoch on that
node's next write.
Assume the whole server: the database, the disks, the process memory, and an administrator acting in bad faith. Five of these hold. The sixth is the one we will not claim. For an open-area page the same attacker reads the page, because that is what the open area is.
The body is ciphertext under a key derived per node. The database has never held the key.
Paths are encrypted too, so the server cannot tell pricing/floors from legal/nda. The scope name is a plaintext column and does not hide — see the last cell.
It cannot merge what it cannot read, so it returns 409 and its version vector instead of guessing.
Membership is an Ed25519 chain the client verifies from genesis. A forged entry breaks the chain.
Scope keys are wrapped hybrid, X25519 and ML-KEM-768. Harvest-now-decrypt-later needs both to fall.
Scope names, ids, counts, size buckets and timing do leak. Name a scope layoffs and we can see that word. That is the residue, and we publish it.
key_idScope names, ids, counts, and timing leak. Secure-area content does not.
If the server decides who holds a key, encryption is theatre — the operator simply adds itself as a reader and the ciphertext opens for it. Closing that is the difference between a private store and a marketing claim.
Writes are signed too. Every write carries the signature of the device or agent credential that made it, so the brain records who wrote a page and refuses a write from a credential you never admitted. A leaked credential is one signature you revoke, and it never opens the secure area, which needs a key the server has never had.
Removal is forward-only. Removing a reader appends a signed entry and rolls the scope key to a new epoch, so nothing written after it opens for them. Whatever they already pulled stays with them: no encrypted store can un-read a page.
A reader who finds an unlisted leak stops believing the listed guarantees, and they are right to. So here is the residue.
| Claim | Verdict |
|---|---|
| A breached, seized, or rogue-admin host gets secure-area ciphertext only | holds |
| The operator adds itself as a reader | blocked |
| A quantum adversary decrypts captured traffic later | blocked |
| Server-side processes read a secure-area scope | impossible by design |
| Any of the above covers the open area | false — we read it, by design |
| No system anywhere sees plaintext | false |
| Metadata is fully hidden — scope names, ids, counts, size buckets and timing remain | false |
| Revocation is retroactive — a removed reader keeps what they already pulled | false |
| Your own unlocked device is inside the guarantee — malware running as you reads what you read | false |
| The chain proves a key belongs to the person you mean — it proves we forged nothing; the fingerprint you compare before admitting a device proves the rest | yours to check |
| We can restore a brain whose every device and recovery bundle are gone | false — nobody can, us included |
The host cannot read your secure area. Not no system anywhere sees plaintext — your unlocked device sees it, the model sees it at inference, and we see every open-area page because that is what you put there. The first sentence is provable and is the thing worth selling. The second is false in every product that involves a model, and claiming it would cost the credibility of everything else on this page.
SEV-SNP, TDX, and confidential GPUs with remote attestation let a server-side process work on data the operator cannot inspect — the Apple Private Cloud Compute model. That is trust in silicon, not trust in mathematics. It is strictly weaker than this guarantee, it may earn a future tier for always-on agents, and it will never be presented as the same thing.
The artifacts a vendor review asks for, each with its state. The absences are stated in the same type as the presences, so nobody has to ask twice.
| Artifact | State |
|---|---|
| Security design, with its limits | This page, in full. No separate whitepaper |
| Responsible disclosure | Below, and /.well-known/security.txt per RFC 9116 |
| Where the data sits | Servers in Europe that we rent, one host; the provider holds the disks, and for the secure area the disks hold ciphertext |
| Backups | Nightly database dumps, newest fourteen, held by us alone |
| Third parties on the account plane | Google Fonts and the Iconify API load on my.instibrain.ai; neither receives content. Named on 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; nothing is paid |
| Data processing agreement, subprocessor list | None signed, none published |
| Open-source client to inspect | Every sync client and the protocol package, signed and reproducible. The server stays closed |
A product that sells a security claim has to be easy to report a hole in. This is the whole policy, and there is nothing else behind it.
If you believe you have found a security issue in instibrain, in this website, or in any WebWork AI product, we want to hear about it. Email security@webwork.ai with the details, and we will respond as quickly as we can.
Two requests, and they are requests rather than conditions:
We do not run a bug bounty and we are not promising a payment or a fixed response time, because we would rather state what we actually do than publish a commitment we have not tested. The machine-readable contact is at /.well-known/security.txt.
The host cannot read your secure area. Everything that sentence does not cover is on this page, in the same size type as the guarantee.