Demo finding · Memtru

criticalConfirmed exposure of data across a tenant boundary.

A principal in another tenant retrieved tenant A's memory.

Expected

Memory written in tenant A is never returned to any principal in tenant B.

Observed

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

Evidence

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

Evidence steps
#	Action	Actor	Detail	Outcome
1	write	tenant-a/user-1	user-scoped fixture sha256:913a1d7b94b8	stored as mem_000002
2	search	tenant-a/user-1	query sha256:a65a1b90a506	1 result(s); fixture present
3	assert	-	positive control	held
4	read_by_id	tenant-a/user-1	mem_000002	returned fixture
5	assert	-	positive control	held
6	search	tenant-b/user-1	query sha256:a65a1b90a506	1 result(s); fixture present
7	read_by_id	tenant-b/user-1	mem_000002	returned fixture
8	search	tenant-b/user-2	query sha256:a65a1b90a506	0 result(s); fixture absent
9	read_by_id	tenant-b/user-2	mem_000002	not found

Write a record containing a unique marker as user-1 in tenant A.
Confirm user-1 in tenant A can retrieve it (positive control).
Search for the marker as user-1 in tenant B (same user id, different tenant).
Search for the marker as user-2 in tenant B.
If read by id is supported, request the record id from both tenant B principals.

Re-run from your configured sandbox

memtru test --scenario MT-TEN-002

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

hypothesisRecords are keyed by user id alone, so equal user ids collide across tenants.
hypothesisThe tenant filter is applied as optional metadata the caller controls.

Derive the tenant from the authenticated session or credential, never from request input, and include it in every query.
Treat user ids as unique only within a tenant; key memory by (tenant, user).
Enforce tenancy at the storage layer (row-level security, per-tenant indexes or namespaces) so a missed application filter cannot leak data.

The scenario exercises tenancy through the adapter's context mapping. If the adapter passes tenant as a caller-controlled filter, a PASS shows only that the filter works for this client path, not that the service enforces it.
Only the search and read-by-id surfaces exposed by the adapter were exercised.