Banking AI agent memory isolation testing checks whether an agent can retain, retrieve or infer conversational and task data only within authorised customer, tenant, session and purpose boundaries. It uses controlled identities and synthetic markers to probe short-term context, persistent memory, caches and retrieval stores, then verifies that unauthorised data does not appear in responses, tool calls or accessible logs.

Define the isolation boundaries

Start with the agent's intended memory model. Document what it can retain, how long each type of memory persists, which identities may access it, and when it must be cleared. Include conversation history, summaries, agent state, vector-store entries, application caches and any memory passed between agents. An undocumented store or reset behaviour is a test gap.

Set explicit rules for customer, account, tenant, session and task boundaries. For example, a customer's preference may persist across their own sessions if that behaviour is approved. Account balances or another customer's details must remain unavailable to that customer unless the access policy permits them. Test the expected boundary for each data type rather than assuming all memory should have the same lifetime.

Map the agent's connected systems as well. Memory isolation tests examine data retained or reused by the agent; retrieval access control tests examine whether a connected source, such as a retrieval-augmented generation (RAG) index, returns documents the caller is not authorised to see. A workflow can pass one set of checks and fail the other.

Prepare controlled test data

Use synthetic customer profiles and unique canary strings, such as CUST-A-ORCHID-742, placed in approved test records or conversation inputs. Do not use live customer data. Create separate users and tenants with clearly defined permissions, and record which sessions should share memory and which should be isolated.

Confirm that the test environment has representative memory components, identity propagation, cache behaviour and background processing. Define how to start a clean session and how to reset or remove test data. If a component cannot be reset, use a fresh test namespace and verify that it cannot return data from earlier runs.

Run cross-boundary checks

For each canary, test both authorised retrieval and unauthorised access. Give the agent a customer A detail in an allowed interaction, then start a new session as customer B and ask direct and indirect questions that could expose it. Repeat across tenants, agent hand-offs, parallel sessions, retries and task resumption. Include attempts to make the agent reveal remembered details through a summary, a tool argument or a response to an unrelated request.

Check lifecycle boundaries too. After logout, session expiry, memory reset, customer offboarding or an approved deletion action, query again from the relevant identity and from a separate identity. Expected behaviour depends on the documented retention policy. A reset that clears visible conversation history while leaving a retrievable summary or cache entry is a failure when that data should have been removed.

Worked example

  1. In tenant A, ask the agent to store the synthetic marker CUST-A-ORCHID-742 as a test note for customer A.
  2. Start a fresh session as customer B in tenant A, then as a user in tenant B. Ask for the test note without supplying the marker.
  3. Resume customer A's session and check whether the marker is returned where the design permits it.
  4. Reset customer A's memory, then repeat the authorised query.

Customer B and tenant B must not receive the marker. Customer A should receive it only while the approved memory rule allows it. After reset, the result should match the specified deletion behaviour. Assert the response, tool inputs and relevant memory or retrieval traces; an agent's statement that it has forgotten the note is insufficient evidence.

Analyse failures and verify evidence

Treat disclosure in any channel as a failure: generated text, tool calls, cross-agent messages, summaries, notifications or logs available to an unauthorised role. Inspect access-control decisions, tenant and session identifiers, memory reads and writes, and deletion events. Logs can prove which path returned data, although their own access and retention need separate controls.

Common causes include missing tenant filters, session identifiers reused across users, stale cache entries, summaries that preserve sensitive details, and race conditions between memory writes and reads. Re-run failures with fixed identities and inputs, then vary timing and request order to expose intermittent leakage. Large language model output can vary, so assess whether the canary or other protected content is disclosed across repeated, controlled attempts. Record the configuration, test identities, prompts, expected boundary and evidence for each result.

Frequently asked questions

How is memory isolation different from database transaction isolation?

Database transaction isolation controls how concurrent transactions read and write database state. AI agent memory isolation controls which conversation or task data an agent can retain, retrieve or expose to each identity, and can involve several stores beyond a database.

Can memory isolation be tested with a non-deterministic AI agent?

Yes. Use stable synthetic canaries, fixed identities and controlled prompts, then repeat scenarios and check all output and tool-call channels for disclosure. Treat any observed unauthorised disclosure as a failure, even if other runs pass.

Should these tests use production customer conversations?

Use synthetic or appropriately anonymised data in an isolated test environment wherever possible. Production data introduces privacy and access risks, and is unnecessary for checking whether identity and memory boundaries are enforced.

What evidence should a memory isolation test retain?

Retain the test identity and tenant, memory configuration, scenario and expected access rule, observed response, relevant access or retrieval events, and reset or deletion result. Protect the evidence itself from unauthorised access.