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 offers a stronger alternative: Advanced Protection. With a user-set PIN, keys are derived via OPAQUE — a zero-knowledge protocol where your PIN never leaves your device and the server holds no key material. There is no admin panel where an operator can browse Advanced Protection memories, no database query that returns plaintext, no backdoor "just in case." If you are evaluating memory services, ask one question: "Can the operator decrypt my data at rest?" With Advanced Protection enabled, the answer is no — enforced by cryptography, not policy.
The default tier (no PIN required) uses strong AES-256-GCM encryption with per-user, OAuth-derived session keys. The Cloudflare Worker derives keys per request from your authenticated identity and ships them to the storage service in memory only — the storage service never persists them. Decryption requires Gnosis and Cloudflare acting in cooperation. This is a deliberate two-party custody design, not a backdoor, but it means default-tier memories are reachable by legal process directed at both parties. See the Encryption Tiers section below for full detail.
Encryption Tiers
Default Tier — Two-Party Custody
Memory content is encrypted at rest using AES-256-GCM with per-user keys derived from your OAuth identity. The Cloudflare Worker derives session keys per request and provides them to the storage service in memory only — the storage service never persists OAuth tokens or session keys. Per-user data encryption keys are wrapped both by your session key and by a server-held master secret (the durability anchor that lets you recover after long absence). Gnosis and Cloudflare acting together can decrypt; neither alone can. Default-tier content is reachable by valid legal process directed at both parties.
Want to be subpoena-proof? Set a PIN. That's it.
Advanced Protection — Zero-Knowledge
Users who enroll with a PIN activate Advanced Protection. Key derivation uses OPAQUE — a zero-knowledge password-authenticated key exchange. The server holds only blinded OPAQUE state. Your PIN never leaves your device. Gnosis cannot produce decryption keys for Advanced Protection users. Not reachable by legal process directed at Gnosis alone. Available at launch or in the early-access to public-launch window.
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 yields only encrypted blobs for memory text. Without the per-user key, the ciphertext is indistinguishable from random data. In the default tier, session keys are derivable by Gnosis and Cloudflare acting together (two-party custody). In the Advanced Protection tier, keys are derived via OPAQUE from a user PIN that never leaves the device — there is no recovery mechanism and no party that can bypass 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).
Beta Transparency
Pre-Release Access Disclosure
During the beta period, 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. Gnosis does not log search queries, memory content, or any user-generated text.
As Gnosis approaches general availability, this programmatic access will be removed and the encryption architecture will enforce that only the authenticated user can access their decrypted memories.
Multi-Agent Security
Gnosis supports multiple agents, shared collections, and cross-agent signals. Each layer has its own security boundary.
Namespace Isolation
Each agent identity operates in a fully isolated memory namespace. An agent's memory_add writes to its own partition. An agent's memory_search returns only its own memories by default. The owner controls cross-namespace access through owner_access — a role that grants none (fully isolated), reader (search + read the owner's memories), or member (read + write to the owner's namespace).
Collection Permission Enforcement
Every write operation to a shared collection checks the caller's role before executing. Members get full read/write. Readers can search and retrieve but cannot create, modify, or delete. Knowledge packs enforce write restriction at the API layer — only the owner can write, regardless of member role. Partial name matching is disabled on permission-sensitive operations to prevent accidental grants.
Signal Security: Zero-Content by Design
Gnosis signals contain no content. A signal references memory IDs, not memory content. The recipient must already have read access to the referenced memory's collection to retrieve it. Signals cannot be used to leak content across collection boundaries — they are a notification mechanism, not a data transfer mechanism. Even if a signal is intercepted, it contains only opaque IDs.
Cross-Boundary Leak Prevention
Key seeds and email addresses are not exposed across encryption boundaries. Error messages visible to MCP clients contain no user content, no key material, and no internal identifiers. Replication between database nodes uses echo-prevention triggers to prevent signal and collection data from bouncing between replicas.
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
Vector embeddings are generated locally within the application infrastructure. Memory text is processed via local inter-process communication — never sent to an external API. Text exists in memory only during processing and is not persisted, logged, or cached.
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 (Advanced Protection). With Advanced Protection enabled, the OPAQUE-based architecture prevents Gnosis or any employee, contractor, or successor from accessing the plaintext content of your memories. Enforced by cryptography, not policy. Default-tier users: memories use strong encryption, but Gnosis and Cloudflare acting together can derive keys — this is two-party custody, not zero-knowledge.
- 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.
- Cross-agent data leakage. Agent namespaces are isolated at the storage layer. Signals carry no content. Collection permissions are enforced on every write. Key seeds and emails are not exposed across encryption boundaries.
- Signal interception. Signals contain only opaque memory IDs. No content travels in the signal. The recipient must already have collection access to retrieve the referenced memories.
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 beta: 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
Gnosis Memory has not yet undergone SOC 2 auditing or independent penetration testing. These are planned as the service matures toward general availability.
Last updated: March 29, 2026