Claude's Memory Tool Replays Everything You Store. Never Put Secrets In It.

Claude has two memory systems, and they fail differently

Anthropic ships two unrelated things both called memory. The first is the memory tool (memory_20250818), a client-side tool for direct API use: Claude automatically checks its memory directory before starting a task, and as it works, it stores what it learns in files under /memories and reads them back in later conversations. Your application owns the storage; Claude only issues read, write, and delete commands against a path prefix you define.

The second is the managed-agents memory store, part of Anthropic's hosted agent platform. A memory store is a workspace-scoped collection of small text documents that persists across sessions, and when it's attached to a session it is mounted into the container as a filesystem directory, with the agent reading and writing it through its ordinary file tools. Every change produces an immutable memory version, giving an audit trail and point-in-time recovery for everything the agent writes.

Both systems solve the same problem — sessions are ephemeral by default, so anything learned in one disappears when it ends, unless it was written to a store that outlives the session. The difference that matters for security is where the validation responsibility sits: on the memory tool, it sits entirely with your handler; on managed-agent memory stores, Anthropic enforces path containment, but you still decide what goes into the files.

Sources: Memory tool - Claude Platform Docs, Using agent memory - Claude Platform Docs, skills/skills/claude-api/shared/managed-agents-memory.md at main · anthropics/skills · GitHub.

A secret written once comes back in every later session

Anthropic's own documentation for managed-agent memory stores carries a direct warning: never store credentials, API keys, or tokens in memory stores, because memories persist across sessions and are returned verbatim into future contexts — a key written once is replayed into every later session that mounts the store. That's not a theoretical risk. It describes the normal, working behavior of the feature. The whole point of a memory store is that its contents get fed back into the model's context on every subsequent session that attaches it, unmodified.

This matters because a bot that writes a note like "API key for the invoicing tool: sk-..." to memory isn't just risking one leaked session transcript. It is guaranteeing that key gets reprinted into every future session's context for as long as the memory exists, including sessions run by other team members, other agents sharing the store, or anyone who later exports or audits the memory contents through the console or API.

Anthropic's fix is procedural, not just advisory: use vault environment_variable credentials instead, which inject secrets at the network layer rather than storing them as readable text the model can see. Vault credentials of this type are stored keyed by a secret name and substituted with the real value only at the moment of an outbound request — the agent never sees the plaintext. If a secret has already been written to memory, the documented remedy is to delete the memory and redact the affected versions, not just delete the current file.

Sources: skills/skills/claude-api/shared/managed-agents-memory.md at main · anthropics/skills · GitHub.

Deleting the memory doesn't erase the version history

Because every mutation creates an immutable memory version, simply overwriting or deleting the live memory leaves the secret sitting in a prior version that the audit trail still holds. Anthropic's managed-agents memory documentation describes a dedicated redact operation for this: it scrubs content, its hash, its size, and its path from a historical version while preserving the audit trail — the actor and timestamps stay, so you can still see that a write happened and who made it, without the leaked content being retrievable.

There's a procedural wrinkle worth planning for before you need it: a version that is the current head of a live memory cannot be redacted directly — you write a new version first, or delete the memory, and redact the old version afterward. If your incident-response plan assumes "delete the memory" is the end of the cleanup, test the redact call ahead of time rather than during an actual leak.

Sources: Using agent memory - Claude Platform Docs, skills/skills/claude-api/shared/managed-agents-memory.md at main · anthropics/skills · GitHub.

The memory tool's other failure mode: paths your handler trusts

Separate from what gets stored, the client-side memory tool has a structural risk: the model sends a path string, and your handler decides what that path maps to on real storage. Anthropic's documentation is explicit that this is the implementer's job — your handler must reject paths outside /memories, and because the memory tool is client-side, Claude only requests memory operations; your application runs each request against storage you control.

The documented attack shape is a path like /memories/../../secrets.env, which can reach files outside the /memories directory if your handler does a naive prefix check instead of resolving the path to its canonical form. Anthropic's safeguards for this are concrete: validate that paths start with /memories, resolve to canonical form and confirm the result is still inside the memory root, reject ../ and ..\ sequences and their URL-encoded forms, and use your language's built-in path-resolution utilities rather than string matching.

This is a different failure from the credential-replay problem above, but it compounds with it: a handler that doesn't canonicalize paths and a bot that writes secrets into memory together mean a crafted path could both read a stored secret and potentially reach storage the memory tool was never meant to touch.

Sources: Memory tool - Claude Platform Docs.

Illustrative example: a scheduling bot's memory file

Say a small team builds a bot that manages meeting scheduling and uses the memory tool to remember each person's calendar preferences — "prefers afternoons," "never Fridays." That's a reasonable use: low-sensitivity, genuinely useful across sessions, and not the kind of thing that needs a vault. The failure case shows up when the same bot also needs a one-off API token to reach a calendar provider during setup, and a developer, debugging a connection problem, lets Claude write "calendar token: xyz123" into the same /memories/notes.md file so it "remembers" the fix.

From that point, every future session that loads notes.md gets the token reprinted into context, whether or not that session needs it. If the file is ever shared, exported for debugging, or read by a second bot that mounts the same store, the token goes with it. The practical decision: keep a short written rule for what's allowed in memory files — preferences, summaries, and task state, never credentials or tokens — and route actual secrets through vault credentials or your own secrets manager, injected at call time rather than written into a file the model can read back.

What to check before you turn memory on

Before enabling either memory system for a bot, confirm three things. First, decide explicitly what categories of information are allowed into memory files — write it down, since the model won't know your boundary unless the system prompt states it. Second, if you're implementing the client-side memory tool yourself, verify your handler resolves paths to canonical form and rejects anything outside /memories before it touches storage; don't rely on a string prefix check. Third, if you're using managed-agent memory stores and a secret does get written, know the redact workflow in advance — delete or overwrite the live memory, then redact the specific version, rather than assuming deletion alone clears the history.

Sources: Memory tool - Claude Platform Docs, Using agent memory - Claude Platform Docs.