MemNexus Security Practices

Last updated: 2026-04-06 Status: Current Contact: [email protected]

Overview

MemNexus is an AI memory management platform for developer teams. We store users' knowledge, decisions, behavioral patterns, and institutional memory. Given the sensitivity of this data, security is foundational to everything we build.

This document describes our current security practices. We state only what is implemented and deployed today. Where capabilities are planned but not yet complete, they are marked as such.

Encryption

Encryption at Rest

MemNexus implements field-level encryption using AES-256-GCM-SIV (RFC 8452) for sensitive data stored in our database.

• 13 of 14 sensitive field types are encrypted at the application level before storage
• Encrypted fields include: memory content, user names, user emails, entity names, fact subjects, fact objects, pattern descriptions, and other user-generated content
• Not covered by field-level encryption (complete list): search indexes and embedding vectors are stored unencrypted so that keyword and semantic search work. This includes the fulltext search index over memory content (contentIndex), the memory name index (nameIndex), entity normalized names (normalizedName), fact subject and object indexes (subjectIndex/objectIndex), and embedding vectors. A searchable plaintext copy of memory content is therefore stored alongside the encrypted copy — inside the encrypted storage layer, but outside field-level encryption. Searchable encryption that would remove this exception is planned for a future phase.
• Each encryption operation uses Additional Authenticated Data (AAD) binding (userId, entityId, fieldName, encryption version) to prevent ciphertext substitution attacks

Key Management

• Per-user Data Encryption Keys (DEKs): Each user has a unique 256-bit DEK generated at first use
• Envelope encryption: DEKs are wrapped (encrypted) before storage. The wrapping uses either Azure Key Vault or a local Key Encryption Key (KEK), depending on deployment configuration
• Azure Key Vault integration: Production deployments use Azure Key Vault for KEK storage and DEK wrapping/unwrapping operations
• Per-organization key hierarchy: Planned -- a Master to Organization to User HKDF-SHA256 key hierarchy is designed but not yet implemented. Currently, key derivation is per-user only.
• Bring Your Own Key (BYOK): Planned for a future phase

Encryption in Transit

• External traffic: TLS 1.2+ on all client-facing connections (HSTS enabled)
• Third-party API calls: TLS 1.3 enforced for OpenAI and Stripe API communication
• Azure managed disk encryption: Azure Storage Service Encryption (SSE-256) with platform-managed keys provides baseline disk-level encryption

Authentication

User Authentication

MemNexus uses WorkOS AuthKit for all user authentication:

• Email and password authentication with email verification
• Social login (Google, GitHub) via WorkOS identity providers
• Single Sign-On (SSO): SAML 2.0 and OIDC support via WorkOS, configurable per organization
• Session management: Handled by WorkOS AuthKit with secure cookie-based sessions

API Key Authentication

• API keys are hashed with HMAC-SHA256 using a server-side pepper before storage
• Plaintext API keys are never stored -- only the hash is persisted
• API keys can be created, listed, and revoked via the customer portal and API
• Revoked keys are immediately invalidated

Authorization

Role-Based Access Control (RBAC)

MemNexus implements organization-level RBAC with three roles:

Data Isolation

• All data queries are scoped by userId at the application layer
• Organization-scoped queries use organizationId filtering
• Cross-tenant data access is prevented at the repository layer -- every database query includes user/organization context

Audit Logging

MemNexus maintains an append-only audit trail for accountability and compliance:

• Immutable entries: AuditEntry records are append-only by design. No update or delete operations are permitted on audit entries.
• Auth events logged: Login attempts (success and failure), API key creation and revocation, account deletion requests and completions, session events
• Event fields: Each audit entry captures: action, actor (userId), target type and ID, timestamp, IP address, correlation ID, and outcome (success/failure)
• Metadata only: Audit entries contain metadata about actions -- they never store memory content, search queries, or user-generated content
• Resource-level audit events: Planned for a future phase -- audit events for memory creation, updates, and deletion operations

Data Protection

Account Deletion

• Self-service: Users can initiate account deletion from the customer portal or API
• 7-day grace period: After requesting deletion, the account enters a read-only grace period. Users can cancel deletion and restore full access at any time during this period.
• Complete erasure: After the grace period, all personal data is permanently deleted: memories, entities, facts, topics, patterns, conversations, API keys, user profile
• External cleanup: User records are also deleted from WorkOS (authentication) and Stripe (billing)
• Pseudonymized audit record: A compliance audit record with SHA-256 hashed (non-reversible) user identifiers and data counts is retained. This record contains no personal data.
• GDPR Article 17 compliant: Right to Erasure is fully supported

Data Export

• Self-service export: Users can export all their data via GET /api/users/me/export
• Available during grace period: Data export remains available even after deletion is requested
• Standard format: Data is exported in JSON format
• GDPR Article 20 compliant: Right to Data Portability is fully supported

Data Retention

Infrastructure

Cloud Infrastructure

• Azure Kubernetes Service (AKS): Application workloads run on managed Kubernetes in the US East 2 Azure region
• Private container registry: Container images are stored in a private Azure Container Registry
• Azure managed disks: Storage volumes use Azure SSE-256 encryption
• Azure Key Vault: Used for encryption key management in production deployments

API Gateway

• Kong Gateway provides API gateway functionality: TLS termination, CORS policy enforcement, request routing, and API key validation
• Input validation using Zod schema validation at the application layer

Network Architecture

• Application services run within the AKS cluster
• External access is through the Kong API gateway with TLS termination
• Internal service-to-service communication is within the Kubernetes cluster network

Development Practices

• Pull request-based code review: All changes require PR review before merging to main
• Automated CI/CD: GitHub Actions runs build, lint, type checking, and test suites on every PR
• Unit and integration testing: Automated test suites cover API routes, services, repositories, and middleware
• Input validation: All API inputs are validated against Zod schemas before processing
• Dependency management: Package dependencies are managed with pnpm and lockfiles are committed

Compliance Status

Currently Implemented

Planned

Responsible Disclosure

If you discover a security vulnerability, please report it to [email protected]. We take all reports seriously and will respond within 48 hours.

Questions

For security-related questions, contact [email protected].