Security

Access control and accountability, built in

Every key, every role, and every administrative action is accounted for — enforced on the server, not just hidden in the interface.

Key management

Every API key memtrunk issues is shown once, in full, at the moment it's created. From then on, it's stored and displayed hashed and prefixed only — never logged, and never re-displayed in the clear.

Authentication

Sign-in runs through Google OAuth by default, with an optional restriction to your own email domain, and a trusted-IP allowlist can add another gate on top. Sessions are handled with cookie-based sessions rather than tokens sitting in client-side code. For a trusted local or self-hosted setup, memtrunk can also run with authentication turned off entirely — a deliberate opt-in for a single-operator environment.

Role-based access control

Every account has a role — member, org admin, master admin, or a read-only auditor — and what that role can actually do is enforced on the server, not just hidden behind a disabled button. A read-only auditor can reach every admin screen without ever being able to change something through it.

Audit trail

Every administrative action — who did it, what changed, and when — lands in an audit trail that can't be edited or deleted after the fact. Nothing an admin does goes unrecorded.

Data handling

Application code never talks to the database directly. Every read and write goes through a single, consistent API layer.

Memory & data isolation

Memory's index is built entirely on-device — embedding and reranking run within your own deployment's infrastructure, never a third-party API — with zero data egress and no LLM calls involved in indexing. The resulting memory records persist centrally in that same deployment, not on any single device, so they carry over across your sessions. Recall is scoped strictly per user by default, with no way to even detect whether another user has a matching memory, let alone read it — unless you and a teammate both opt the same project into a shared pool, which neither of you gets into without choosing to. A dedicated defense also keeps a turn's own text from ever influencing how that same turn gets classified or promoted — provenance is decided in code, never parsed out of the prompt.

Org & team isolation

Users, keys, and quotas are grouped by organization and team, so access and visibility stay scoped to where someone actually belongs — from a single admin managing everything, up through org-scoped admins who see only their own organization.

Have a security question?

Talk to us about your deployment, your review process, or anything else you need to know before you commit.

Talk to us