Session-level memory isolation with sanitisation
Control objective
Session-level memory isolation ensures that what an AI agent remembers for one user, session or tenant never bleeds into another's context — critical in banking where conversational memory may hold account numbers, balances or KYC details, and any leakage between customers is both a privacy breach and a regulatory incident (OWASP ASI06, IBM Cross-Session Privacy). The control verifies that memory is strictly partitioned and that residual data is sanitised between uses. Its targets are 100% of memory partitioned by the (user, session, tenant) key and 0 cross-session leakage events. To implement, namespace every memory record by that composite key and enforce it at the data-access layer so a read can only ever return records matching the active identity; clear or expire session-scoped memory at session end and sanitise any shared buffers before reuse. Instrument the store to log the partition key on every read and write, and run automated probes that attempt to retrieve another session's data to confirm isolation holds. Evidence to keep includes partition coverage reports and leakage-probe results. Because the leakage threshold is zero, any detected cross-session retrieval is a breach that must trigger containment, notification under the relevant privacy regime, and a fix before the affected memory path is reopened.
Partition memory storage by (user, session, tenant) with cryptographic isolation. Automatically sanitise session-scoped memory at session end. Audit cross-session data access attempts quarterly.