# Set retention, deletion, and tenant boundaries before an AI assistant remembers > AI memory can improve continuity while retaining sensitive or hostile context beyond the original exchange. Define what may be remembered, its provenance, tenant boundary, expiry, user controls, deletion path, and incident response before enabling persistence. - Canonical URL: https://update.dsesecurity.com/updates/ai-assistant-memory-retention-deletion-tenant-boundaries/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: Gavin Stewart - Published: 2026-08-17T13:29:00+00:00 - Modified: 2026-08-17T19:22:08+00:00 - Last reviewed by DSE: 2026-08-17 - Resource type: Guide - DSE priority: Important - Topics: Business Continuity, Cybersecurity, IT - Reading time: 3 minutes ## What you need to know AI memory can improve continuity while retaining sensitive or hostile context beyond the original exchange. Define what may be remembered, its provenance, tenant boundary, expiry, user controls, deletion path, and incident response before enabling persistence. ## Potentially affected AI assistants and agents; conversation history; user preferences; summaries; embeddings and vector stores; retrieved context; application state; customer data; audit records; caches; backups; and deletion workflows. ## DSE recommendation Classify each memory type, require intent and provenance before persistence, enforce isolation outside the model, assign retention and deletion rules, expose meaningful user controls, and test poisoning, revocation, export, and incident containment. ## Article ## Source facts: memory changes both the data boundary and future behavior Microsoft’s [Guarding AI memory](https://www.microsoft.com/en-us/security/blog/2026/06/22/guarding-ai-memory/) describes memory as information an AI system retains and recalls across interactions. That persistence can support personalization and continuity, but Microsoft also identifies a larger attack surface: a malicious or misleading input can influence stored memory and affect reasoning or tool use after the original interaction has ended. The Microsoft guidance treats memory in two roles. It can contain high-value user information that should be protected as customer data, and it can shape agent behavior, so it also needs governance appropriate to a system that can act. Its design principles include establishing intent and provenance before persistence and enforcing isolation outside the model rather than relying on prompt instructions. That distinction matters because a model cannot serve as the only boundary between users, agents, customers, or tenants. Provider storage behavior also varies by feature. OpenAI’s official API data-controls documentation, for example, distinguishes abuse-monitoring logs from application state and publishes endpoint-specific retention and Zero Data Retention eligibility. Conversation, vector-store, file, response, and other endpoints do not all behave the same way. Those details are product and configuration facts that can change; they should be verified for the exact provider, endpoint, region, contract, and controls in use rather than copied into a permanent organization-wide assumption. ## DSE recommendation: decide what “remember” means before storing anything Separate transient working context from durable memory. A helpful multi-turn conversation does not require every message, retrieved document, inference, or preference to become permanent. - Create a memory register. List conversation history, session summaries, user preferences, task state, retrieved snippets, embeddings, tool results, feedback, audit evidence, and model-provider state. For each, record the owner, purpose, data classes, system of record, tenant, storage location, encryption and key boundary, readers, writers, retention, deletion method, and backup behavior. - Require a valid write reason. Define which events may create or update durable memory. Prefer explicit user intent for preferences and profile facts. Do not convert instructions embedded in email, webpages, tickets, or retrieved documents into durable governing memory merely because the model repeated them confidently. - Attach provenance and time. Store the source object, user or service identity, creation event, confidence or verification state, effective scope, expiry, and last review. Mark derived summaries as derived rather than authoritative records. When a source changes or is deleted, find and invalidate memories created from it. - Enforce isolation outside the model. Partition memory by tenant, user, agent, purpose, and environment using application and storage controls. Prevent a production agent from reading test memory or one customer’s summary from influencing another customer. Use authorization at retrieval time instead of a system prompt that says “only use the right tenant.” - Give people practical controls. Explain what will be remembered, allow review and correction where appropriate, provide a deletion request path, and distinguish deleting application memory from other records retained for security, legal, or contractual reasons. Confirm what backups and downstream indexes do after deletion. - Exercise memory attacks and failure. Test indirect prompt injection, gradual poisoning, forged user preference, cross-session contamination, deleted-source recall, account transfer, tenant reassignment, unavailable memory stores, and emergency disablement. Preserve enough evidence to determine what was written, read, and used. Factual boundary: A memory attack is a documented risk pattern, not proof that a particular product or deployment is vulnerable. Retention and deletion facts are provider- and endpoint-specific. Deleting one application object may not remove separately governed audit, abuse-monitoring, legal-hold, backup, or source-system records. Track unowned memories, expired items, failed deletions, cross-boundary tests, provenance coverage, stale-source recall, and time to disable a memory store. The useful outcome is bounded continuity: the assistant remembers only what has a legitimate purpose, traceable origin, authorized audience, and predictable end. ## Official references - Microsoft Security, [Guarding AI memory](https://www.microsoft.com/en-us/security/blog/2026/06/22/guarding-ai-memory/), June 22, 2026. - OpenAI, [Data controls in the OpenAI platform](https://platform.openai.com/docs/models/default-usage-policies-by-endpoint); current endpoint behavior should be rechecked before implementation. - NIST, [Generative Artificial Intelligence Profile](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence), NIST AI 600-1. ## Primary reference - Name: Microsoft Security: Guarding AI memory - Authority: www.microsoft.com - URL: https://www.microsoft.com/en-us/security/blog/2026/06/22/guarding-ai-memory/ - Source publication date: 2026-06-22 ## Citation and use Preferred citation: “Set retention, deletion, and tenant boundaries before an AI assistant remembers,” DSE Security, https://update.dsesecurity.com/updates/ai-assistant-memory-retention-deletion-tenant-boundaries/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.