Skip to content
Memtru
Demo mode. These are captured runs of the real scenarios against a deliberately broken store and a fixed one. All data is synthetic.

Cross-user memory returned outside authorized scope

highConfirmed exposure or modification across a user boundary, or data retrievable after deletion.

Another user retrieved a memory outside its authorized scope.

Expected

Memory written by user-a is never returned to user-b in the same tenant.

Observed

user-a's fixture was returned to tenant-a/user-b via search; tenant-a/user-b via read by id.

Evidence

Steps recorded by the CLI for MT-ISO-001 v1.0.0. Fixture content is shown as a fingerprint; actors are synthetic principals created for this run.

Evidence steps
#ActionActorDetailOutcome
1writetenant-a/user-auser-scoped fixture sha256:ee069031e20cstored as mem_000001
2searchtenant-a/user-aquery sha256:d36ae9018aef1 result(s); fixture present
3assert-positive controlheld
4read_by_idtenant-a/user-amem_000001returned fixture
5assert-positive controlheld
6searchtenant-a/user-bquery sha256:d36ae9018aef1 result(s); fixture present
7read_by_idtenant-a/user-bmem_000001returned fixture

Reproduction

  1. Write a record containing a unique marker as user A.
  2. Confirm user A can retrieve it (positive control).
  3. Search for the marker as user B in the same tenant.
  4. If read by id is supported, request user A's record id as user B.
Re-run from your configured sandbox
memtru test --scenario MT-ISO-001

Potential causes

Hypotheses to investigate. None of these is confirmed by the test.

  • hypothesisThe search query filters by tenant (or nothing) but not by user.
  • hypothesisA cache or vector index is shared across users without a user filter.
  • hypothesisRead by id checks existence but not ownership (IDOR).

Suggested remediation

  • Filter every read path by the authenticated user id on the server, not by a client-supplied parameter.
  • Apply the same scoping to direct lookups by id; an id is not an authorization token.
  • Add this scenario to CI so the boundary is re-checked on every change.

Limitations

  • Only the search and read-by-id surfaces exposed by the adapter were exercised.
  • Semantic retrieval with other queries may behave differently from exact markers.

Identifiers

finding
MTF-90f147e3-ISO-001
fingerprint
MT-ISO-001:cross_user_exposure:7088973826a1
category
user_isolation
detected
22 Oct 2026, 06:35 UTC

What fixed it

Restoring the user filter on search and read by id. The same scenario then passes, and no other scenario changed. See the comparison