Point at what makes it impossible, then show that thing running. Saying data is isolated is a claim about every request you have ever served. No sampling gets you there. What you can show is narrower and stronger. Your tenant is resolved from the verified credential. Every query is scoped by that resolved value. No code path takes a tenant identifier from the request. Add a negative test: a request naming another tenant is refused. Give your retrieval and caching layers their own pass here. That is where a scoped system leaks. An index built across tenants does not care how careful your query layer was.
Related: How do I scope an agent so it can only reach the caller's own resources?, How do I test that a guardrail holds, rather than that it exists?
Scope the store like a database, and test it like one. A memory or retrieval layer is a data store people forget to treat as one. It gets built for relevance, and relevance has no tenant boundary in it. Resolve the owner from your verified caller. Partition on that value. Never let a query widen it. Then write the negative test: a request that should see nothing gets nothing. An index built across users is the classic version. It passes every query-layer review you run, because your leak happened at write time.
Related: How do I evidence that one tenant's data never reached another tenant's agent?, How do I scope an agent so it can only reach the caller's own resources?
Enumerate the copies first. Your deletion evidence is only as good as that list. An agent creates derived data as a side effect. Retrieval indexes. Caches. Conversation history. Tool call logs. Provider-side records. A delete clearing your primary store and nothing else is a partial delete you have described as a complete one. Write down every place data lands during a run. Then say which you can delete, which expire on their own, and which sit with a third party under their terms. Disclose that last group rather than discover it.
Related: How do I evidence that an agent's memory or context store isn't leaking between users?, My model provider changed their terms. What do I actually need to check?
Make the crossing explicit, narrow and recorded, rather than a mode your agent runs in. Broad access with a good reason behind it is still broad access, and refusing it is not your fix. Bind each crossing to a specific case or ticket, so scope comes from that record rather than from a role. Time-box it. Log it apart from ordinary access, because these are the events worth your review. Then decide whether your customer is told. A support path reaching customer data without any of this is what an auditor reaches for first.
Related: How do I scope an agent so it can only reach the caller's own resources?, What does human-in-the-loop have to look like before it counts as a control?