Skip to content
Memtru
Documentation menu
Getting started

Concepts

Memory isolation

An agent's memory store holds facts about users. Isolation means a fact written for one principal is never returned to another principal unless the system's documented sharing rules allow it. Memtru checks three boundaries:

  • User: two users in the same tenant (MT-ISO-001)
  • Tenant: two tenants, including principals with identical user ids (MT-TEN-002)
  • Session: session-scoped memory across sessions of the same user (MT-SES-005)

Test scope

A scenario tests what the adapter exposes. If the adapter offers search and read by id, both are probed; if it offers only search, only search is probed and the result says so. Results never claim more coverage than was executed.

Storage mode tests the memory service directly through an adapter. Agent mode tests behaviour visible through the agent itself and needs an adapter that can run the agent (AGENT_RESPOND). Passing storage tests do not imply the agent behaves correctly, and the reports keep the two modes separate.

Positive controls

A missing result is only evidence if the authorized path would have found it. Every isolation, deletion and update scenario first proves that the owner can retrieve the fixture. If that fails, the result is INCONCLUSIVE, never PASS. A store that returns nothing at all produces INCONCLUSIVE for every scenario.

Scenarios

A scenario has a unique id (MT-ISO-001), a version, required capabilities, synthetic fixtures, assertions, a timeout and retry policy, and cleanup. See Scenarios.

Adapters

An adapter translates Memtru operations (add, search, read, update, delete) into calls on your system and declares its capabilities. See Adapters.

Findings

A FAIL produces a finding with a severity from a fixed mapping, the expected and observed behaviour, sanitized evidence, reproduction steps, remediation suggestions, hypotheses about the cause (labelled as hypotheses) and limitations. Each finding has a stable fingerprint (scenario:failure-code) so the dashboard can track first and last seen.

Synthetic fixtures

Fixtures are generated per run: unique markers such as mtmarkiso7b9c84a1f3e2d0, principals named mt-<run>-user-a, and a run namespace mt-<run>. No real personal data is used. Reports show fixture content as a SHA-256 fingerprint unless privacy.include_raw_content is enabled.

Cleanup

Every record a scenario writes is tracked in a ledger and deleted with the owner's context afterwards, then the run namespace is released. Cleanup never deletes anything the run did not create. Cleanup failures are reported per scenario with the remaining record ids.

Limitations

See Known limitations. The short version: tests show the behaviour of the surfaces they exercised, under the configured timing, for the synthetic principals they created.