stash_security & data

What we can and cannot see

Security & Data

SanctumX, LLC · effective 15 September 2026

This page states, in plain language, what the operator of Stash can and cannot do with your data — and how to verify the claims rather than trust them.

1. The architecture, briefly

Every memory and summary is sealed with XChaCha20-Poly1305 under an identity's master key before it touches storage, and each sealed row is cryptographically bound to its exact position, so ciphertext cannot be moved or replayed elsewhere and still authenticate. The master key exists on our servers only in wrapped form: presenting your capability token derives the unwrapping key for the life of one request. We store a verifier of each token — never the token, never the key. Where the server's SQLite build supports SQLCipher, whole-file encryption is layered on top. The memory log is append-only, enforced by database triggers rather than convention. Transport is TLS-only.

2. What the operator can see

3. What the operator cannot see

The content of any memory or summary, ever, without a valid capability token for that identity. There is no administrative bypass, no master key, no recovery path, and no backdoor. This is why lost tokens mean lost memories: the property that protects you from us is the same property that prevents us from rescuing you.

4. Legal process

We comply with valid legal process to the extent technically possible. In practice, that extent is: ciphertext, registry metadata, and web logs. We cannot produce plaintext memory content for any identity, because we cannot produce it for ourselves. We have no mechanism to add one for a specific target, and building one would be visible in the open source.

5. Verify it yourself

The implementation maintains an invariant suite of 103,993 checks covering the encryption, isolation, and append-only properties. Better, the sealing is verifiable from outside: write a memory containing a distinctive string through the API, and no plaintext trace of it exists in any file at rest — a check anyone operating their own instance can run in one grep, and the ritual our own deployment was accepted with.

6. Backups

Backups contain the same ciphertext and registry metadata as the live system, are useless without capability tokens, and rotate on a roughly weekly cycle.

7. Reporting a vulnerability

Security research against your own identities is welcome and has already improved the service. If you find something, write to contact@sanctumx.ai with enough detail to reproduce it; please do not test against identities you do not own, and do not run load tests against the shared host. We will acknowledge honest reports and credit them if you wish.