Security & Privacy

Your Data, Encrypted Under Your Key

TL;DR

ReGild encrypts every conversation, memory, and persona under a key derived from your password using Argon2id + AES-256-GCM. The master key is derived in your browser and never transmitted. We cannot decrypt your data at rest. Your account also gets four-tier user-initiated deletion, including GDPR Article 17-compliant Full Account Wipe.

Every conversation, memory, and persona you build on ReGild is encrypted under a key derived from your password. We don't have your password, and we don't have the master key derived from it. Your data at rest is ciphertext we cannot unlock without you.

By Travis Sawyer, Founder · Last updated May 8, 2026

The Promise

How does ReGild encrypt my data?

If data came from you or was derived from what you said, it is encrypted at rest under a key only you can unlock. Your password derives a master key in your browser. That master key wraps your data encryption key. The wrapped key sits on our servers as ciphertext we cannot decrypt without your participation. We don't have your password. We never receive the master key. We have the lock — you have the key.

When you send a message, your browser unwraps the key locally and the platform decrypts the specific data your request needs — that conversation, the relevant memories for your prompt, your library if you're asking about it. The decryption is request-scoped: tied to the thing you just asked for, not a blanket window into your account. When your session ends, the key is gone from our cache. What remains in the database is ciphertext.

This is the same user-held master-key model that products like Bitwarden and 1Password use to protect vaults. The architecture differs from Signal-style messaging in one specific way: because ReGild needs to do AI inference on your behalf, decryption happens server-side during your request, not in your browser. We are explicit about this — see "What we can and cannot read" below.

Scope

What's Encrypted Under Your Key

Every byte of content derived from you. Forty-six-plus columns across seventeen tables, audited annually:

Conversations

Every message you send and every persona response. Session summaries. Conversation titles.

Memories

The episodic memory entries the platform extracts from your conversations to build persistent persona awareness. Per-topic memory summaries. Behavioral observations the platform derives from how you talk.

Persona Identity

The mandates, anchors, and refinements that define each of your personas. Their evolution history across versions.

Personal Narratives

Your onboarding responses — values, goals, interests, and the longer narratives you authored about yourself.

Relationships

The relationship model the platform builds about the people in your life — the names you mentioned, the context, the interaction patterns. All of it.

Journeys

Your stated intentions, milestones, and where-you-are notes. Commission updates from your personas as they accompany you through a journey.

Library

Documents you upload to your personal knowledge library.

Feedback & Audit

Feedback reports you submit. Behavioral analysis the platform runs on the conversation.

Capability

What We Can and Cannot Read

The honest answer for every category — same precision a regulator would ask for.

What "request-scoped" means: when you send a message, the platform unlocks only what your request needs — that conversation, the relevant memories for your prompt, your library if you're asking about it. Same as your phone unlocking your photos when you tap one: the system unlocks for the specific thing you just asked for, then locks again. We do not run analytics on your decrypted content. We do not train models on it. We do not snapshot it. The decryption is bound to the request you sent, not a blanket window into your account.

Your messages

Only as your request needs it

Encrypted at rest under your key; the platform unlocks only what your active request specifically requires

Persona responses

Only as your request needs it

Same as above — request-scoped, not blanket

Your memories & relationships

Only what your request retrieves

Encrypted at rest under your key; only retrieved memories for the current prompt are unlocked

Your password

No, never

Hashed by Supabase Auth (bcrypt). The master key derived from it never leaves your browser

Your master key

No, never

Derived from your password in your browser; never transmitted to our servers in any form

Your data encryption key

Only as your request needs it

Wrapped at rest under your master key. The platform unwraps it briefly while serving your request, then it leaves the cache

Your email address

Yes

Plaintext in our auth system — required so you can sign in

IP addresses + session timestamps

Yes

Auth logs, rate limiting, abuse prevention

API keys you stored in the vault

Only when you trigger an integration

Decrypted only during your active session, only when you ask your persona to use a connected service (e.g., 'check my last workout,' 'pull this Notion page'). The vault is not used for background jobs and is not used for our internal operations. See honest gaps for the architecture detail.

Honest Disclosure

Why does ReGild have two encryption zones?

We could pretend the system has only one encryption zone — yours — and gloss over the rest. We are not going to do that. Here is the full picture, and why it matters that we tell you.

ReGild has a small amount of its own internal operating data — tooling, configuration, and platform operations content — that is encrypted under our server-held key, not yours. We need this data to be editable by us as the platform evolves, which means the key must be server-side.

Your data does not flow through that zone. The two zones are separated by ownership: anything owned by a real user account encrypts under that user's key. Anything owned by ReGild's internal operating account encrypts under our key. The platform's encryption layer enforces the boundary at write time — and there is a fail-closed guard that throws an error rather than silently degrade your encryption if your key is missing during a write.

Your Zone

Key HolderYou hold the key (derived from your password)
ContainsAll conversations, memories, persona identities, narratives, relationships, journeys, library, feedback
Our AccessOnly what your active request needs to unlock

Operator Zone

Key HolderReGild holds the key (server-side)
ContainsInternal tools, configuration, and platform operations data
Our AccessAt any time (we maintain this data)
Deletion

What Happens When You Delete

Four tiers of deletion, each user-initiated, each immediate. We do not soft-delete and silently retain. We do not honor "delete" by hiding rows behind a flag. The deletion is real.

Per-Persona Start Fresh

From the persona's settings

Wipes one persona's conversations, memories, and behavioral analysis. The persona itself remains — same name, same identity, same configuration. The slate is clean.

Account Start Fresh

From Data & Privacy settings

Wipes conversations, memories, and journeys across every persona on your account. All your personas remain — their souls intact. Your library, integrations, and account stay too. Confirmation phrase required.

Per-Persona Wipe

From the persona's settings

Deletes a persona entirely — its identity, all memories, all conversations, the whole thing. Other personas on your account are untouched.

Full Account Wipe

From Data & Privacy settings

Deletes everything. Personas, memories, conversations, integrations, library, vault, account. Your auth identity (email, password hash, sign-in metadata) is removed as the final irreversible step. After this completes, there is no record of your account on our servers. Confirmation phrase required.

Full Account Wipe is GDPR Article 17 compliant — your right to erasure includes the auth identity, not just the user data. The deletion endpoint removes it as the final step. We verified the full flow with row-count verification before publishing this page.

Legal Process

If Law Enforcement Asks

We will respond to valid legal demands. We will not pretend otherwise. Here is what we can and cannot provide.

Your email address

Yes

Plaintext (stored in our auth system)

Account creation date + session timestamps

Yes

Plaintext

IP addresses from authentication logs

Yes

Plaintext

Message content

Ciphertext only

We do not have your master key. We cannot unlock the data without you.

Memory + relationship content

Ciphertext only

Same — encrypted under your key

Persona configuration derived from you

Ciphertext only

Same

Your master key or password

No

Never transmitted to our servers; never stored

Stored API keys (vault)

Yes

Vault is operator-held by design — see honest disclosure above

Account login record (post-deletion)

No

Full Account Wipe removes the auth row entirely. After deletion there is no email, no password hash, no record.

A Note On Third-Party Inference Providers

Your conversations are sent to large-language-model providers (Anthropic, Google Vertex AI, others) for inference at request time. That is how the chat works. Provider-side retention windows still apply. As of this writing, Anthropic retains API logs for thirty days for paid API usage; after that, they delete the request/response data. A subpoena served outside that retention window would find no corresponding logs at the provider, and would find only ciphertext at ReGild.

Primitives

What encryption standards does ReGild use?

We did not roll our own cryptography. The primitives below are NIST-approved, widely audited, and well understood.

AES-256-GCM

Authenticated symmetric encryption. NIST-approved (SP 800-38D), used in TLS 1.3 and most modern encrypted storage. 96-bit IV, 128-bit authentication tag, 256-bit key. We use the Node.js built-in implementation. No third-party crypto library for core operations.

Argon2id

Memory-hard, GPU-resistant key derivation. We derive your master key from your password with parameters that meet or exceed OWASP 2026 recommendations. Parameters are stored per-wrap on the server so future upgrades roll out lazily without invalidating existing data.

BIP39 12-Word Recovery Phrase

Industry-standard wordlist (BIP39) for your zero-knowledge recovery phrase. Generated in your browser via the Cure53-audited @scure/bip39 library, shown once, never transmitted to our servers. If you forget your password and have your phrase, you can recover. If you lose both, your data is unrecoverable. We state that limit clearly so no one is surprised.

Breach Detection (HaveIBeenPwned)

At sign-up, password change, and password reset, we hash your candidate password in your browser and send only the first five characters to the HaveIBeenPwned range API (k-anonymity). Breached passwords are rejected before submission.

Transport Security

TLS 1.2 or 1.3 for every connection. Cloudflare WAF for edge protection. HSTS enforced. Cross-origin requests restricted to known ReGild domains. Content Security Policy active.

Open Items

What's Still Server-Readable, And Why

No system is perfect. Here are the residual server-readable fields, why each exists, and what we plan to do about them.

Vault Keys

When you connect an integration — Hevy, Mealie, Notion, or your own AI provider key under BYOK — your credentials are encrypted under a server-held vault key, not your password-derived one. We decrypt the vault only during your active session, only when you trigger an action that needs the integration. The vault is not used for background jobs and is not used for our internal operations. The reason it's a separate key hierarchy: tying the vault to your master key would mean every password change requires re-wrapping every stored API key, and OAuth refresh cycles would couple to your password lifecycle. We've kept the two key hierarchies separate so you can rotate your password without invalidating your connected integrations.

Auth Metadata

Your email address (required for sign-in) and your authentication logs (IP addresses, session timestamps, MFA enrollment status) are stored plaintext in our auth system. Standard for any SaaS with email-based authentication. Removed entirely on Full Account Wipe.

Operator Zone (by design)

ReGild's own internal operating data — tools, configuration, platform operations content — is encrypted under our server-held key, not yours. This is the two-zone architecture documented above. Your data does not flow through this zone.

Going Deeper

Want More Detail?

This page is the customer-facing summary. The full technical architecture — including key rotation procedures, threat model, vendor trust matrix, incident response plan, and cryptographic decisions log — is maintained internally and available on request for prospective enterprise customers, security auditors, or regulators.

For complementary reading:

Questions? Email hello@regild.ai. We respond.