The threat we designed for
The requirement we set ourselves was concrete: someone holding only the database credentials, or a copy of the database, must not be able to read anyone's memories. That covers the most likely serious incident for a small company: a leaked connection string, a compromised hosting console, or a backup in the wrong hands.
What we do not claim is zero knowledge. The running service decrypts your memories in memory to embed, search, score, and return them, because server-side semantic search structurally requires it. If you need a memory no server can read, run the open-source engine on your own machine.
Encryption at rest
Memory content, summaries, link explanations, Notion tokens, and waitlist emails are encrypted before they reach the database, using envelope encryption:
- A data key is generated for each user. Every value is encrypted with AES-256-GCM under that user's key, with a fresh nonce per value.
- Each data key is stored only in wrapped form, encrypted by a master key that is held outside the database and never written to it.
- Every ciphertext is bound to its user and column, so a value cannot be moved to another user or another field without failing to decrypt.
- Erasing an account destroys the user's data key. Anything left in a backup is then unreadable, a crypto-shred.
- Where a field must remain searchable for equality, such as a waitlist email, we store a keyed hash beside the ciphertext. That reveals whether two values are equal and nothing else.
The master key is provisioned as a secret in the hosting environment and backed up offline. Moving it to a managed key service is on the roadmap and changes nothing about the format above.
In transit
All traffic to the web app, the API, and the MCP endpoint is served over HTTPS. Cloudflare terminates TLS and provides edge protection in front of the service. Calls to the AI providers that process memory text are made over TLS with provider API keys held as environment secrets, never in code or in the database.
Authentication and tokens
People sign in through Clerk, which handles passwords, passkeys, social sign-in, and multi-factor authentication. We store only your Clerk identifier.
Assistants connect through OAuth 2.0 with PKCE and dynamic client registration, the flow Claude, ChatGPT, and MCP clients expect. Access tokens live 24 hours. At rest we keep only a SHA-256 hash of each token, so a database copy contains nothing that can be replayed. Refresh tokens are never written to disk. Disconnecting an assistant revokes its tokens immediately.
Isolation
Every memory, link, token, and connection record carries a user identifier, and every storage query is filtered by it. There is no path that reads across users. Memories shared with an organisation carry an explicit visibility flag and are only visible to that organisation's members. Sharing is a deliberate action by the owner and can be reversed.
What leaves the service, and what does not
Two providers receive memory text for a specific job: OpenAI to compute the vector used for search, and Anthropic to extract entities, summarise, infer causal links, and detect contradictions. Both are bound not to use the content for anything else. The full list of providers and what each receives is in the Privacy Policy.
Error monitoring runs with personal data reporting switched off, so memory content is never included in a crash report. Nothing is used to train models, ours or anyone else's.
Operations
| Area | Practice |
|---|---|
| Hosting | Application on Railway; managed Postgres on Neon in AWS us-east-1. |
| Secrets | API keys, database credentials, and the master key are environment secrets, rotated on a schedule and after any suspected exposure. |
| Changes | Schema migrations run only after a database snapshot. Destructive migrations are never automatic. |
| Access | Administrative endpoints require a separate key and every call is written to an audit log with who, what, and outcome. |
| Abuse | Per-user rate limits on reads and writes; import uploads are size-capped. |
| Backups | Neon point-in-time recovery, with erased users made unreadable by key destruction rather than waiting for backups to age out. |
Open source, by design
The memory engine, its scoring, forgetting, and the MCP tools are published under the AGPLv3 at github.com/Astrix-Labs/papez. You can read how a memory is ranked, when it is pruned, and what each tool does, rather than take our word for it. The hosted service adds authentication, storage, encryption, and connectors on top of that engine.
Responsible disclosure
If you find a vulnerability, please report it privately through GitHub security advisories or by email to [email protected]. Do not open a public issue. You will hear from us within 48 hours, and we will work with you to understand the issue and coordinate a fix before any public disclosure. Good-faith research within these bounds will not be met with legal action.
- Test only against accounts you own.
- Do not access, modify, or retain data belonging to others.
- No denial of service, spam, or social engineering of our people.
What we are not yet
We do not hold a SOC 2 or ISO 27001 certification today. The master key is not yet in a managed key service. Full account erasure is performed by us on request rather than by a button in the app. Each of these is on the roadmap, and this page will change when they ship. We would rather tell you what is true than what sounds good.
Astrix Labs Inc. · [email protected]