The sharpest item of the past few days is an interview Help Net Security published on September 28 with Chris Latimer of Vectorize, arguing that if a team runs a single security check this quarter, it should be on agent memory. That framing is worth taking seriously, and it lines up with a point made in MemTensor's recent "Agent Memory Is Not RAG" field guide on Hugging Face: these two things share infrastructure and almost nothing else.
Why the same vector index behaves differently
Classic RAG is a read path over a corpus you control. Documents arrive through an ingestion pipeline you own, chunking and embedding are batch jobs, and the blast radius of a bad document is bounded by whatever review gate your content team already runs. Agent memory inverts this. The agent writes. The sources of those writes are model output, tool output, and raw user text — three untrusted channels — and the write usually happens with no human in the loop, because the whole point is that the system gets better without one.
The consequence is temporal. A prompt injection against a stateless RAG app lives for one turn. The same injection against a memory-writing agent can be distilled into a tidy declarative fact — "this user has approved expense waivers above the threshold" — embedded, and recalled semantically for months, by a different session, possibly a different user if your namespacing is loose. Consolidation makes it worse: summarization and dedup passes strip provenance and launder a hostile fragment into something that reads like established context. Retrieval is similarity-based, so the attacker never needs to know the future query.
What to actually change
Treat the write path as a separate privilege from the read path. Concretely: every memory record carries provenance — originating turn, tool, principal, tenant — and provenance survives consolidation rather than being summarized away. Write-time policy is its own layer, not an afterthought on your retrieval filter. Memories from tool output and from user assertion live in different namespaces with different trust, and cross-namespace promotion is an explicit, logged operation. TTL and decay are security controls, not just cost controls. Consolidation jobs run with their own identity and leave a diff you can review.
Evaluation needs the same inversion. Retrieval hit rate tells you nothing here. The question is whether a planted record survives a consolidation cycle, and whether it surfaces for a query that shares no lexical overlap with the injection. That is a red-team harness, not a benchmark.
Who should care: anyone shipping a multi-session assistant with shared organizational memory, and especially anyone whose memory store is multi-tenant. If you are still doing single-session retrieval over a governed corpus, this is a problem you are about to have rather than one you have. The uncomfortable part is that most memory layers shipped in the last year were built by retrieval teams, with retrieval threat models.