Agent Memory

Expanded Definition

Agent memory is the persisted context an OWASP Agentic AI Top 10 concern when an autonomous software entity stores prior prompts, tool outputs, user preferences, policies, or task state for later reuse. In NHI governance, that stored context is not neutral. It can alter future decisions, expand tool use, and create hidden pathways into secrets, permissions, and sensitive workflows. Definitions vary across vendors: some treat memory as a simple convenience layer, while others include vector stores, session summaries, retrieval caches, and long-lived agent profiles. For security teams, the practical boundary is control, not storage format. If the agent can act on it later, the memory is operational state and should be treated as part of the identity surface, similar to how the NIST AI Risk Management Framework treats AI context as a risk-bearing system component. Agent memory is distinct from ordinary application logging because it can drive behaviour rather than just record it. The most common misapplication is allowing unreviewed task history to persist into new sessions, which occurs when teams confuse convenience caching with governed, reusable agent state.

Examples and Use Cases

Implementing agent memory rigorously often introduces retention and review overhead, requiring organisations to weigh continuity of execution against the risk of stale, sensitive, or improperly inherited state.

• An IT service agent remembers a prior admin exception and later reuses that context to request broader permissions than the current ticket justifies.
• A code-assist agent stores repository-specific findings and later surfaces them in a different project, increasing the chance of cross-tenant leakage. That pattern is especially relevant in analyses such as Analysis of Claude Code Security.
• A customer-support agent keeps account details in memory after a session ends, then incorporates them into a later conversation without fresh authorisation or purpose limitation.
• A procurement agent retains a vendor approval exception and applies it to a new request, bypassing normal NIST AI Risk Management Framework controls for traceability and oversight.
• An internal automation agent caches API key fragments or operational notes, echoing real-world compromise patterns seen in the Moltbook AI agent keys breach.

Teams assessing persistent context should also align implementation choices with the CSA MAESTRO agentic AI threat modeling framework, especially where memory can influence tool calling or policy decisions.

Why It Matters in NHI Security

Agent memory becomes a security issue when it outlives the trust decision that created it. In NHI environments, that means stored context can preserve access cues, operational assumptions, or sensitive data long after a session should have ended. NHI Mgmt Group research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which makes memory systems another potential repository for sensitive state if they are not designed with strict controls. The same governance mindset that applies to secret management should apply to agent memory, because forgotten context can become an unwritten privilege. This is why memory design should be considered alongside OWASP NHI Top 10 guidance and broader threat mapping such as MITRE ATLAS adversarial AI threat matrix. It also matters because once memory is poisoned, the agent may repeatedly amplify bad context across later actions, making recovery slower than a single failed request. Organisations typically encounter the consequence only after a memory-driven mistake reaches production, at which point agent memory becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• AI Agent Authentication
• What is agent communication poisoning?
• What is a shadow agent and why is it more dangerous than a typical shadow NHI?
• A2A — Agent-to-Agent Protocol