Everyone is selling you the same upgrade right now: give your agents memory. Persistent context, a vector store, a knowledge graph, an MCP server that wires the model into your tickets, your CRM, your codebase, your support transcripts. The pitch is productivity. The agent stops asking you the same question twice, it "remembers" the customer, it gets smarter over time. It is a good pitch. I have made it myself.
Underneath the demo it isn't a productivity feature. It's a data-residency problem wearing a productivity costume so it can walk past your review board without getting carded.
Memory is retention by another name
Security people understand this instinctively and product people often don't: memory is just retention by another name. The moment an agent can write something durable and read it back later, you have created a data store. Data stores have owners, classifications, retention schedules, encryption requirements, access controls, and, in my world, regulatory scope. The agent's "brain" is not exempt from any of that because it is wrapped in an embedding model and called context.
Think about what flows through a working agent over a quarter. A customer's name and account number, pasted into a support thread the agent summarized into memory. A card PAN that a user dropped into a chat because users do that. An internal Slack export the agent ingested to "learn our tone." A snippet of production data someone used to debug an issue with the agent's help. None of it was deposited deliberately into a system of record. It accreted, sideways, into a vector index that lives in a bucket nobody added to the data inventory.
That is how PCI and PII scope expands now. Not through a new application someone designed, but through a memory layer that quietly absorbs whatever passes in front of it. You spent years shrinking your cardholder data environment, tokenizing, segmenting, pushing PANs out of your logs. Then you handed a hundred agents a durable place to remember things and re-expanded scope in a layer your QSA has not heard of yet. The data lake didn't get approved. It got summoned.
MCP makes it worse before it makes it better
I am genuinely bullish on the Model Context Protocol (opens in new tab). Standardizing how agents reach tools and data is the right architectural move, and it will pay off. But be honest about what a connected protocol does to a data-flow diagram: it turns N point integrations into a mesh where any agent, given the right server, can pull from systems it has no business touching and stash the results in its own memory.
The connector is the easy part. The hard part is that data now moves along paths your diagram does not show, lands in stores your inventory does not list, and persists on schedules nobody set. In a regulated shop, "I don't know where the cardholder data is" is a finding — and "the agent put it there" is not a remediation plan.
So the question I would ask before you connect anything: when this agent reads a record through MCP, what is it allowed to keep? Reading is transient and governable. Remembering is durable and, by default, ungoverned.
Treat the memory store like the database it became
I am not arguing against agent memory. Treat it like what it is — a data store — and apply the boring controls you already know how to run. The discipline is the same; only the location is new.
- Classify at write time, not read time. The expensive mistake is letting raw content land in memory and trying to scan it later. Put a classification and redaction step in front of the write path. PANs get tokenized or dropped before they are ever embedded. PII gets tagged so you know what category of data the store now holds. If you can't classify it, the agent doesn't get to keep it.
- Encrypt and key-scope the memory store like the system of record it became. Vector indexes and context caches are data at rest. They get the same KMS-backed encryption, the same key rotation, and the same access policy you would demand of any database holding the same content. A memory store full of customer data with default settings is an unmanaged production database with better marketing.
- Bound retention and prove deletion. Memory needs a TTL and a purge path, full stop. If a customer exercises a deletion right, "it's somewhere in the embeddings" is not an answer a regulator accepts. Design the store so you can find and remove a subject's data, and test that you actually can, before someone makes you.
- Scope what each agent can retain, per role. A support agent and a sales-enablement agent should not have the same memory permissions, because they do not have the same data needs. Least privilege didn't go away when the principal became a model. If anything it matters more, because the agent will helpfully remember everything you let it.
- Inventory the memory stores as first-class assets. If it is not on the data map, it does not exist to your audit, which means it exists only to your adversary. Every durable agent brain goes in the inventory with an owner, a classification, and a flag for whether it is in PCI or PII scope.
None of this is exotic. It is the same data-protection program you already run, pointed at a surface your program did not know it owned yet. The controls are not the hard part. Nobody decided agent memory was in scope for them, so it sailed through as a feature instead of a system.
Draw the diagram before you hand over the brain
Serving 1,500-plus financial institutions taught me a habit I can't switch off. Before I get excited about what a new capability lets us do, I ask what it lets us retain, and who answers for it when someone asks. Agent memory is the most under-governed retention surface most companies are building right now, approved on the strength of a productivity story while the data-residency story goes unwritten.
So before you give your agents a durable brain, draw the data-flow diagram for what that brain will hold: sources, classifications, retention, deletion, encryption, scope. Get it signed by the same people who sign off on your databases. If you can't produce that diagram, you don't have an AI productivity initiative yet. You have an unmanaged data lake with a great demo. Classify it, encrypt it, and bound it while it is still small enough to govern, because the one thing memory does relentlessly is grow.