Trust · last updated 2026-05-17

Security at MemHQ

The controls in place today, the wedges built into the storage layer, and how to report a vulnerability. This is a beta-period overview; the SOC 2 Type I report will land in 2026 Q4.

At a glance

TLS everywhere. Encryption at rest. Clerk-managed auth. Storage-layer ACLs that the app code can't bypass. A verifiable audit chain. SOC 2 Type I in progress.

Encryption

  • In transit: TLS 1.2+ for every connection to the API, dashboard, and managed Postgres. HSTS preload on memhq.ai.
  • At rest: AWS-managed disk encryption (AES-256) on every Postgres volume and backup snapshot. Object storage (used for uploaded files) is encrypted with SSE-S3.
  • Key management: AWS KMS, customer-managed keys available on Enterprise.

Authentication

End-user auth is handled by Clerk — email + password, magic link, and SSO via SAML or OIDC. We never see your password. API access uses Bearer tokens scoped to a single project; tokens can be rotated from the dashboard at any time.

Authorization — the storage-layer wedge

Most memory stacks check permissions in app code. We push the check into the database: every read passes through a predicate that intersects the caller's principal set with graph_acls. App bugs can't override the storage layer. See the RBAC docs for the model.

Isolation

  • Per-project: every row in the database carries a projectId. Cross-project reads are impossible — the queries don't exist.
  • Per-org: projects are owned by an organization; users in an org can be scoped to a subset of projects.
  • Per-graph: ACL grants are at the graph level (user graph or named group graph).

Audit chain

Every state-changing action — memory create, supersession, ACL grant, ontology bump, user delete — appends a SHA-256-chained row to the audit log. POST /v1/audit/verify recomputes the chain end-to-end. Tampering is detectable, not preventable; on Enterprise we additionally pin the chain head to a customer-controlled object store on a weekly cadence.

Operational practices

  • Daily Postgres backups, 30-day point-in-time recovery, restore drills quarterly.
  • Application servers are immutable; deploys are atomic blue/green.
  • Production access is restricted to two engineers, MFA enforced, just-in-time elevation logged.
  • Dependency vulnerabilities are tracked via Dependabot + weekly review; critical fixes ship within 48 hours.
  • Background workers run with the same isolation boundary as the API — no shared mutable state across projects.

Compliance posture

  • SOC 2 Type I: in progress, target 2026 Q4 report.
  • GDPR / CCPA: data export + delete endpoints today, DPA available on Pro and above.
  • HIPAA: not certified; do not send PHI to the Service. Talk to us if HIPAA handling is on your near-term roadmap — we are scoping a compliant offering.

Responsible disclosure

Found a vulnerability? Email [email protected]. We respond within 48 hours. Please don't disclose publicly until we've had a chance to fix and notify affected customers. We don't run a paid bounty program yet — we do publicly credit reporters in our changelog and the next time we do, we'll backfill bounties to everyone who reported during the beta.

Subprocessors

The third-party processors that handle your data are listed in the Privacy Policy. We notify Pro+ customers 30 days before adding a new processor.