Your AI Has a Memory Now. Have You Checked What's In It?
AI assistants that persist memory across sessions create a new attack surface most users never audit. Here's the risk shape and the discipline that closes it.
Most people who use AI coding assistants know about the context window. It’s the thing that runs out. You hit a limit, the session compacts or restarts, and whatever the AI was holding in its head gets summarized or lost. That’s the problem everyone talks about.
The problem nobody talks about is the opposite one: the things your AI doesn’t forget.
The quiet write
Modern AI assistants can persist information to disk. Memory files, project notes, session summaries, preference records — the implementations vary, but the shape is the same: the AI decides something is worth remembering, writes it to a file on your machine, and loads it back on the next session. The intent is good. The AI gets better at helping you over time. It remembers your conventions, your project structure, your preferences.
It also remembers things you didn’t ask it to remember, and it writes them to places you probably don’t check.
The memory-file write is an implicit trust decision. When your AI commits a fact to durable storage, it’s crossing a boundary: from ephemeral session context (gone when the window closes) to persistent state (survives restarts, lives on your filesystem, potentially syncs to backups). That boundary should be narrow and audited. In practice, for most users, it is neither.
What accumulates
The dramatic version of this risk is credentials. An API key pasted into a conversation. A database password mentioned in a debugging session. A connection string the AI helpfully “remembers” so you don’t have to type it next time. When any of those end up in a memory file, they’re now sitting in cleartext on your disk, potentially in a cloud-synced directory, surviving long after you’ve rotated the credential itself.
But the broader risk isn’t credentials. It’s context.
Over weeks and months of use, memory files accumulate a surprisingly detailed picture: client names and project details your client might not want summarized. Architectural decisions that reveal competitive strategy. Half-formed opinions the AI absorbs from a frustrated afternoon and later serves back as established fact. Internal team dynamics mentioned in passing. Vendor evaluations. Salary discussions. The kind of information that’s harmless inside a single conversation but becomes a liability when it persists, compounds, and eventually surfaces in a context you didn’t expect.
The AI doesn’t know the difference between “useful project context” and “information that would be embarrassing or damaging if it leaked.” It optimizes for helpfulness. Helpfulness and discretion are not the same axis.
The three surfaces
Memory-file risk expresses through three surfaces, each with different exposure characteristics:
The storage surface. Memory files typically live in cleartext in a known directory on your workstation. Anyone with access to your filesystem — a compromised machine, a shared backup, a synced cloud folder — has access to everything your AI ever decided to remember. Most users have never opened the directory where their AI stores memory files. Most don’t know it exists.
The retrieval surface. Every new session loads the memory files back into context. Information persisted months ago influences today’s responses. A credential remembered in January gets loaded into a session in April, even if it was rotated in February. Stale context is the quieter cousin of leaked context, and it compounds over time because the volume only grows. The AI speaks with confidence based on what it remembers, even when what it remembers is wrong.
The transit surface. Content from memory files bleeds into AI-generated output: messages, commit messages, pull request descriptions, code comments, documentation. Each of these outputs crosses a different trust boundary — some are private, some are team-visible, some are public. The AI doesn’t distinguish between them when deciding what context to surface. A fact in memory is a fact available everywhere the AI speaks.
The discipline shape
The fix isn’t “don’t use memory files.” Persistent context is genuinely valuable, and disabling it wholesale trades one problem (accumulation risk) for another (context loss). The fix is a discipline with three parts:
Narrow the default. Not everything belongs in durable memory. Credentials, connection strings, and access tokens should never be stored inline — if the AI needs to reference them, it should store a pointer (“the database password is in the project’s .env file”) rather than a value. And even read-only credentials are not fully safe to store: what they can access is itself information about your infrastructure, and their naming conventions and format can leak patterns that inform guessing at their write-scope siblings. Client-sensitive context should be stored with the same discretion you’d apply to an email: would you be comfortable if this sentence appeared in a breach report?
Verify at the boundary. Before the AI commits something to memory, the write should pass through a filter — a DLP pattern scan, a category check, a sensitivity classifier. The same discipline applies to memory-file content entering generated output: scan before the boundary crossing, not after. This is the same principle that makes pre-commit hooks more useful than post-commit audits. Catching the problem at the crossing is cheaper than catching it downstream.
Audit periodically. Open the directory where your AI stores its memory files. Read them. You will almost certainly find things you didn’t know were there, and some of them will be things you’d rather weren’t. The audit isn’t a one-time exercise — memory files grow with use, and the most sensitive information tends to arrive in the least expected sessions. A quarterly review of what your AI has accumulated is the minimum; monthly is better if you work with sensitive client data.
The quiet risk
The reason this risk stays quiet is that memory files work exactly as designed. Your AI is being helpful. It’s remembering things so you don’t have to repeat them. The problem isn’t a bug — it’s an unaudited trust boundary, and the failure mode is silent accumulation rather than dramatic breach. By the time you notice, the surface area is already large.
A trusted default from a parent layer should be narrowed before it crosses a boundary. The boundary needs narrowing at the policy level, verification at the crossing, and periodic audit. Skip any of the three and the accumulation becomes invisible.
Your AI has a memory now. The question isn’t whether it’s remembering things about you. It’s whether you’ve checked what those things are.
— Terminal-IDE