Your memory. Your rules. Provably.
Memuron is built so access decisions sit with you, not with us. Every space is scoped to its owner, every boundary is enforced at the store, and every change to the memory is written to an append-only ledger you can replay.
Ownership isn't a policy. It's a control.
Most memory layers describe data protection as something the vendor does for you — encryption at rest, access logs, a privacy policy. Memuron is built so ownership is something you configure, not something you're promised.
Tenant boundaries are enforced at the storage layer, not just the API layer. Spaces are explicit, inspectable scopes rather than inherited defaults. And because every change to a memory is an append-only event, you can reconstruct not just what your organization knew, but when that changed and what it replaced.
We don't hold implicit access to your memory. You scope it, you decide where it runs, and the ledger can prove what happened to it.
Four levers, all yours.
None of these are settings we apply on your behalf. They are boundaries you define and can inspect at any time.
Tenant boundaries
Hard tenant_id isolation on every read and write. One tenant's memory is never retrievable in another tenant's context — not filtered out after the fact, structurally unreachable.
Space-level scoping
Segment memory by app, team, or end-user. Each space is a bounded subgraph with its own Guardian prompt and enable controls — nothing crosses a space unless you place it there.
An append-only record
Creates, corrections, links, and placements are typed events in an append-only ledger. Nothing is silently overwritten, so what your organization knew — and when it changed — is replayable.
Deployment sovereignty
Choose where the graph and the ledger physically live: our infrastructure, your cloud under your account, or fully air-gapped. The architecture is the same at every option.
Access control is structural, not procedural.
A permissions table a support engineer can override on request isn't ownership — it's a policy with an exception path. Memuron's isolation is enforced the same way its memory integrity is: at write time, structurally, with a record.
- Storage-level isolationTenant boundaries are enforced where the data lives, not only at the API gateway. A scoped query cannot widen its own scope.
- No standing vendor accessWe do not read tenant memory as a matter of course. Support access is explicit, initiated by you, and time-bound — and on self-hosted deployments it is not ours to have.
- Every write is an eventMemory changes are typed ledger entries (memory.created, memory.updated, link.created, placement.created) — replayable in order, not reconstructed from logs after the fact.
- Provable, not just claimedBecause the trail lives in the ledger rather than in an application log, "what changed, and when" is a query against your own data — not a support ticket to us.
Sovereignty extends to deployment.
Wherever Memuron runs — our infrastructure, your VPC under your account, or fully air-gapped — the same tenant isolation, scoping model, and append-only ledger apply. Ownership isn't a feature of the hosted tier; it's the same architecture at every deployment option.
What we're building next.
Everything above describes what ships today. These two do not — they are on the Enterprise roadmap. If either is a requirement for your evaluation, tell your enterprise architect: it shapes deployment sequencing.
Customer-managed keys (CMEK)
Scoping determines who can ask. Customer-managed encryption keys determine who can ever read the bytes — a stronger guarantee we are building toward for Enterprise deployments.
Access grants as ledger events
Today the ledger records what happened to your memory. Recording permission changes themselves as typed, replayable events — granted, revoked, rescoped — is the next step in that trail.
Review your access model with us before you commit.
An enterprise architecture review covers tenant isolation, space design, retention, and deployment sovereignty — mapped to your organization's actual governance requirements, not a generic checklist.