Back to home

Security

Last updated: June 2025

MnemonX encrypts your context data on your device, with AES-256-GCM, before it ever reaches our servers. Decryption is limited to specific, authorized code paths tied to your own requests — your signed-in session, and apps or API keys you've explicitly connected — never ad hoc access by MnemonX staff. See our Data Processing Agreement for the exact scope of when and how decryption occurs.

AES-256-GCM
Encryption
SMS OTP
Auth
TLS 1.3
Transit
Encrypted at rest
Storage

AES-256-GCM Encryption

On-device
  • Your wallet is encrypted with AES-256-GCM before it ever leaves your browser.
  • The encryption key is generated per user. It is stored in our database only in encrypted form, locked with a separate master key that is kept outside the database, so a copy of the database on its own does not open your data.
  • The initialization vector (IV) is unique per encryption operation — no two encrypted blobs are the same.
  • We use the Web Crypto API (native browser crypto) — no third-party crypto libraries.
  • Phase 2 domain isolation: each domain can derive its own HKDF sub-key from your master key, ensuring a connected app granted access to one domain cannot decrypt another.

Encrypted Cloud Sync

Server-side
  • We store ciphertext — the encrypted blob — at rest in the database.
  • The encryption key is also held server-side (so it can sync across your own devices). Our servers can unlock it, using the separate master key, to serve requests you make, so this is not end-to-end or zero-knowledge encryption. Server-side decryption is limited to specific, authorized code paths: your own signed-in requests, the Memory API when you've explicitly connected an app, and your own data export. There is no ad hoc or support-initiated access to read wallet content.
  • Supabase Row Level Security (RLS) policies ensure no user's own session can access another user's data. Server-side processes that use the service role (the paths above) bypass RLS by design — that's how they serve your own authorized requests — but are scoped in code to act only on the requesting user's own data.
  • All database connections use TLS 1.3 in transit.
  • Service role keys are server-side only and never exposed to the browser or client bundle.
  • Your encrypted wallet is stored in your assigned region (US: us-east-1; EU: eu-central-1). Routing is server-side — the client never connects directly to a regional database.

Authentication Security

Auth
  • Login uses SMS OTP via Twilio — no passwords to phish, steal, or reuse.
  • Sessions are managed by Supabase Auth with short-lived JWT tokens (1-hour access tokens that are renewed with a rotating refresh token stored in localStorage; you are also signed out after 1 hour without activity).
  • Sign out immediately clears all session tokens and local data.
  • No persistent third-party auth cookies are used.
  • Sign-in codes are single-use and expire after 60 seconds.

SMS & Communication Security

Messaging
  • SMS is delivered via Twilio on a verified A2P 10DLC registered messaging service.
  • MnemonX does not store or log sign-in codes. The text message itself passes through Twilio, which keeps delivery records under its own policy.
  • Marketing SMS messages include mandatory opt-out instructions ("Reply STOP") on every message.
  • Opt-out status is stored in the database and enforced at the query level — opted-out users are excluded before any send operation runs, not filtered afterward.
  • SMS consent records are append-only in the app: the consent timestamp and version are never edited after they are recorded.
  • Re-engagement messages are rate-limited to a maximum of once every 90 days per user.

API & OAuth Security

API
  • All OAuth tokens (access and refresh) are stored as SHA-256 hashes — never plaintext.
  • Authorization codes are single-use, 10-minute TTL, and hashed at rest.
  • client_secret is verified on every token exchange (authorization_code and refresh_token grants) against a hashed value — never accepted without verification.
  • Refresh tokens rotate on use — redeeming one immediately invalidates it and issues a fresh pair.
  • Prompt injection sanitization: all user-provided text processed through an 8-pattern sanitizer with length cap before any AI API call.
  • Per-domain HKDF key derivation ensures cryptographic isolation between memory domains for connected apps.
  • API access logs record every call with user ID, token, endpoint, scopes, and IP — retained 90 days for security auditing.
  • Your AI Tools (the native MCP connector) issues a unique client_id and secret per user, provisioned automatically — never a secret shared across accounts.
  • OAuth scope enforcement is mandatory — requests exceeding granted scopes are rejected at the middleware level.
  • Team/Enterprise orgs can enforce an IP allowlist on Memory API access, and can block members from connecting personal third-party apps org-wide.
  • Enterprise orgs can enable SCIM 2.0 provisioning — deprovisioning a user via SCIM also revokes that individual's own personal app connections.

Infrastructure & Rate Limiting

Backend
  • All API routes are server-side only — secret keys never reach the client bundle.
  • Stripe webhook signatures are verified cryptographically before processing any payment event.
  • Admin dashboard is IP-restricted via allowlist enforced at the edge (supports IPv4 and IPv6).
  • Admin login attempts are logged and brute-force protected.
  • Rate limiting is enforced via Vercel proxy configuration on sensitive endpoints.
  • Vercel Edge Network provides DDoS mitigation and TLS termination.
  • Security headers enforced on every response: Content-Security-Policy, X-Frame-Options (clickjacking protection), X-Content-Type-Options, Strict-Transport-Security, Permissions-Policy.
  • Redirect destinations after payment (Stripe checkout/billing portal) are validated against an allowlist — never built from unvalidated client input.
  • Regional data isolation: US wallet data stays in us-east-1 (Virginia); EU wallet data stays in eu-central-1 (Frankfurt). Encrypted wallet content never crosses regional boundaries.
  • EU data residency guarantee: EU users' encrypted wallet content and encryption keys are contractually prohibited from transfer outside the EU/EEA (GDPR Art. 44 + SCCs). This guarantee covers wallet content and encryption keys only — organisation/member directory data (name, roles, SSO config) is centralised in the US for every org. See our DPA.

Websites you publish

Hosting
  • Every published website runs in its own separate project with its own settings and secrets. No MnemonX key is ever added to a website.
  • Before a website is delivered, its code is reviewed for secrets written into the code, database tables left open to everyone, queries or commands built from visitor input, unsafe page HTML, and missing privacy basics (tracker consent, privacy policy).
  • Its packages are checked against the public OSV.dev vulnerability database: npm, Python, Go, Rust, Ruby, PHP and Java projects, and libraries loaded from a CDN. Malware reports in a package always count as serious.
  • Before every publish and update we also scan for phishing, impersonation and malware. A website is stopped only when it could put MnemonX or other customers at risk: code aimed at our systems, an install script that downloads or reads secrets, or malware in a package. Other findings are shown to the owner with how to fix them.
  • Every day we recheck live websites. When automatic updates are on, a safe update within the same major version is built, its pages are checked, and the previous version is put back if anything fails. The owner is told what was found and what was done.
  • No scan is a guarantee. The owner remains responsible for the website and its content (Terms, section 11B).

Job Hunter

Careers
  • Your facts, resumes, jobs and notes are stored encrypted in your regional database with your own key. They are not end-to-end encrypted: our servers unlock them to show them to you and to run what you ask for.
  • Your lowest acceptable salary and your private reasons for leaving a job are never sent to an AI provider and never typed into a form by the browser helper.
  • A resume is built only from facts you confirmed. Software checks every number and name in a line against its fact, and a line no fact backs is flagged.
  • The browser helper runs in your own browser. It is connected with a pairing code you can revoke at any time, works only on listed job sites and mnemonx.ai, and by default stops before Submit. Pressing Submit for you is off until you switch it on and an earlier run of your applications was clean.
  • Pasted job links are fetched from public addresses only. A job Twin answers only from questions and answers you approved and refuses everything else.
  • Every AI action has a daily limit per plan, and a failed or repeated request does not charge again. No check is a guarantee: you remain responsible for what is sent in your name (Terms, section 7.9).

What We Deliberately Don't Do

  • We do not store plaintext wallet content: at rest it is the encrypted blob. Features you choose to use (import, Memory Health, connected apps, chat) process the content on our servers while they run, and it is not kept in plaintext.
  • We do not store OAuth tokens or authorization codes in plaintext — only SHA-256 hashes.
  • We do not store or log sign-in codes in MnemonX.
  • We do not send SMS to users who have opted out — opt-out status is enforced at the database query level, not post-hoc filtering.
  • We do not expose the service role key or any secret to the client-side JavaScript bundle.
  • We do not share user data with advertising networks, data brokers, or marketing platforms.

Alexa (an Amazon service you choose)

  • Alexa is Amazon's, not ours. Whatever Mox says aloud, and any note you ask it to save, also passes through Amazon and is kept in your Alexa history. We cannot see or delete that.
  • Every request to our Alexa endpoint is checked as really coming from Amazon and from our skill (certificate chain, signature, timestamp, skill ID). Anything else is rejected.
  • You sign in once through our own consent screen and choose which wallet areas Alexa may read or write. Access can be narrowed or revoked at any time; "Disconnect Alexa" at mnemonx.ai/alexa revokes it immediately.
  • Private areas are read aloud only after a 4-digit voice code you choose. We store only a salted, scrambled form of it, never show it, and lock private areas after three wrong tries.
  • Passport, ID, social security, bank account, card numbers and passwords are never read aloud, and Mox refuses to save them by voice.
  • Saving by voice is a new short note on a list, never a change to existing data, and only after Mox reads it back and you say yes. Each note is kept in your version history.
  • We do not receive your voice recordings and do not keep your questions or Mox's answers.

Data Residency

Your encrypted wallet is stored in the region closest to you at signup. Encrypted content never crosses regional boundaries.

🇺🇸 United States

Supabase us-east-1 (AWS Virginia)

Default region · US, Canada, global users

🇪🇺 European Union

Supabase eu-central-1 (AWS Frankfurt)

EU, EEA, UK, Switzerland, Israel, Middle East, North Africa · GDPR Art. 44 + SCCs

  • Billing data (Stripe IDs, plan tier) is centralised on the US database — it contains no wallet content.
  • Organisation directory metadata (org name, member list, roles, SSO/SCIM/OAuth policy settings) is also centralised on the US database for every organisation, regardless of which region its shared wallet content lives in — this is a deliberate scope limitation, not an oversight. See our DPA, Section 5–6, for the full breakdown.
  • EU wallet data is contractually prohibited from transfer outside the EU/EEA. See our DPA for SCC documentation.
  • Pipeline regions (Australia, Southeast Asia, South America) will launch with the same encryption-at-rest architecture.

Responsible Disclosure

Found a security vulnerability? We take security seriously and appreciate responsible disclosure. Please email [email protected] with a description of the issue. We will acknowledge within 48 hours and work with you to address the problem before any public disclosure. Please do not publicly disclose vulnerabilities until a patch is live.

Privacy PolicyTerms of Service[email protected]
MnemonX — Your AI Memory, Everywhere