Connect with the Product Hunt community

Start a thread, join a discussion, stay in the loop.

Start new thread
trending
scritty

p/scritty

by

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.

1

123
•••
Next
Last