Three keys, three places, and we hold only the one that opens nothing.

The design goal is simple to state: an attacker with everything our servers hold, including a customer's username and password, must learn nothing about the customer's wells.

What lives where

Item	Where	Who can read it
Raw rig files (mudlogs, geology tables, surveys)	Your workstation only	You
Built dashboard objects (plain JSON)	Your workstation (out/)	You
Encrypted objects (AES-256-GCM over gzip JSON)	Your workstation and, with sync on, our private object store	Anyone with the data passphrase; nobody else, including us
Data passphrase	Engine config on your workstation; typed into the browser per session	Your team
Username, password hash (scrypt), licence state, audit log	Our private store	Our admin console
Engine push secret (hashed)	Hash on our side, plain in your engine config	Your engine

The three keys

1. Account password

Authenticates a person to the service. It is checked server-side against an scrypt hash and produces a short-lived, HttpOnly, SameSite=Strict session cookie. It unlocks the dashboard shell and the right to download ciphertext for your organisation. Nothing more.

2. Data passphrase

Chosen in the engine, never transmitted. Browser and engine derive the same AES-256 key: PBKDF2-SHA256 (250,000 rounds, per-organisation salt) then HKDF-SHA256. Every object is encrypted with a fresh random nonce and authenticated (GCM tag), so a wrong passphrase fails cleanly and a tampered object is rejected. A leaked account password does not help: without this passphrase, the ciphertext is noise.

3. Push secret

Lets your engine upload new objects. It is a random 256-bit token; we store only its hash. It cannot read anything and can be rotated from the dashboard's Account page.

Local mode: zero upload

If the policy is "nothing leaves the site", skip sync. The dashboard can open the engine's output folder directly through the browser's file-system access API (Chrome and Edge). The licence check is the only network call.

Platform hardening

• Static web app served from a global CDN; API functions are small, stateless and rate-limited.
• Strict Content-Security-Policy, no third-party scripts on the dashboard, no analytics, no cookies except the session.
• Private object storage: objects are not reachable by URL, only through authenticated functions.
• All transport over TLS with HSTS preload; the AI add-on calls the model provider directly from your engine and browser with your own key.
• Secrets (session signing key, provider keys) live only in the deployment's environment variables.

What we can and cannot do

We can see that an organisation exists, how many objects it pushed and when, and the names of the objects (well identifiers are hashed by the engine before upload when you enable anonymise_names). We cannot read any value, depth, event or geology description, and we cannot recover a lost data passphrase. If it is lost, run borewatch set-key and push again; the engine rebuilds everything from the files on your disk.

Cryptography is implemented with the platform primitives (WebCrypto in the browser, the cryptography package in the engine); the formats are documented in the engine source so you can verify them.