How we protect your memories

Last updated: May 2026

Organic LLM treats long-term memory as sensitive data. We combine strict access controls on the server with application-layer encryption for the human-readable text we store in the memory database alongside the numeric fingerprints we use for search—so a storage leak is much less likely to spill readable conversations and summaries.

Why this matters

Memory systems remember context across sessions: preferences, projects, and phrasing that is inherently personal. That usefulness creates risk if data is ever exposed through a misconfiguration, a compromised host, or an upstream incident. We invest here because trust is part of the product, not an afterthought.

At a glance

  • AccessMemory APIs resolve the signed-in user on the server only; clients do not supply identity for reads or writes. Deletes are checked against what already belongs to you.
  • AbuseRate limits and response validation sit at the public boundary so automated or buggy clients cannot hammer memory or receive malformed payloads unchecked.
  • StorageWhen enabled, sensitive text fields in the memory database are encrypted with AES-256-GCM before persistence and decrypted inside the app when search or UI needs the text. Keys are versioned deployment secrets so we can rotate without rewriting the whole system in one shot.
  • LoggingWe do not log raw memory content in production.

How it fits together

Organic LLM uses Mem0 with a memory database (Qdrant in our setup). Mem0 still writes numeric fingerprints for semantic search; what we additionally protect is the readable text stored with those records—for example the main memory text. A thin wrapper encrypts those fields on the way into the memory database and decrypts them on the way out, so the rest of the application keeps a normal Mem0 mental model.

Those search fingerprints stay readable at the database layer by design: locking them down would break ordinary similarity search. The tradeoff is intentional—we reduce exposure of readable memory text at rest while keeping relevance and performance.

What a database-only attacker does not get
Without app keys
With Organic LLM
Encrypted blobs
Your memories, readable
Search numbers
Relevant results
No readable text
Normal experience

Deletion and retention

When you delete individual memories or wipe memory in the product, we remove those records from the memory database on the backend. Full account deletion is available on request through our privacy contact flow.

What we claim—and what we do not

  • We do claim a meaningful layer of protection for stored memory text if someone obtains database payloads without application keys, plus a disciplined server boundary (auth, limits, validation, ownership checks).
  • We do not claim that encryption replaces TLS, authentication, secure hosting, or careful vendor configuration. It is defense in depth, not a single magic switch.

Further reading

For more depth on the problem space, industry context, and design tradeoffs—including how we chose our encryption approach, how it deploys, and where it lives in the stack—see Memory Encryption.