At‑rest encryption + per‑client scope

Following up on the launch thread, few of you asked same good question:

transcript is immutable and redaction happens at share boundary, but doesn't local index still hold plaintext secrets at rest, so any agent/MCP client with read access (or synced backup) can pull old key straight out of search?

it is a logical deduction. scritty's model is not "your disk is the trust boundary." instead there's opt in at‑rest encryption on the local store one switch, pointed at a passphrase you hold (env var or OS keychain, never written to config) and the whole local store is encrypted, both layers, not just the transcript:

1. relational transcript + keyword index (SQLCipher): page‑level AES‑256, each page authenticated with an HMAC so tampering is detectable, key stretched from the passphrase via PBKDF2.

2. vector index: XChaCha20‑Poly1305 authenticated encryption, key derived via Argon2id, KDF params + salt bound as AAD. same passphrase as layer one so an old key buried in history isn't readable by another process, MCP client, or synced backup without it. fail‑closed -- passphrase absent > the store refuses to open, never a silent fallback to plaintext.

3. scope gating: per client. MCP access is by scoped token; hand an agent a token bound to a specific session (or set), and it can't widen to the whole corpus. cross‑corpus reads (e.g. corpus‑wide semantic search) are refused for that token, not silently honored. "one agent asking for everything" only works if you explicitly mint it admin scope.

Bottom line is trust boundary is passphrase + token scope, not filesystem. redaction stays separate share‑boundary concern; encryption is what protects local copy.