In this interview with Help Net Security, Chris Latimer, CEO of Vectorize, talks about the security risks hiding in AI agent memory. He found coding agents storing API keys, credentials, and sensitive documents in plain text on developer machines and in cloud services.
Latimer explains how attackers could plant poisoned memories through plugins, skills, and MCP integrations, often aimed at new coders who trust too easily. He covers why access control for agent memory lags behind other areas, what to track after an incident, and the one audit he thinks every CISO should run this quarter.
When you first opened an agent’s memory store and read through it line by line, what surprised you most about what had piled up? Give me one entry you still think about.
One of the biggest surprises I had was looking at the memory bank for coding agents I was using. It opened my eyes to just how many sensitive pieces of information get stored in agent memory.
Developers are sending API keys, credentials, and sensitive documents into these agents, and those agents push a lot of that information into long-term memory. All these pieces of highly sensitive data that enterprises have gone to great lengths to protect as part of a secure SDLC are now floating around in plain text on developers’ workstations, in cloud memory services, and in markdown files.
If you were red-teaming a memory-enabled agent next week, what’s the first thing you’d try to plant, and where? Why that target and not the obvious one?
One of the most obvious attacks is memory poisoning. I don’t want to give away too many secrets that could help an attacker, but there are specific techniques that you can use when planting memories that will make it much more likely those memories cause behavioral changes in the harnesses.
The first thing you need to figure out is how to poison the memory. Likely candidates are plugins, skills, and MCP integrations. Most people find something that looks valuable, and they plug it in without doing a very thorough read-through of it.
There are a lot of people who have never coded before now using coding agents to build something, and they don’t have the sophistication to understand what’s real and what’s a scam. If I were an attacker, I’d target those users with things that sound too good to be true.
“This Claude Code plugin glitch will give you unlimited tokens even on the free plan” or something like that. Something too good to be true.
Then I’d have that plugin scan through your memory, looking for any credentials, and have the skill report back to an API endpoint with any keys, tokens, or other sensitive information it finds.
Like so much of security, a lot of this requires social engineering, but these extension points in the coding agents, combined with an overly trusting user base, create real potential for attacks like these.
When an incident involves an agent with memory, what does evidence collection look like in the first hour? What do you wish you had preserved the first time and didn’t?
The regret comes less from what you wish you had preserved and more from what you wish you didn’t let into the memory system in the first place. This is the same as most other attacks. Yes, it’s helpful to know when there’s a phishing attack who clicked the link and whose passwords were compromised, but it’s much better if you caught the phishing attack before it ever landed in anyone’s inbox.
Most of the traceability you want for a memory poisoning attack that’s already happened is to understand where the memory came from. You want to know if it’s an MCP server, a tool call response, or an inside threat. That will help you contain the damage as much as possible.
However, it’s much better if you can just detect and filter those attacks before they’re persisted. This was the idea behind the OWASP reference project Memory Guard.
What question about memory do vendors consistently struggle to answer? Share the most revealing non-answer you’ve received.
Surprisingly, it’s a very first-principles aspect of memory – access control. For as mature as the industry is at things like RBAC, ABAC, and other fine-grained access controls on structured data, it’s rare to find the same level of access control on agent memory.
Most solutions have some approach to make sure an agent session for one user won’t leverage memories for another user. But when you start getting into more complex scenarios like team-based memory or graduated levels of access, it’s a space that’s evolving quickly.
Enterprise users have a good understanding of these requirements from an application security, database security, and API security perspective. They expect analogous techniques to be figured out already in the agent memory space, but the truth is most products out there can’t do it yet.
If a CISO reading this has memory-enabled agents in production and does one thing this quarter, what should it be, and what do you expect they’ll find?
Do at least an informal audit of the agent memory solutions in your organization. Most likely what you’ll find is a big security hole you weren’t aware of and that you want to get patched ASAP.
Specifically, I expect CISOs to discover two troubling things at most enterprise-sized companies.
First, you’ll find that there’s no governance in terms of what is being used for agent memory. You might think there’s no agent memory being used, but you’ll be surprised at how many developers have plugged in random, unvetted solutions into their local workstations or on a small shared server somewhere.
Second, you’ll be shocked by the amount of highly sensitive information that’s sitting in plain text, ripe for exfiltration in those systems. You’ll find leaked keys, database passwords, confidential business information, and more.
Download: The Agentic Software Development Guide