Reading the memory store on a modern coding agent can show you, line by line, exactly what your developers have been sharing with it: API keys, database credentials, customer documents, and internal notes written down for context. Security researchers now recommend a single quarterly audit of agent memory as the most useful check a CISO can run, because a quick read-through typically surfaces credentials that already sit in plain text on developer workstations and in cloud memory services.
What is actually sitting in agent memory?
Coding assistants persist context, snippets, and instructions into long-term memory so future sessions can pick up where the last one stopped, which also turns that memory into a store for API keys, credentials, and internal notes developers share during a session.
Audits of common coding agents have found sensitive material such as API keys, internal hostnames and proprietary code being sent into agent memory.
- API keys and OAuth tokens, copied in so the agent can make calls on the developer’s behalf.
- Database connection strings and service credentials, pasted in to debug a failing query.
- Internal documents and customer data, used as context for refactors or summaries.
- Notes about infrastructure, architecture diagrams in text form, and deployment runbooks.
All of this tends to land in plain-text files on the developer workstation, in cloud memory services that back the agent, and in markdown notes that travel between machines. Enterprises that invested heavily in a secure software development lifecycle, with secret managers, vaulting, and code-scanning gates, find that their most sensitive material has quietly ended up in a system that none of those controls cover.
How does memory poisoning actually work?
The attack pattern that worries researchers most is memory poisoning: getting malicious content into the agent’s memory so it shapes future behavior. Three extension points make this easier than it should be: plugins, skills, and Model Context Protocol (MCP) integrations.
Plugins, skills, and Model Context Protocol (MCP) integrations are the most common delivery vehicle. A user finds something that looks valuable, plugs it in, and never reads the underlying code carefully. Newer users, including people who only started coding once agentic tools became available, are the easiest targets because they lack the background to tell a legitimate plugin from a malicious one.
A realistic lure looks like a too-good-to-be-true offer: a Claude Code plugin that promises unlimited tokens on the free plan, or a skill that claims to automate a tedious task. Once installed, the plugin scans the agent’s memory, pulls out any keys or tokens it finds, and reports them back to an attacker-controlled endpoint. The social engineering is simple, and the extension model gives the lure a place to live.
The containment question after an incident is the same as for a phishing email: trace where the poisoned memory came from, whether it was an MCP server, a tool-call reply, or an insider, and stop the bleeding. But the better answer is to filter and reject poisoned writes before they are ever persisted, which is the goal of the OWASP reference project Memory Guard.
Why is access control on agent memory so far behind?
Enterprise security has spent years getting good at role-based access control, attribute-based access control, and fine-grained permissions on databases, APIs, and applications. Agent memory, by contrast, is treated as a flat personal store. Most products can keep one user’s session from picking up another user’s memories, and that is about it.
Team-based memory and policy-aware retrieval, the controls database teams rely on, are still rare in agent products. Buyers assume the permissions they use elsewhere will already exist in the agent layer, but in practice vendors have not shipped them.
What does the one CISO audit actually find?
Two things tend to show up at most enterprises.
First, there is no central governance over what is being used as agent memory. Leadership may believe the organization has no agent memory in production, but developers have installed unvetted tools on personal laptops, on shared servers, and inside small team environments that never went through a security review.
Second, the volume of sensitive material already in plain text is larger than expected. Leaked API keys, database passwords, confidential business information, and customer data are sitting in memory stores that an attacker with a foothold on a developer machine can read directly. The exposure is not theoretical; it is sitting in files that already exist.
What to do this quarter
- Inventory every coding agent and memory-enabled assistant in use, including those installed by individual developers without a formal procurement step.
- Run a search across known memory locations for API key formats, connection strings, and other high-entropy secrets.
- Rotate any secret that turns up in memory, and revoke tokens that were copied into agent context.
- Restrict which plugins, skills, and MCP integrations are allowed, and require a code review before new ones are installed.
- Push for filtering at write time so poisoned memories never persist in the first place.
A business that wants to see how its own site and listings appear to AI search engines, and whether AI agents can actually read what is published there, can run that check through a tool like SEOScanPro.
FAQ
What is agent memory and why is it a security problem?
Agent memory is the long-term store a coding assistant uses to remember context between sessions. The security problem is that developers paste API keys, credentials, and sensitive documents into that store, where they sit in plain text on developer machines and in cloud memory services.
How does memory poisoning attack a coding agent?
An attacker offers a malicious plugin, skill, or MCP integration that looks useful. Once installed, it writes poisoned entries into the agent’s memory or scans existing memory for secrets and reports them back to the attacker.
What should a CISO check in an agent memory audit?
The audit should look for two things: any agent memory solution in use that was never formally approved, and any sensitive data such as API keys, tokens, and confidential documents stored in plain text inside those memory stores.
SEOScanPro
SEOScanPro has the AI visibility report runs a full technical audit of a site and shows the measured result behind every check. Open the AI visibility report.
This article summarizes reporting from helpnetsecurity.com.