memory: safer persistence defaults, atomic writes, quotas, redaction, and destructive-operation guardrails

[lcv-leo]

Summary

While auditing and hardening local MCP server usage, I reviewed @modelcontextprotocol/server-memory and built a local hardened wrapper for our environment. I am opening this issue to share findings and possible upstream improvements.

This is not a report about a known data loss incident in the upstream package. It is a defense-in-depth report about persistence defaults and operational safety for a memory tool exposed to autonomous agents.

Package/runtime reviewed

• Package: @modelcontextprotocol/server-memory@2026.1.26
• License observed: MIT
• Author observed: Anthropic, PBC
• Upstream repo/issue tracker: modelcontextprotocol/servers
• npm maintainers observed from registry during local review: jspahrsummers, pcarleton, thedsp, ashwin-ant, ochafik

Findings

1. Default persistence path can land inside the package directory.
   Local source evidence showed a default path based on path.dirname(fileURLToPath(import.meta.url)), with memory.jsonl under the package dist directory when MEMORY_FILE_PATH is not configured. This creates operational fragility:

   • package reinstall/update can remove or overwrite memory state
   • global/package directories are not intuitive user data locations
   • backup/sync behavior is unclear

2. Writes appear to be whole-file writes without explicit atomic replace and lock discipline.
   For agent memory, interrupted writes or concurrent host usage can corrupt or lose state. This is especially relevant when the same memory server is configured across multiple MCP hosts.

3. No obvious mutation journal or backup trail.
   Debugging accidental writes or deletes is hard without append-only audit entries or backup snapshots.

4. Destructive tools are available by default.
   delete_entities, delete_observations, and delete_relations are useful, but high-impact. In an agent context, accidental deletion should require explicit operator opt-in or confirmation mode.

5. No obvious quotas/caps.
   Large observations or graphs can become a memory/latency issue. Whole-graph reads and writes are also sensitive to unbounded growth.

6. No obvious secret redaction before persistence.
   Memory can become a persistent prompt-injection and secret-retention surface if fetched web content, logs, stack traces, or credentials are persisted without sanitization.

7. No namespace isolation by default.
   A single global memory file shared across workspace/host contexts can mix unrelated operational memories unless the user manually configures paths.

Local hardening behavior that worked well

For our local wrapper, we preserved the upstream-compatible 9 tool names:

create_entities, create_relations, add_observations, delete_entities,
delete_observations, delete_relations, read_graph, search_nodes, open_nodes

We added:

• explicit persistence outside node_modules, defaulting to a user data path
• refusal to persist under node_modules
• namespace support for workspace separation
• cross-process lock with stale-lock cleanup
• temp-write plus rename, with backup file
• append-only mutation audit journal
• quotas for entity/relation counts and observation sizes
• secret redaction before writes
• destructive tools disabled unless LCV_MCP_MEMORY_ALLOW_DESTRUCTIVE=1

Validation from local wrapper

Smoke output from the hardened local wrapper:

memory tools: add_observations,create_entities,create_relations,delete_entities,delete_observations,delete_relations,open_nodes,read_graph,search_nodes
memory read_graph entities=0 relations=0

A redaction/destructive-operation check also behaved as intended in local testing:

create {"entities":[{"name":"redaction-proof","entityType":"test","observations":["token [REDACTED]"]}]}
delete [{"type":"text","text":"delete_entities is disabled by default. Set LCV_MCP_MEMORY_ALLOW_DESTRUCTIVE=1 to enable destructive memory mutations."}]

Suggested upstream changes

• Default persistence to an OS/user data directory instead of the installed package directory.
• Refuse or strongly warn when MEMORY_FILE_PATH resolves inside node_modules or another package-managed path.
• Use atomic write/replace and cross-process locking.
• Add backup and append-only mutation audit journal options.
• Add quotas for graph size, entity count, relation count, and observation length.
• Redact common secret patterns before persistence.
• Add namespace support or document recommended per-workspace file paths.
• Gate destructive tools behind an explicit environment flag or confirmation mechanism.

Compatibility note

Most of these can be additive and opt-in, except the safer default persistence path. If changing the default is too disruptive, a migration warning plus documented MEMORY_FILE_PATH recommendation would still help users avoid package-dir persistence.

[policylayer-dan]

The persistence path issue is the most immediately actionable: defaulting to a path inside the package directory means any update silently drops state. That alone warrants an upstream fix regardless of the security angle.

On the destructive-operation guardrails point: approving deletes before they execute and maintaining a tamper-evident audit log of what an agent wrote or erased are concerns that live at the consumer layer, not just the server. Even if the server ships safer defaults, an agent operating under prompt injection could still call destructive operations legitimately from the server's perspective.

The separation that tends to work well in practice: the server handles data integrity (atomic writes, quotas, safe paths), and the calling layer handles operation-level authorisation - specifically, an approval gate before destructive tool calls and an audit log of every call with its arguments. If you're running this server as part of a broader agent stack with tools you didn't build, that calling-layer enforcement is what PolicyLayer covers.

[sophymarine]

Safer persistence defaults are especially valuable in MCP servers that may be embedded into long-lived desktop sessions. Atomic writes plus quotas are a good baseline, but I’d also consider a corruption-recovery path that prefers the last known-good snapshot over a hard failure. That keeps the tool usable after abrupt shutdowns or partial writes. Redaction is the other piece worth testing early: it’s easy for one log path to bypass the sanitizer, so a fixture that asserts both persisted content and emitted logs stay aligned would catch a lot of edge cases.

[lcv-leo]

Thanks for the detailed feedback. I agree with the split: the server should own persistence integrity and safe storage defaults, while the caller/consumer layer is the right place for approval gates around destructive operations.

For the server-side scope of this issue, the immediately actionable pieces remain:

• move durable state out of the package/install directory by default;
• use atomic writes and quotas;
• add redaction coverage for both persisted content and emitted logs;
• add corruption recovery that can prefer a last-known-good snapshot instead of hard-failing after an abrupt shutdown or partial write.

The last-known-good recovery suggestion is especially useful and fits the persistence-integrity part of the report.

[eddyaipt]

Another safety layer that has paid off for us is write provenance on each observation/entity mutation: source host/workspace, tool name, and timestamp stored alongside the data. That makes cleanup and trust decisions much easier later, especially when memory becomes a mix of user facts, fetched web content, and agent-generated notes. Even lightweight provenance fields would make redaction/rollback workflows much more practical.

[chenyuan35]

Well-audited report. The points about default persistence in node_modules, atomic writes, and cross-process locking are particularly relevant — I've seen the same issues with agent memory servers deployed in production.

A design question that I've been thinking about: should the MCP memory server be purely local (file-based, single-host) or should it support a shared/cross-host mode natively? For agent use cases, there's a strong pull toward the latter — same failure pattern gets debugged independently by different agents on different machines.

I built a companion layer that handles the shared cross-agent part: 3 API calls (record failure → search → share fix) with no auth, self-declared agent IDs. The API design deliberately avoids the persistence path problem by being stateless from the client perspective — agents POST failures and get back cached results.

For the MCP memory server specifically, the suggestions I'd double down on:

• Namespace isolation (your point 7) — essential for agent use cases where multiple projects/repos share the same MCP host
• Atomic writes + lock (point 2) — without this, concurrent memory access from parallel agents will corrupt state
• Quotas (point 5) — unbounded memory graph growth is a real token-waste problem

Repo for the cross-agent layer (if useful as reference): https://github.com/anomalyco/aineedhelpfromotherai