What breaks when AI agent memory is stored in readable files?

Why This Matters for Security Teams

Readable memory files turn an agent’s working context into a durable attack surface. That is not just a confidentiality issue. It becomes an identity problem because the file can capture tokens, tool outputs, task intent, and relationship data that let an attacker impersonate the agent or steer future actions. This is exactly the kind of exposure highlighted in LLMjacking: How Attackers Hijack AI Using Compromised NHIs, where credential abuse and fast attacker movement become operationally relevant within minutes.

The risk is amplified in agentic systems because memory is often reused across sessions, tools, and workflows. A readable file may be convenient for debugging, but it can also preserve secrets far longer than intended and make later compromise much more valuable. NHI Management Group has documented how secrets sprawl and delayed remediation worsen this pattern in The State of Secrets in AppSec, where exposure is already difficult to contain once it lands in shared operational systems. Security teams often underestimate how quickly readable memory becomes an identity substrate for the attacker, not just an application artifact. In practice, many teams discover this only after the agent has already been used to replay trust relationships or disclose sensitive context.

How It Works in Practice

When agent memory is stored in plain or readable files, the file itself becomes a high-value target. The problem is not merely that an attacker can read notes. The problem is that the file often contains the operational ingredients needed to continue the compromise: API keys, bearer tokens, user preferences, prior prompts, tool call history, and even references to other systems the agent can reach. Once that context is exposed, an attacker can reconstruct the agent’s decision path and use it to mimic legitimate behaviour.

Current guidance suggests treating this memory as workload data plus identity data. In agentic environments, the safer pattern is to use short-lived, task-scoped storage and bind memory access to runtime policy rather than broad file permissions. That aligns with the direction of the OWASP Agentic AI Top 10, which emphasises misuse of agent autonomy and exposed execution paths, and the NIST AI Risk Management Framework, which pushes organisations to govern AI systems across the lifecycle rather than only at deployment.

• Encrypt memory at rest, but do not rely on encryption alone if the runtime can decrypt everything automatically.
• Prefer ephemeral per-task memory with strict retention limits and automatic revocation.
• Separate conversational history from secrets and from tool execution logs.
• Use workload identity and policy checks before an agent can read or write memory.
• Redact or tokenize secrets before they ever enter persistent storage.

For implementation teams, the practical question is whether the memory file can be used to bootstrap another identity or another tool session. If the answer is yes, the file is already part of the trust boundary. This guidance tends to break down in developer laptops, shared debug mounts, and notebook-driven environments where memory is copied into flat files for convenience and then reused outside the intended runtime.

Common Variations and Edge Cases

Tighter memory controls often increase operational overhead, so organisations must balance observability against exposure. That tradeoff becomes visible when teams need reproducible agent behaviour for testing, audit, or incident review, yet persistent readable files also preserve sensitive context that should have expired. There is no universal standard for this yet, but best practice is evolving toward minimised retention and runtime-controlled access rather than human-readable dumps.

One edge case is benign-looking session replay. Teams often assume a memory file is safe because it contains prompts and tool outputs rather than passwords. In practice, those details can still enable impersonation by revealing naming conventions, approval patterns, and escalation paths. Another case is multi-agent workflows, where one agent’s memory file can expose enough context to pivot into another agent’s permissions or queue. NHI Management Group’s research on AI LLM hijack breach and DeepSeek breach shows why exposed operational context can compound quickly once attackers can read and reuse it. The emerging consensus is to treat readable agent memory as sensitive infrastructure, not developer convenience. It breaks down most sharply in environments that mix long-lived notebooks, shared volumes, and broad service-account access because the same file can be read, copied, and replayed across trust zones.

Related resources from NHI Mgmt Group

• What breaks when an AI agent is hijacked but still looks trusted?
• What breaks when authorization is only evaluated after an AI agent acts?
• What breaks when organisations use a kill switch for AI agent governance?
• What breaks when an AI agent stores its own access token?