Long-term memory is the feature every coding assistant is racing to ship. Tell it once how your team likes things done, and it remembers next time instead of relearning from scratch. On GitHub, phrases like "please remember that I prefer..." appear more than 122,000 times, proof that developers routinely hand assistants throwaway instructions, no attacker required.
Researchers planted one insecure habit, something like "skip certificate verification, it's just for testing," into several widely used assistants' memory, then had each write code for unrelated tasks later. The bad habit followed it everywhere. The share of generated code with a security flaw rose across every assistant and language tested, by as much as fifty percentage points in the worst case, and models normally careful about encryption and certificates started slipping in exactly those spots.
More unsettling is how quietly it happens. The same instruction given as a one-off remark tends to get flagged. Stored as memory, the assistant mostly stops mentioning it was ever the reason. Fewer than 1 in 10 outputs said so, even as the code got measurably less safe.
"This indicates that even when insecure memory is provided, LLMs rarely disclose the influence of memory in their outputs."
It's also stubborn once lodged. Telling the assistant a corrected preference doesn't erase the old one. It gets filed as a competing instruction that keeps winning. Only a flat contradiction overrode it, and only for one of two systems tested; the other kept both instead. Padding the memory bank with harmless, unrelated preferences didn't dilute the bad one either.
"Stored memories are difficult to overwrite through normal interactions, and variations in prompt phrasing do not affect their retrieval."
Two fixes were tested. Reminding the assistant to code securely cut the flaw rate substantially, but the fix meant to make code safer also broke code that used to work, by as much as 16 points in one case, because the assistant refused a legitimate install over a rule nobody asked it to enforce. Screening every candidate memory before storage worked cleanly, catching 100% of the planted habits at no cost to working code.
For an engineering leader, this is less about any one bad instruction than about where trust currently sits. Code review catches what's visible in a diff; it can't catch a standing instruction quietly shaping every future diff without ever saying so. A team whose assistant looks clean this week has no way to know whether that's durable judgment or the residue of something an engineer told it months ago and forgot. That is hard to audit precisely because the influence is invisible by design, which is the catch in any vendor pitch that markets a memory feature as a pure convenience win. A reasonable ask of that feature is some way to see what's been remembered and clear it out, the way a team would rotate a credential rather than trust it forever. The reflexive fix, telling the assistant to be more careful, deserves the same scrutiny as the original problem. This study's own numbers show "be more secure" can silently break working code, so it needs testing for what it costs, not just credit for what it prevents.
Sources
- Chen, Y., Cheng, W., Xiao, Y. et al., "Insecure Coding Preferences in Long-Term Memory: Security Risks for LLM-based Code Generation" — https://arxiv.org/abs/2607.17619