RBAC
Storage-layer role-based access control for per-user and group memory.
RBAC
MemHQ enforces access control at the storage layer, not just in the application. Every read and write checks an access-control list that's attached to the underlying graph, which means a misused API key can't exfiltrate another user's memory by guessing IDs — the database simply refuses the query.
The two access patterns
| Graph kind | Default access | Sharing model |
|---|---|---|
Per-user (user_id) | Only the project key plus that user | A user can be added to one or more group graphs; their own graph is never shared. |
Group (group_id) | Only members of the group | Membership is explicit. Add and remove members via the dashboard or the management API. |
The project key is the system actor — it can read and write any graph in
the project. End-user identity comes from the user_id (and optional
group_ids) you pass on each API call.
How it's enforced
Every memory and edge in the underlying graph carries an ACL row that names the graph it belongs to and the principals authorized to read it. Queries are rewritten at the storage layer to join against the ACL, so:
- A
searchcall withuser_id=Acannot return memories owned byuser_id=B. - A
searchcall against agroup_idreturns only memories the caller is a member of, even if the project key technically has access to the whole project.
This is a hard guarantee, not a convention — the join happens inside the storage engine, not in application code.
Audit log
Every authenticated request — add, search, ask, plus all
dashboard-side reads — is written to an append-only audit log scoped to
the project. The log records:
- Timestamp, correlation ID, principal (project key fingerprint).
- Graph(s) touched (
user_idand/orgroup_id). - Operation kind and result counts.
- IP and user agent.
You can stream the audit log to your SIEM via the
/v1/dashboard/audit endpoint.
The audit log is not user-mutable. If you need to redact a memory for a data-subject request, use the dashboard's Erase memory flow, which writes a tombstone and links it back to the audit entries that produced the data.
SCIM and SSO
For organizations that need provisioning, MemHQ supports SCIM 2.0 for user and group lifecycle, and SAML / OIDC SSO via the dashboard. See the dashboard's Settings → Identity panel.
Coming soon
- Fine-grained per-graph roles (
read,read+write,admin). - Time-bounded access grants for sharing memory across projects.
- Encryption-at-rest with customer-managed keys (CMK).