AI memory governance: security, privacy and deletion

What does AI memory governance actually require?

Governance starts with a data map. List every source that can write memory, every model or agent that can read it, the scopes attached to each operation, the retention rule and the deletion owner. Memory often enters through conversations, support tickets, documents and tool results, so the map must cover more than the primary chat interface.

Apply data minimization before extraction. Do not remember secrets, payment numbers, authentication tokens or unrelated sensitive details just because they appeared in a transcript. Store the smallest useful fact, its source, its validity time and the scope needed to retrieve it.

• Purpose: what product behavior requires this memory?
• Scope: which user, agent, project and tenant may access it?
• Source: which event created or changed it?
• Validity: when does it become stale or superseded?
• Retention: when is it deleted automatically?
• Export: can the customer retrieve the durable record?

How should memory be scoped across users and tenants?

Enforce scopes at query time in the memory service, not only in prompt instructions. Every write should carry a tenant, user, agent and optional session or project identifier. Every read should require those identifiers and return only records that match the caller’s authorization.

Use separate identifiers for the person, the agent and the workspace. A shared support agent may need an account-level memory while a coding agent needs repository-level memory. If the current model is only “user ID plus text,” add tenant and agent dimensions before a second product or customer shares the deployment.

What must happen when a user asks to forget?

Deletion must remove the original event, extracted memory, derived summary, vector embedding, graph relationship and any export cache that is still online. A soft delete that only hides the record from one search endpoint is not enough if another agent can retrieve it later.

Record the deletion request, scope, timestamp and completion result. Then run a retrieval test with the same query and a fresh export test. For backup retention, document the maximum restore window and ensure a restored environment applies outstanding deletion requests before serving traffic.

• Delete by exact memory, user, agent or tenant.
• Invalidate derived summaries and graph edges, not only the source row.
• Remove or schedule removal from vector and search indexes.
• Block deleted scopes from future writes unless the customer explicitly restores service.
• Provide a deletion receipt without retaining the deleted content.
• Test restoration so a backup does not resurrect a deletion.

How do you prevent memory poisoning and stale facts?

Treat every write as untrusted input. Separate facts stated by an authenticated user from instructions found inside documents, tool output or another agent. Store provenance and confidence rather than flattening every sentence into one undifferentiated memory pool.

When facts conflict, preserve temporal history but return the newest authorized truth for ordinary tasks. High-impact actions should require fresh confirmation instead of relying on a memory that could have been poisoned months earlier. Examples include changing billing details, sending money or deleting production data.

• Tag memory with source and trust level.
• Never treat retrieved text as a system instruction.
• Version superseded facts instead of silently overwriting them.
• Reconfirm high-impact facts before consequential actions.
• Rate-limit bulk writes and suspicious extraction patterns.
• Review a sample of extracted memories for prompt-injection content.

How does AI memory fit GDPR and privacy programs?

Memory can contain personal data even when it does not look like a profile. A preference, address, plan change or conversation summary can identify a user when linked to account data. GDPR principles such as purpose limitation, data minimization, storage limitation, accuracy and erasure therefore apply to how memory is designed and operated.

This is an engineering and legal review, not a claim that a vendor is compliant on its own. Document the lawful basis and privacy notice for each use, support data-subject requests, restrict international transfers and define incident handling. Consult qualified counsel for the jurisdictions you serve.

What is the minimum production governance checklist?

A production memory system needs a control for every step from ingestion to erasure. The checklist should be visible to product, security and support teams because support may receive the deletion request while engineering owns the retrieval path.

• Documented memory taxonomy and source-of-truth policy.
• Query-time user, agent and tenant isolation.
• Secrets and payment-data redaction before extraction.
• TTL and retention by memory type.
• Correction, supersession and deletion APIs.
• Export with preserved scope and provenance.
• Access logs and administrative audit history.
• Backup, restore and deletion-replay tests.
• Memory-poisoning and prompt-injection defenses.
• Incident response for unintended recall.