The part of your AI agent nobody put behind a firewall
Most teams that ship an AI agent spend their security budget on the model and the prompt. They red-team the system prompt, rate-limit the API, and scan the tool calls. Then they bolt on a memory layer so the agent stops forgetting things between sessions, and that layer quietly becomes the least-governed data store in the company.
We keep running into this in our engagements. A support agent that "remembers" past tickets. A coding assistant that keeps a running summary of a repository. An internal ops bot that stores what each user asked it last week. Each one writes data somewhere, reads it back later, and feeds it straight into a model that will act on whatever it finds. That is a database, an ingestion pipeline, and an execution path stitched together, and it usually ships with none of the controls any one of those three would get on its own.
Memory is what makes an agent useful past a single turn. It is also a new attack surface, a new place for regulated data to pool, and a new way for one user's input to change another user's outcome. This article walks through where the risk actually lives and the controls we put in place before an agent with persistent memory goes anywhere near production data.
What "memory" means once you look closely
"Memory" gets used as one word for several different things, and the security properties of each are not the same. It helps to separate them before deciding how to protect them.
The context window is the short-term working memory the model sees on a given call. It lives for one request and disappears. The risk here is classic prompt injection: content that reaches the window can carry instructions.
The long-term store is where the interesting problems start. This is usually a vector database or a plain table that holds embeddings, summaries, past messages, extracted "facts" about a user, or retrieved documents. It persists across sessions and often across users. Pinecone, Weaviate, Redis, and pgvector all show up here. Whatever the agent writes today, it can read back in three weeks and treat as trusted context.
Then there is scratch or episodic memory, the intermediate notes an agent keeps while working a multi-step task, and summarized memory, where older content is compressed to fit the window. Compression matters for security because it launders provenance. Once a hostile instruction has been folded into a tidy summary labelled "notes from previous session," nothing downstream remembers that it came from an untrusted source.
The through-line is simple. Anything an agent can read back and act on is memory, and every one of those paths deserves the same scrutiny you would give an external input, because that is exactly what it is.
Where the real risks live
Memory poisoning and persistent injection
Standard prompt injection is a single-turn problem. You sanitize the input, the model does something it should not, and the conversation ends. Memory turns that into a durable one. An attacker plants an instruction, the agent stores it as a "fact" or a summary, and days later the agent retrieves that entry into its context and follows it. The injection outlives the session that delivered it.
We have seen the benign version of this by accident more often than the malicious one. An agent misreads a user's frustrated message as a standing preference, writes it to long-term memory, and then behaves oddly for that user for weeks with no obvious cause. The malicious version is the same mechanism aimed on purpose: get one hostile string written to the store, and it fires every time the retrieval query pulls it back. OWASP tracks this under LLM01 (Prompt Injection) in its Top 10 for LLM Applications, and MITRE's ATLAS knowledge base catalogues the same pattern as an adversarial technique against ML systems.
Data pooling in a place that was never scoped for it
The moment an agent starts writing conversation history and extracted facts to a persistent store, that store fills up with whatever users typed. Card numbers pasted into a chat. Health details. Passport data, which in the UAE market comes up constantly during onboarding flows. None of it was meant to live in a vector database, and yet there it sits, embedded and indexed.
This is a compliance problem before it is a breach problem. Under PCI-DSS 4.0, anything that touches cardholder data pulls the system into scope, and a memory store full of chat transcripts is a component most teams never added to their scope diagram. Under the UAE Personal Data Protection Law and GDPR, that store now holds personal data with a retention obligation, a deletion obligation, and a residency question about where the vectors are actually hosted. A "delete my account" request that does not also purge the embedding store is an unfulfilled data-subject request, and it will not survive an audit.
Cross-tenant and cross-session bleed
Retrieval is a similarity search, not an access-control decision. If the memory store is shared and the query is not scoped tightly to the current user and tenant, the agent can surface one customer's data inside another customer's session. The failure is quiet. There is no error, no alert, just a relevant-looking chunk of someone else's information dropped into a stranger's context. In a multi-tenant SaaS product this is the difference between a feature and a reportable incident.
Excessive agency acting on poisoned recall
Memory risk compounds with tool access. An agent that can only talk is annoying when its memory is wrong. An agent that can send emails, open tickets, move money, or change infrastructure is dangerous when its memory is wrong, because it will take real action on a retrieved instruction it now treats as its own intent. OWASP calls this LLM08, Excessive Agency. The memory layer is where the poisoned instruction waits, and the tool layer is where it pays off.
Mapping memory types to risk and control
The controls differ by memory type, which is why lumping them together leads to gaps. This is the mapping we start from on an assessment.
Memory typePrimary riskControl that actually helps
Context window (short-term)
Single-turn prompt injection
Input classification, delimiter and role separation, output filtering
Long-term vector store
Poisoning, PII pooling, cross-tenant bleed
Tenant-scoped queries, write-time validation, provenance tags, encryption, TTL
Summarized memory
Provenance laundering
Preserve source and trust level through summarization; never elevate untrusted content
Scratch / episodic memory
Task-scoped leakage
Ephemeral by default, destroyed at task end, never promoted to long-term without review
Retrieved external docs
Indirect injection via content
Treat retrieved content as untrusted data, not instructions; strip active markup
Treat the memory read as untrusted input
The single most useful shift we recommend is this: stop trusting your own memory store. Teams spend real effort validating what a user types on the way in, then read from the vector database on the way back and hand the result to the model as if it were gospel. The store is only as trustworthy as everything that was ever allowed to write to it, which in most designs is "the users." Data coming out of long-term memory should pass through the same classification and sanitization you apply to a fresh external request.
Concretely, that means a read-time guard that inspects retrieved chunks for instruction-like content before they enter the context, and a clear structural boundary in the prompt between "here is retrieved reference material" and "here are your instructions." The model should never be in a position where a memory entry can rewrite its objective.
A practical control checklist
This is the checklist we work through when hardening an agent's memory layer. It maps cleanly onto NIST CSF 2.0 functions and ISO 27001:2022 Annex A controls, which matters when the same work has to satisfy an auditor and not just an engineer.
- Isolate by tenant and user. Every retrieval query carries a mandatory tenant and user filter enforced at the data layer, not left to the application to remember. Shared indexes without hard partitioning are the most common cause of cross-tenant bleed we find.
- Validate on write. Classify and sanitize content before it is embedded and stored, so obvious injection strings and unwanted secrets never enter the store in the first place. Prevention at write time is cheaper than detection at read time.
- Sanitize on read. Inspect retrieved memory for instruction-like content and keep it structurally separated from the agent's actual instructions. Assume the store may already hold something hostile.
- Redact and classify PII before persistence. Detect and mask card numbers, national IDs, and other regulated data at the point of writing to memory, so a chat transcript does not silently drag the vector store into PCI-DSS or PDPL scope. This aligns with ISO 27001 Annex A.8.10 and A.5.34.
- Set retention and expiry. Give memory entries a time-to-live and a documented deletion path. A data-subject deletion request has to reach the embedding store, not just the primary database.
- Preserve provenance through summarization. Carry the source and trust level of content as it is compressed. Never let a summarization step upgrade untrusted user input into trusted context.
- Encrypt at rest and in transit, and confirm where it lives. Vector stores hold personal data now. Encryption and a clear answer on hosting region are table stakes for GDPR and UAE PDPL residency questions.
- Log reads and writes. Record what was written to memory, by whom, and what was retrieved into which session. Without an audit trail, a memory-poisoning incident is invisible after the fact and impossible to scope during response.
- Constrain agency. Keep high-impact tools behind an approval step or a policy check that does not depend on the memory layer being clean. Poisoned recall should not be able to trigger an irreversible action on its own.
- Red-team the memory path specifically. Test whether a string written in one session survives, gets retrieved later, and changes behaviour. That end-to-end test is the one that catches persistent injection, and it is the one most teams skip.
Why this sits at the intersection of security and governance
Agent memory is awkward precisely because it does not belong to one team. The security group treats it as an injection and access-control problem. The data-protection group treats it as a retention and residency problem. The platform team treats it as a database. All three are right, and when no one owns the overlap, the memory store ends up governed by none of them. In the assessments we run, the finding is rarely a clever exploit. It is that the memory layer never got classified as a data store subject to the organisation's existing policies, so none of those policies were ever applied to it.
The fix is not exotic. It is applying controls the organisation already has, ISO 27001, NIST CSF, CIS Benchmarks for the underlying infrastructure, to a component that slipped in through an AI feature and was never added to the register. The frameworks work here. Someone just has to point them at the right target.
How Aydahwa Enterprise can help
At Aydahwa Enterprise we assess and harden AI-enabled systems the same way we approach any other production workload: identify where sensitive data flows, map the attack surface, and apply controls that hold up to both an attacker and an auditor. For teams putting agents with persistent memory into production, that means reviewing the memory architecture as a data store, checking tenant isolation and retention against ISO 27001 and PCI-DSS obligations, and testing the memory path for persistent injection rather than assuming a clean prompt is enough. Our background across banking, telecom, and critical national infrastructure means we have done this where the data is regulated and the margin for error is small.
If you are deploying AI agents and want to know where your real exposure sits, our cybersecurity services cover architecture review, threat modelling, and control implementation, and our cloud security and migration practice handles the infrastructure the memory layer runs on. You can start with our free cybersecurity self-assessment or work through the cybersecurity readiness checklist to see where the gaps are. When you are ready to talk specifics, get in touch and we will scope it against your actual environment.
