Security model

This page is written for security engineers and IT managers doing an adoption review. It describes what is enforced, where the boundaries are, and — deliberately — where the model is weaker than a reader might otherwise assume.

End-to-end encryption

Chat message bodies, project control-panel contents, and image bytes are encrypted with AES-256-GCM on the sending device (Web Crypto in browsers, Node crypto on the engine) before they reach the relay. Each ciphertext is bound to its context (the thread, panel, or storage path) as authenticated data, so a ciphertext cannot be replayed into a different conversation. The relay stores and forwards ciphertext it cannot decrypt.

Key management and device trust

• The account's encryption key is generated on your computer during desktop setup and is never sent to Wilow. There is no key escrow and no server-side recovery of chat content.
• Additional devices get the key by scanning a QR code shown by an already-trusted device — a deliberate, physical act. Each device is recorded and can be revoked individually.
• Two-step verification (Settings → Account) adds an authenticator-app code to every sign-in. It is enforced twice: the app demands the code before any chat renders, and the relay refuses the writes that matter — sharing a project, moving the home computer, changing the email, deleting the account — from a session that has not passed it. Recovery codes are stored hashed and work once.
• Revocation is enforced at the data layer, not just at login: a revoked device's still-valid session matches zero rows under row-level security and cannot re-enable itself.
• Enterprise projects use per-project keys wrapped to each member device; removing a member removes their wraps in the same operation that cuts their database access.
• Shared projects use key epochs. Revoking a member — or inviting one without “share past history” — mints a new project key epoch for everything written from then on; earlier messages stay sealed under the epochs they were written in, and a member can only ever read the epochs wrapped to them. Un-shared history is unreadable by construction, not by a client-side filter. Rotation cannot un-share what a member could already read.
• Company secrets are sealed per owner group. Each group of a Company OS project has its own key, held only by the owner's Wilow and the Wilows of that group's editors; a vault value is sealed for exactly the groups it is granted to, so a member outside them cannot decrypt it. When someone leaves a group, that group's key rotates and the values are re-sealed.

What the relay stores

Every tenant's rows are isolated by row-level security on a default-deny model; the relay's privileged key never leaves its server-side functions, and clients authenticate as scoped users with no cross-tenant reach.

Account security

• Email + password sign-in; passwords require ≥ 8 characters and are screened against the Have-I-Been-Pwned breach corpus (privacy-preserving k-anonymity check) at registration.
• New accounts must confirm a 6-digit email code before the first sign-in.
• Password reset links only redirect to allow-listed Wilow origins.
• Publishing to the Marketplace additionally requires a confirmed email and a minimum account age (see Publishing).
• Delete your account at any time from Settings → Danger zone. It permanently removes your account and all your data — projects, chats, devices, and daemon — from Wilow's servers in one transaction. It is scoped to your own account and irreversible.

Marketplace trust pipeline

Four independent controls stand between a publisher and code executing on an installer's machine:

• Publish-time verification: the relay independently downloads (or receives) every artifact, recomputes its SHA-256, and runs a server-side scan for embedded secrets and prompt-injection patterns. A mismatch or scan failure rejects the publish.
• Install-time pinning: the installer re-verifies every artifact against the hash recorded at publish time. The hash — not the URL, not the mirror — is the guarantee; a tampered source fails closed.
• Explicit consent: tools that run code locally show a consent screen first — the exact repository (or private-escrow notice), the pinned source hash, the literal setup commands, and the declared permissions. Setup commands are restricted to an allow-list (npm install, npm ci, npm run <script>, uv sync).
• Kill-switch: unpublishing (by the publisher, or Wilow moderation) delists a tool and stops running instances on installers' machines on the next reconcile (minutes), and private-source downloads stop immediately.

Enterprise controls (summary)

Roles (Owner/Admin/Editor/Reader), instant data-layer offboarding, per-enterprise policies (external sharing on/off, marketplace installs open vs. enterprise-only, approved hosting/database/AI providers), and owner/admin oversight of enterprise projects. Full detail in the Enterprise adoption guide.

Network egress (for firewall allow-listing)

Wilow is outbound-only HTTPS — it opens no listening ports on your network (the engine binds loopback-only ports on the machine itself). Egress by function:

Software updates

• Desktop updates are fetched from Wilow's public GitHub releases and integrity-checked (SHA-512 in the update manifest) before install. Auto-update can be toggled off.
• Installed marketplace tools update through the same hash-pinned pipeline as installs; per-tool auto-update is a user setting.
• When connecting an account needs a command-line tool your machine doesn't have (macOS/Linux), Wilow downloads the vendor's official release into its own folder rather than changing your system: no administrator password, no package manager, and it is removed when you uninstall Wilow. Each download must match a SHA-256 pinned inside Wilow before it is unpacked or run — an unrecognised build is refused rather than executed.

Reporting a vulnerability

Email wilow@quorderit.com with reproduction details. Please do not test against other users' accounts or data; registering disposable accounts for research is fine.