Trust Center
Our position: publish the actual architecture, pick honest words for it, and state plainly what we do not yet claim. This page is the procurement-facing summary. The full cryptographic stack and threat model — algorithms, library versions, what we defend against and what we don't — is published at anamnesis.smtry.ai/security; the architectural mechanisms are described in the security architecture page.
Data protection at a glance
| Area | Posture |
|---|---|
| At rest | Every user's memory is encrypted with a key derived from their own credential. No master key — there is no site-wide key that decrypts everyone, and a full-database compromise alone decrypts nothing. |
| Key handling | Keys are derived per request, used, and released — never stored. Full primitive stack (Fernet, HKDF-SHA256, argon2id, library versions) published on the security page. |
| In transit | TLS 1.3 at the edge; session cookies HttpOnly / Secure / SameSite. |
| Isolation | Per-user key derivation means a leaked credential exposes only that account. No blast radius beyond the credential that leaked. |
| Browse without reading | The dashboard's browse view is built from an encrypted index of titles and structure only; a memory body is decrypted just once, when the owner opens that one item. |
Access control
- API keys are CSPRNG-generated tokens; passwords are hashed with argon2id at OWASP baseline parameters.
- Scoped service tokens: a credential can be issued read-only (
memory.read), and the scope is enforced at the API layer on every route — a read-only token cannot write through any surface. Tokens are self-serve and revocable. - Read-only guest access for local models: the one-way mirror lets a local client read a shared pool while its writes never leave the machine (details).
Memory integrity
Encryption keeps memory private; integrity keeps it honest. This is where a memory product either earns trust or quietly fails:
- Screening at capture. Content is screened before it is stored; text that reads like a prompt-injection attempt is held for review rather than trusted automatically, and content that isn't a genuine memory is dropped rather than persisted.
- Provenance and trust tiers. Every memory carries a provenance-derived trust tier. Uncorroborated content is labeled and kept out of decision-weight — an imported claim cannot impersonate an established fact (measured).
- Temporal belief revision. When a decision changes, the superseded record is retired from current context and preserved for audit and point-in-time history (measured).
Data ownership and lifecycle
- Your memory is yours. Export is self-serve from the dashboard.
- Deletion is self-serve at both granularities: individual memories, and full account deletion.
- We do not train models on your memory content.
Operations
- Continuous monitoring: an independent synthetic canary probes production every 15 minutes (health, retrieval, capture, integrity of stats) with automated alerting.
- CI: every change to the server and pipeline code runs the full test suite plus a dependency vulnerability audit; failures block the change.
- Staged releases: behavior changes to the memory pipeline ship behind feature flags with instant kill switches, and are dry-run read-only against real data before they are enabled.
Sub-processors
| Provider | Purpose |
|---|---|
| Fly.io | Application hosting and storage (US region) |
| Anthropic | LLM processing during memory consolidation (hosted tier) |
| Resend | Transactional email (account and alerting; no memory content) |
The on-premises tier removes the hosted LLM dependency: consolidation runs on a local model and memory content does not leave the machine.
What we do not claim
Stated here because trust pages that only list wins aren't trustworthy:
- Not vendor-blind today. Operators with production access can decrypt user content; the derivation inputs live with the ciphertext. The roadmap to client-held keys — where the server stores ciphertext it cannot read — is published as a phased plan, each phase shippable and honest on its own. We will not market a property the code does not have.
- No formal certifications yet. SOC 2 is planned as the enterprise tier matures. Until then we publish the actual architecture, threat model, and benchmark methodology instead of a badge.
Reporting a vulnerability
Security reports: hello@jiashley.com. We read everything and respond to genuine reports.