AI Memory and Session Retention Risks

Remembering forever is a product decision with a bill

Chat history, preference stores, agent scratchpads, and long-term vector memory all count as AI memory. Unlimited retention feels like better UX until a deletion request, a poisoned instruction, or a pasted API token resurfaces months later. APRF Memory Management expects classification, isolation, TTLs, and a purge that actually clears embeddings.

A support agent kept full threads in a per-org index. SSO for a departed employee was revoked; memory rows still held customer PII and a debug token. A later run retrieved the token. No TTL, no write-time secret scan.

Three buckets

- Ephemeral session — dies with TTL; default for most assistants

- Long-term profile — explicit, capped, user-visible where required

- Forbidden — secrets and raw credentials never commit

Reads and writes require `tenant_id` + `user_id` (same bar as RAG). Prefer structured fields over free-text "durable instructions" that injection can plant.

Deletion that means deletion

UI "clear chat" is not enough. Purge APIs must remove primary rows and vector IDs. Test with two tenants: plant a unique secret in A, assert B never sees it; delete A and assert retrieval is gone. Those cases belong in Evaluation—not a slide about GDPR.