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 and stored in Supabase, accessible only to your authenticated session.
  • 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 stored server-side (so it can sync across your own devices) — 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, 90-day refresh tokens stored in localStorage).
  • Sign out immediately clears all session tokens and local data.
  • No persistent third-party auth cookies are used.
  • OTP codes are single-use, expire after 10 minutes, and are hashed at rest.

SMS & Communication Security

Messaging
  • SMS is delivered via Twilio on a verified A2P 10DLC registered messaging service.
  • OTP codes are never logged, stored in plaintext, or accessible after use.
  • 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 immutable — once recorded, the consent timestamp and version cannot be modified.
  • Re-engagement messages are rate-limited to a maximum of once every 60–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.
  • 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.

What We Deliberately Don't Do

  • We do not store plaintext wallet content — only the encrypted blob reaches our servers.
  • We do not store OAuth tokens or authorization codes in plaintext — only SHA-256 hashes.
  • We do not log OTP codes at any point in their lifecycle.
  • 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.

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, Gulf · 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