Should organisations allow persistent memory in work-facing AI agents?

Why This Matters for Security Teams

persistent memory changes a work-facing AI agent from a session-scoped assistant into a system that can retain context across tasks, users, and time. That can improve continuity, but it also expands blast radius when the agent is prompted poorly, misrouted, or compromised. The real issue is not storage alone; it is whether memory becomes a durable channel for sensitive data, unsafe instructions, or hidden state that survives normal access controls.

Security teams often underestimate how quickly memory can become an identity and governance problem, especially when an agent is already operating with tool access. NHI Management Group research on AI Agents: The New Attack Surface report shows that 80% of organisations report agents performing actions beyond intended scope, including sharing sensitive data and revealing credentials. That is a warning sign for memory designs that assume the agent will stay within a narrow conversational boundary. Current guidance suggests treating memory as part of the agent's security perimeter, not a convenience feature bolted on afterwards, and aligning it with the NIST AI Risk Management Framework and OWASP Agentic AI Top 10. In practice, many security teams encounter memory abuse only after an agent has already retained something it should have forgotten.

How It Works in Practice

Persistent memory is safest when it is designed as governed state, not as an open-ended transcript. That means defining what can be stored, who can approve it, how long it survives, and how it is reviewed. In agentic environments, memory should be separated into classes such as operational context, user preference, and security-relevant state, because each has different retention and access rules. For example, preference data may be useful across sessions, while secrets, tokens, and privileged instructions should never persist.

Practically, teams should apply policy at write time and read time. Memory writes should be filtered for sensitive content, tagged with provenance, and tied to a business purpose. Reads should be evaluated against context such as the active user, task, data classification, and whether the memory item remains valid. This is where runtime policy matters more than static IAM. Agent behaviour is dynamic, so the safer pattern is to pair memory with ephemeral credentials, workload identity, and time-bound authorisation rather than assuming a stable role will cover every future action. The agentic guidance in OWASP NHI Top 10 and the CSA MAESTRO agentic AI threat modeling framework both support this direction, because memory is a source of latent risk that can be weaponised across sessions.

• Define a retention policy for each memory class, not a single global setting.
• Require explicit reset, deletion, and rehydration controls for user-facing agents.
• Log every memory write, retrieval, and overwrite with traceable provenance.
• Block persistence of secrets, credentials, and high-risk instructions by default.
• Review memory content after material changes in role, task, or access scope.

These controls tend to break down when agents operate across many tenants or external tools because memory becomes difficult to scope cleanly and validate in real time.

Common Variations and Edge Cases

Tighter memory controls often improve safety but increase operational overhead, requiring organisations to balance user continuity against review burden and latency. There is no universal standard for this yet, so best practice is evolving rather than settled. Some teams permit persistent memory only for low-risk preferences, while others use a full reset model for regulated workflows and sensitive business functions.

One important edge case is delegated or shared agents. If an agent serves multiple users, persistent memory can blur identity provenance and create cross-user contamination, especially when session boundaries are weak. Another is long-running autonomous agents that chain tools over time. Those systems can amplify a bad memory item into repeated unsafe action, which is why AI LLM hijack breach research and the Anthropic AI-orchestrated cyber espionage report are relevant cautionary reads. Persistent memory may be acceptable when it is narrowly scoped, user-owned, and reversible, but it is far harder to justify in systems that can act on behalf of the organisation without human confirmation. For that reason, current guidance suggests keeping memory minimal wherever an agent has execution authority or access to sensitive workflows.

Related resources from NHI Mgmt Group

• How can organisations prevent AI agents from becoming overprivileged?
• How can organisations govern AI agents that use service accounts and tokens?
• What should organisations do when AI agents become part of the fraud problem?
• Should organisations treat service accounts and AI agents under the same authorization model?