Agent memory systems let AI agents remember preferences, project facts, prior decisions, summaries, and workflow state across turns or sessions. Memory can make agents feel dramatically more useful because users do not need to repeat context. It can also create durable security, privacy, reliability, and cost problems when the system stores the wrong fact, stores too much, trusts untrusted content, or retrieves stale information into future prompts.
The key question is not whether agents should have memory. The question is what type of memory belongs in which scope, who can write it, how it is verified, how long it lasts, and how it is deleted. A memory system is a data product, not just a longer prompt. It needs provenance, permissions, retention, monitoring, evaluation, and user controls.
This guide is part of the Agent Security cluster. Pair it with /guides/agent-security-guide/ for threat modeling, /guides/agent-monitoring/ for memory-operation observability, /guides/agent-evaluation-framework/ for memory behavior tests, /guides/agent-cost-management/ for context budget control, /agents/ for discovering agent patterns, and /tools/ai-cost-calculator/ for estimating the cost impact of long context.
Key takeaways
- Treat memory writes as state changes that can affect future behavior.
- Separate preferences, project facts, task state, sensitive records, and operational policy.
- Record provenance, confidence, scope, expiration, and user controls for every durable memory.
Types of agent memory
Memory is not one thing. A user preference such as preferred tone is different from a project fact such as deployment target. A temporary task note is different from a durable business rule. A sensitive record such as billing status is different from a harmless UI preference. Lumping these together leads to over-retrieval, privacy risk, and wrong behavior.
Define memory types before implementation. Common categories include user preferences, organization preferences, project facts, task state, conversation summaries, tool results, examples, policies, and sensitive records. Each category should have its own write rules, retrieval rules, retention period, and deletion path. The agent should not decide all of this dynamically from a single prompt.
- Preference memory: tone, formatting, language, workflow style, and stable likes or dislikes.
- Project memory: stack, domain, repository, deployment target, conventions, and known constraints.
- Task memory: temporary state for a current workflow or multi-step job.
- Sensitive memory: identity, billing, permissions, credentials, customer data, and private records.
Memory scopes and permissions
Memory scope determines who can use a memory. Personal memory should not automatically become team memory. Team memory should not leak into another customer account. Project memory should not apply to a different repository just because the names sound similar. Scope mistakes are some of the most damaging memory failures because they create privacy leaks and confusing behavior.
Permissions should govern both reads and writes. A user may allow an agent to remember personal preferences but not billing facts. An admin may approve organization-wide policy memory. A tool may write task state but not durable user identity. A memory system should make these rules explicit instead of letting every model call append new facts.
- User scope: applies only to one person.
- Project scope: applies only to a specific workspace, repository, or product.
- Organization scope: applies to approved shared policy or conventions.
- Session scope: expires when the task or conversation ends.
Provenance and trust
Every durable memory should answer where it came from. Was it stated by the user, inferred by the agent, extracted from a document, returned by a tool, or written by an admin? Was it confirmed? When was it last seen? What evidence supports it? Provenance lets the agent and the operator decide how much to trust the memory.
Prompt injection makes provenance essential. If a web page tells an agent to remember a new security policy, that should not be treated the same as an admin setting. Tool outputs and retrieved documents are data, not necessarily authority. Memory writes from untrusted content should be blocked, downgraded to temporary task state, or require user confirmation.
- Source: user, admin, system, tool, document, retrieval result, or model inference.
- Confidence: confirmed, inferred, unverified, stale, or contradicted.
- Timestamp: created, last verified, last used, and expiration date.
- Evidence: link to trace, message, tool result, or document reference when safe.
Retrieval and context budgets
Memory retrieval should be selective. Injecting every memory into every prompt increases cost and increases the chance that stale or irrelevant facts influence the agent. Retrieval should consider task, scope, recency, confidence, and sensitivity. The agent should know when a memory is a suggestion, a preference, a verified project fact, or an admin policy.
Context budgets connect memory design to cost management. Long memory blocks increase input tokens and may push the agent toward more expensive models. Use the Agent Cost Management guide at /guides/agent-cost-management/ and the AI Cost Calculator at /tools/ai-cost-calculator/ to estimate the cost impact of memory-heavy workflows. Sometimes the cheapest memory is a better retrieval rule, not a bigger context window.
- Retrieve only memories relevant to the current task and scope.
- Prefer concise structured memories over long narrative summaries.
- Do not inject sensitive memory unless the task requires it and the user is authorized.
- Track token cost added by memory and prune stale records.
Memory poisoning and prompt injection
Memory poisoning occurs when incorrect, malicious, or untrusted information is saved and later influences the agent. It can happen through direct user input, imported documents, web pages, tool outputs, or model inference. The risk is high because the attack persists beyond the original conversation. A one-time prompt injection can become a long-term behavior change if it writes memory.
Defenses include write approval, source labeling, policy checks, expiration, conflict detection, and monitoring. For example, a memory that changes payment instructions, security policy, deployment target, or user identity should require explicit confirmation. A memory derived from a public page should not modify private workflow rules. The Agent Security Guide at /guides/agent-security-guide/ covers broader injection defenses.
- Block memory writes that request policy changes from untrusted content.
- Require confirmation for identity, billing, permissions, security, and production facts.
- Expire uncertain memories and re-verify old project facts.
- Log memory writes so monitoring can detect suspicious sources.
User controls and deletion
Users and administrators need control over durable memory. They should be able to inspect what the agent remembers, correct inaccurate facts, delete memory, disable memory for a workflow, and understand how memory affects behavior. Hidden memory creates trust problems even when it is accurate because users cannot tell why the agent behaves a certain way.
Deletion should be real within the product's stated retention rules. If memory is copied into logs, analytics, evaluation datasets, or support tools, the policy should say so. For privacy-sensitive products, memory controls are not optional. They are part of the safety and compliance posture. Even for simple static tools, avoid implying that personal memory is stored if the site has no database or backend.
- Show memory records with source, scope, and last updated date.
- Allow edit, delete, export, and disable controls where memory is durable.
- Do not store secrets, API keys, passwords, or raw credentials in memory.
- Document retention and deletion behavior in plain language.
Evaluate and monitor memory behavior
Memory systems need tests. The evaluation framework at /guides/agent-evaluation-framework/ should include cases where memory helps, memory conflicts with the current instruction, memory is stale, memory comes from untrusted content, and memory should not be retrieved. A memory-capable agent is not reliable until it can ignore the wrong memory as well as use the right one.
Production monitoring should track memory reads, writes, updates, deletes, conflicts, and user corrections. A high correction rate may mean the agent writes too aggressively. A high retrieval rate may mean context is too broad. A suspicious source pattern may indicate memory poisoning. Tie these signals to the dashboard described in /guides/agent-monitoring/.
- Test current instruction versus stale memory conflict.
- Test untrusted document attempts to create durable memory.
- Test user correction and deletion behavior.
- Monitor memory writes by source, scope, category, and approval status.
Implementation checklist
- Define memory categories, scopes, write rules, retrieval rules, retention, and deletion controls.
- Record provenance, confidence, source, timestamps, and expiration for durable memory.
- Block or review memory writes from untrusted content and sensitive categories.
- Retrieve memory selectively to reduce cost and avoid stale context.
- Evaluate and monitor memory behavior as part of agent reliability and security.
FAQ
What is agent memory?
Agent memory is stored context that an AI agent can use across turns or sessions, such as user preferences, project facts, task state, summaries, and approved workflow rules.
Why is agent memory risky?
Memory can become stale, incorrect, private, or poisoned by untrusted content. Because it affects future behavior, a bad memory can persist beyond the original interaction.
What should not be stored in agent memory?
Do not store API keys, passwords, raw credentials, unnecessary personal data, unsupported policy changes, or sensitive facts that lack consent and access controls.
How should memory writes be approved?
Low-risk preferences may be saved automatically with transparency, but identity, billing, permissions, security, production, and policy memories should require confirmation or admin approval.
How does memory affect AI cost?
Memory can increase input tokens when injected into prompts. Selective retrieval, concise structured memory, expiration, and pruning reduce both cost and irrelevant context.
How do I test agent memory systems?
Test helpful memory, stale memory, conflicting current instructions, untrusted-source memory writes, deletion, correction, and scope isolation between users or projects.