Loading today’s stories
Build1 distinct publisher3 min readUpdated
A read-only sensor for cross-tenant memory leaks ships with no tagged release, because its own backend cannot enumerate what the retriever exposed. That limitation is the story.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
A developer has published CrossSessionMemoryGuard, a read-only sensor that watches the chunks an agent's memory engine hands to one principal and asks whether another principal wrote them [s1c1]. It matters because persistent agent memory is currently defended almost entirely on the write side, against poisoning and manipulation, while the prior question -- should this data leave towards this principal -- goes largely unmonitored [s1c2][s1c3].
The post cites recent work it identifies as arXiv 2607.23444, "Isolated but Exposed: Persistence-Based Memory Extraction Attack on LLM Agents", as a practical demonstration against agents that are isolated per session [s1c4]. The distinction the project draws is the useful one: session isolation is not data isolation, and if the retrieval engine crosses tenants through a broken filter, an aggressive consolidation, or a relabeling, one session can silently read what another wrote [s1c5]. Nothing in an integrity check on the write path is looking at that.
As evidence that the read side is uncovered, the author reports that a GitHub repository search using the five exact terms describing the problem returns zero results, while control searches return 4,632 repos for "agent persistent memory" and 435 for topic:llm-memory [s1c6][s1c7]. The raw JSON from those calls is versioned in the repo as github_gap_2026-08-17.txt rather than asserted in prose [s1c8]. Adjacent projects the author names -- OWASP Agent Memory Guard, memlineage, dent8 -- are described as covering write-side integrity and poisoning [s1c9].
The design is deliberately unambitious in scope: it observes, compares and alerts, never blocks, modifies or participates in authorization, sits outside the critical path, fails open, and carries a kill-switch via CSMG_DISABLED=1 [s1c10][s1c11]. Events carry a SHA-256 hash plus a minimal span, not the content [s1c12]. Attribution of who wrote what is taken from the schema layer, never from the observed view, because a retriever that crosses tenants must not be trusted to relabel ownership; the author says that contamination produced mass false positives in the benchmark, logged as KI-8 [s1c13].
The honest part is why there is no tagged release yet [s1c14]. The Engram adapter reads the schema layer rather than the real search path because the author verified that engram search cannot list everything visible: an empty query errors with "search query is required", wildcards and FTS escapes return zero results, and there is a hard cap of 20 results per query that persists at --limit 1000 and --limit 5000, against a default of 10 [s1c15][s1c16]. Coverage therefore becomes a function of the query set: 15 broad queries covered 87.9% of real observations, 80 of 91, 23 queries reached 96.7%, and 100% arrived only with queries tailored to the rows that were missing [s1c17]. At 15 queries, 11 of 91 observations were invisible [s1d1]. An independent audit reproduced the cap with the engine's official binary and 30 test observations: 30 stored, 20 returned, two thirds of what was there [s1c18][s1d2].
That is the structural point for anyone building read-side monitoring. If your ground truth for what the engine exposed is itself a set of queries, a leak nobody thought to query for does not exist. The author also flags that mem0, langmem, zep and letta implement the real read but not schema_chunks(), so a broken tenant filter in those adapters would contaminate attribution the way bug t1 did in the SQLite and JSONL paths before it was fixed [s1c19], and that composite collusion cases -- fragments of a secret each below the similarity threshold, scenario t4 -- are not detected in the MVP and are reported as declared limitation AC7 rather than a pass [s1c20].
Watch whether external adapters get a schema layer of their own, and whether memory engines start shipping an enumeration path that a monitor can trust.
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
Session isolation is not the same as data isolation: if the retrieval engine crosses tenants (a broken filter, an aggressive consolidation, a relabeling), one session can silently read what another wrote.
Engram search has a hard cap of 20 results per query: --limit 1000 and even --limit 5000 still return 20, with a default of 10.
An independent audit reproduced the 20-result cap using the engine's official binary and 30 of its own test observations: 30 were stored and the engine returned 20; the evidence is in engram_search_spike_2026-08-17.txt.
Known issue KI-11: the external adapters mem0, langmem, zep and letta implement the real read but not schema_chunks() (the true attribution layer), so if their tenant filter were broken, attribution and references would be contaminated as in bug t1 already fixed in the SQLite and JSONL backends; this is declared future work.
CrossSessionMemoryGuard is a read-only sensor that detects unauthorized cross-session memory flow using three signals (provenance, content, and a write/read graph) over the chunks the engine exposes to a principal, never blocks anything, and documents its own limitations with versioned raw evidence in the repo.
By the repo's own constitution the tool is read-only by design: it observes, compares and alerts, and never blocks, modifies or participates in authorization.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Unusually detailed self-reported measurement, single unreviewed source
The cluster contains one self-published post by the project's own author. Within that constraint the evidentiary discipline is high: pre-declared thresholds, seeded benchmark runs, named known-issue identifiers, false positives reported rather than hidden, and raw evidence files versioned in-repo. But none of those artifacts are supplied in the cluster, no second publisher covers the work, the cited arXiv paper cannot be checked from anything given, and the reported independent audit is itself relayed by the author. That caps evidence below the midpoint despite the rigour of the write-up.
Pre-release, author dogfooding only
Every adoption signal in the cluster is negative or internal: no tagged release, evaluation only on a synthetic 3-tenant fixture, the memory engine used is the author's own dogfooding target, and the four external adapters (mem0, langmem, zep, letta) are explicitly incomplete because they lack schema_chunks(). The post's closing ask is for a first production multi-tenant case, which confirms none exists yet. No stars, installs, downstream users or third-party deployments are disclosed anywhere in the supplied material, so the score reflects a documented near-zero rather than an unknown.
Capability claims run behind disclosed limits; one over-reached novelty proxy
Negative because the post systematically de-hypes its own tool: it withholds a tagged release over a backend limitation, publishes a real false-positive rate, marks composite collusion as an undetected limitation instead of a pass, and states that coverage depends on already knowing what to look for. Nothing in the capability description exceeds what is measured. The offsetting overstatement is the ecosystem framing: 'almost nobody monitors this' and the write-side-only classification of adjacent projects rest on a five-term keyword search returning zero results, which is a weak proxy for absence and pulls the score back toward zero.
Author-promoted pre-release project on a self-publish platform
The post is written by the project's maintainer, published on a developer self-publishing platform with no editorial gate, and closes with explicit contributor recruitment and repository links, so there is a clear promotional interest in the problem being framed as unserved. The keyword-gap section and the classification of adjacent projects as write-side only both serve that interest. Countervailing signals are real and unusual: the same author leads with unresolved known issues, withholds a release, and publishes measured false positives, which cuts against pure promotion. No vendor funding, sponsorship, commercial product or paid relationship is disclosed anywhere in the cluster.
Internally consistent but single-sourced and unreplicated
Confidence is limited structurally rather than by sloppiness: one publisher, one author, no independent replication in the cluster, and the two external anchors (the arXiv paper and the audit) are both relayed rather than shown. The technical claims about the tool's own design and its backend's behaviour are specific, numerically consistent and self-limiting, which supports moderate confidence in the engineering findings; the ecosystem and novelty claims deserve materially less. The near-zero adoption is well established, so confidence in the maturity assessment is higher than confidence in the significance assessment.
build
LoreKit puts agent memory in Markdown files you can grep, not a vendor's database1 distinct publisher
build
Microsoft ships an MIT-licensed agent kernel: policy rings, Ed25519 identity, kill switch1 distinct publisher
build
The retry loop is a memory bug: a gatekeeper that checks failures before it calls the tool1 distinct publisher
build
The agent asks, the gateway decides: why read-only is not a security boundary1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 17, 2026