Security architecture
The server is a mailbox, not a memory reader.
Docmancer encrypts canonical memory revisions on the client and gives the service only enough information to authenticate, order, deliver, retain, and bill for ciphertext. We describe the metadata that remains visible instead of claiming the service knows nothing.
01
Client-side cryptography
- XChaCha20-Poly1305 IETF authenticated encryption
- Ed25519 device signatures
- X25519 sealed boxes for per-device workspace-key wrapping
- HKDF-SHA256 and workspace-scoped HMAC opaque references
02
What leaves your machine
| Data | Server view |
|---|---|
| Memory text, tags, graph data, project identity | Encrypted ciphertext only |
| Local record and revision IDs | Workspace-scoped opaque references |
| Local paths and private keys | Never sent |
| Account, device, timing, size, cursor, membership, billing | Visible operational metadata |
03
Account access is not decryption
Supabase account sessions authorize workspace and device operations. A trusted device or recovery key is still required to unwrap memory. Device revocation and key rotation are separate auditable operations.
04
Assurance and disclosure
Cross-language test vectors, real database no-plaintext tests, tenant isolation tests, dependency updates, CodeQL, SBOM generation, strict browser policy, and redacted logs are part of CI. The cryptographic design has not yet received the independent external review required for a production assurance claim. See the security disclosure policy.