Contents7
At a glance
In thirty seconds- StakeAgents sharing a memory must not read what another scope entrusted to theirs, and a prompt instruction cannot prevent it.
- MechanismThe application checks each actor’s scope before any Cypher query, and the Memgraph database enforces distinct roles from initialisation.
- ProofThe public code of the session-ux branch: access rules, unit tests and end-to-end tests against a real Memgraph database.
- ImpactShared knowledge that does not leak from one scope to another: the starting condition for agents that remember.
- LimitsIsolation is per agent; per-client scopes and offensive tests remain to be done.
- Client
- MC Studio, research and development
- My role
- Designer and sole developer of the feature
- Setting
- Internal project
- Team
- Solo · 1 person
- Technologies
TypeScript
Docker- Memgraph
- Cypher
- Vitest
The starting point
As soon as several agents work together, they need memory: what was decided, what was learned, what remains to be done. A shared memory immediately raises another question. If an agent works for a person, a team or a client, it must not be able to read what the others entrusted to theirs. Asking the model “not to look” is not enough.
What I built
On a fork of OpenClaw, an open-source agent project1, I added a graph memory hosted on Memgraph, run in a container. Each actor gets a scope: an agent reads and writes in its own, the operator has an administration scope. Before every query, the application checks that the requested scope is the actor’s own, and refuses otherwise.
OpenClaw is a third-party open-source project…
OpenClaw is a third-party open-source project. Only the partitioned memory feature of this branch is mine, developed alone in February 2026.
The database applies the same logic on its side: distinct roles for administration, agents and teams, created at initialisation with their own users. If a query slipped past the first check by mistake, it would hit the second. Agents and administrators each have a skill that describes how to use the memory.
What the evidence shows
The access rules are covered by unit tests: an agent reaches its own scope and is refused another’s. End-to-end tests run against a real Memgraph database, to check that the whole holds up outside mocks2. The code is public and can be read on the branch3.
Vitest unit tests on the access…
Vitest unit tests on the access rules; end-to-end tests launched by a dedicated script and configuration, against Memgraph in a container.
My presentation of this work also…
My presentation of this work also mentions audit logs and answers that cite their sources. I have not checked them in the branch yet, so I do not claim them here.
What it changes
For an organisation that wants agents able to remember, this is the starting condition: shared knowledge that does not leak from one scope to another. The same logic, extended to clients or engagements, would keep an agent from using in one file what it learned in another. That is the direction I propose when an organisation wants agents that remember, without mixing files.
Limits
It is a personal demonstrator: it establishes the mechanism, with no external user, and I claim only what the code shows.
- Extending it to per-client or per-engagement scopes is a direction, not a delivery.
- Offensive security tests, prompt injection and cross-scope exfiltration attempts, are planned but not done yet.
- It is a fork branch, not offered to the upstream project.
Share and reuse
The link, the plain text and visuals ready for LinkedIn.
