Security and Encryption

How Gnosis protects your memories — and why we can't read them even if we wanted to.

The Core Principle: "Can't, Not Won't"

Most services promise "we won't read your data." That is a policy. Policies change — with new ownership, legal pressure, shifting business incentives, or a single rogue employee. A promise not to look is only as strong as the people making it, and people change.

Gnosis takes a fundamentally different approach. The system architecture is designed so that stored data cannot be decrypted without the user's credentials. Your encryption keys are derived from your OAuth credentials through a key derivation function. Keys exist only in memory during your active session and are never stored at rest. When your session ends, the key is gone — there is no stored copy for anyone to access. There is no admin panel where an operator can browse user memories, no database query that returns plaintext, no backdoor "just in case."

This is not a pledge. This is enforced by cryptography, not policy. The encryption is not a feature we added on top — it is the foundation the entire system is built on. If you are evaluating memory services, ask one question: "Can the operator decrypt my data at rest?" If the answer is "they won't" instead of "they can't," you are trusting a policy. We would rather you trust the architecture.

What Is Encrypted

Memory Content: Encrypted at Rest

The actual text of your memories is encrypted using AES-256 with per-user keys. Each user's encryption key is derived from their authentication credentials through a key derivation function. No two users share a key. The server processes encryption and decryption in memory during active requests, but what is written to disk and stored in the database is ciphertext.

A complete database dump — from a breach, a subpoena, or a disgruntled operator — yields only encrypted content for memory text. Without the per-user key, the ciphertext is indistinguishable from random data. There is no stored master key. Each user's encryption key is derived from their own credentials and exists only during authenticated sessions. There is no recovery mechanism that bypasses the user's credentials.

What Is Not Encrypted (And Why)

Transparency means telling you what we don't protect, not just what we do. Three categories of data are stored without encryption, each for a specific technical reason.

Vector Embeddings

When you store a memory, Gnosis generates a vector embedding — a mathematical representation of the memory's meaning in high-dimensional space. These embeddings are what make semantic search possible: they allow the system to find memories by meaning, not just keyword matching.

Embeddings are stored unencrypted because similarity search requires computing mathematical distances between vectors. If embeddings were encrypted, every search query would require decrypting every embedding for every user — defeating the purpose of having a search index at all. This is a fundamental constraint of vector similarity search, not a shortcut we chose to take.

Critically, vector embeddings are lossy mathematical projections — the original text cannot be directly decoded, though embeddings may carry statistical information about subject matter. An embedding captures semantic relationships (that two concepts are related) but discards the specific words, grammar, and structure of the original text. An attacker with database access would see mathematical vectors, not readable text. While embeddings cannot be trivially decoded to exact text, we treat them as sensitive data and restrict access accordingly.

Account Metadata

Your email address, display name, account creation timestamp, and memory counts are stored unencrypted. This data is required for basic service operation — authenticating you, displaying your account information, enforcing usage limits, and communicating with you about your account.

API Request Logs

Endpoints accessed, request timestamps, and IP addresses are logged unencrypted. This operational data is necessary for rate limiting, abuse detection, debugging service issues, and maintaining the reliability of the platform. Logs are retained for a limited period and do not contain memory content.

What We Do Not Log

We do not log or record: memory content, search queries, the text of your memories in any form, or the content of API request/response bodies. Operational logs contain only: request timestamps, endpoint paths, response status codes, and error messages (which never include user content).

Early Access Transparency

Pre-Release Access Disclosure

During Early Access, our engineering team retains programmatic access to memory data for essential service operations — database migrations, schema updates, and data integrity verification. This access is used solely for service continuity and is never used to read, analyze, or extract user content. We do not log search queries, memory content, or any user-generated text.

As we approach general availability, this programmatic access will be removed and the encryption architecture will enforce that only the authenticated user can access their decrypted memories.

Infrastructure Architecture

Every layer of the Gnosis stack is designed to minimize exposure of user data and eliminate unnecessary trust relationships.

Edge Layer

Cloudflare Workers handle API routing, TLS termination, and DDoS protection. All traffic between your AI client and Gnosis is encrypted in transit using HTTPS. There is no plaintext HTTP endpoint. Requests that attempt to connect over HTTP are rejected, not redirected — your data never touches an unencrypted connection.

Authentication

Google OAuth 2.1 with PKCE (Proof Key for Code Exchange) flow. Gnosis does not store passwords — there are no passwords to store. Session tokens are issued with expiration times and are validated on every request. Authentication is the basis for key derivation, which means access to memories requires both a valid session and the correct cryptographic key.

Database

PostgreSQL hosted on CrunchyBridge with TLS encryption in transit. Memory content is encrypted at rest using per-user AES-256 keys before it reaches the database. The database stores ciphertext. Even CrunchyBridge operators with full database access see only encrypted blobs for memory content. Hosted in US data centers.

Embedding Generation

RunPod GPU instances generate vector embeddings from memory text. Memory text is sent to RunPod over TLS for embedding generation. The text exists in GPU memory only during processing and is not persisted, logged, or cached. RunPod instances are ephemeral compute — they process and return results, with no persistent storage of user content.

Threat Model

No security page is complete without an honest assessment of what the system protects against and what it does not. Security is about trade-offs, not absolutes.

Protected

  • Operator reading memories. The encryption architecture prevents the Gnosis operator (or any employee, contractor, or successor) from accessing the plaintext content of your memories. This is enforced by cryptography, not policy.
  • Database breach exposing memory text. A complete database dump yields only ciphertext for memory content. Without per-user keys, the data is useless.
  • Unauthorized account access. Authentication is handled by Google OAuth with PKCE. Session tokens expire. There is no password database to breach.

Partially Protected

  • Metadata analysis. We minimize what we log, but some operational metadata is inherently required — when you use the service, how many memories you have, which IP addresses you connect from. We do not sell or share this data, but we cannot claim it does not exist.
  • During Early Access: programmatic database access exists for service operations (to be removed at GA). Our engineering team can access the database for migrations, schema changes, and integrity checks. This access is necessary for a pre-release service and will be eliminated as the encryption architecture matures toward general availability.

Not Protected Against

  • Compromise of your own device or AI client. If an attacker has access to the machine where your AI assistant runs, they can observe memories as they are retrieved and displayed in plaintext. Gnosis protects data at rest and in transit, not data on your screen.
  • A government compelling you to provide your credentials. Encryption protects your data from us. It does not protect you from being legally compelled to authenticate and hand over your own data. This is a limitation of every encryption system, not specific to Gnosis.

No system is perfectly secure. We aim to minimize what we can access, be transparent about what we cannot protect against, and build the architecture so that trust is enforced by mathematics rather than promises.

Responsible Disclosure

If you discover a security vulnerability in Gnosis Memory, we want to hear about it. Please report it to security@gnosismemory.com with as much detail as possible — steps to reproduce, affected endpoints, and potential impact.

We take all reports seriously and will acknowledge receipt within 48 hours. We do not currently operate a formal bug bounty program, but we will credit researchers who report valid vulnerabilities (with your permission) once the issue is resolved.

We will not pursue legal action against security researchers who discover and report vulnerabilities in good faith, provided they avoid accessing other users' data, do not degrade the service, and allow reasonable time for fixes before public disclosure.

Compliance Status

As an Early Access service, Gnosis Memory has not yet undergone SOC 2 auditing or independent penetration testing. We plan to pursue these as the service matures.

Last updated: February 28, 2026