How do we stop an AI assistant revealing one client's information to another?

Separate client information using enforceable access permissions before the AI retrieves it. Do not upload every client's documents into one shared assistant and rely on instructions saying not to mix them. Once confidential information reaches the model's working context, you have already crossed the boundary you were trying to protect.

Think about a small accountancy practice serving two competing businesses. A member of staff may legitimately work on both accounts, but a client-facing assistant serving one business must not inherit that employee's access to the other. The assistant needs a narrower identity and a clear client context established by the application, not by whatever company name someone types into the chat.

That distinction matters when buying a system. Ask the supplier to show what happens before a search: who is signed in, which client they belong to, which records that identity can retrieve, and how those restrictions apply to attachments and connected tools. A reassuring answer about the model being private does not answer these questions.

The UK's NCSC Cloud Security Principles offer a concrete reference. Principle 3 addresses separation between customers: a malicious or compromised customer should not access another customer's data or affect their service. Apply that buying criterion to the complete assistant, not just its hosting platform.

The obvious risk is a shared document library. The less obvious risks are reused conversation histories, cached answers, search indexes, generated downloads and support dashboards. A system may restrict its main database correctly while exposing a previously generated report through an unprotected link.

Ask your supplier to map the whole journey. An uploaded document may be copied into storage, broken into searchable passages, added to an index, included in a model request, written into a diagnostic log and exported as a summary. Every copy needs an owner, an access rule and a retention decision. Deleting the original upload does not demonstrate that every derived copy has gone.

Memory needs particular attention. If an assistant remembers information across conversations, is that memory attached to one user, one client, or the entire organisation? A shared receptionist assistant should not reuse confidential details from an earlier client conversation when answering a new visitor. Starting a fresh visible chat is not proof that the underlying memory has reset.

In practical terms, request a diagram and a demonstration rather than a page of security adjectives. Include failures: what happens if the client identifier is missing, an integration returns too much information, or an employee changes teams? The safe behaviour is to refuse or stop, not search the whole business as a fallback.

Make separation an acceptance condition in the proposal. The supplier should explain how identity, client membership and document permissions are checked on every retrieval and download. Client identifiers must be derived from trusted application state. A question such as 'pretend I work for the other client' must never change authorisation.

Require business-owned administration, named accounts and restricted service credentials. An integration that runs as an all-powerful employee can undermine the permissions people see in the chat interface. For higher-risk work, separate client stores or deployments may make the boundary easier to reason about, although separate hosting alone does not fix a shared administrator or wrongly connected mailbox.

A second specific UK reference is the ICO's data security guidance. It explains that authorised people should act within the scope of the authority given to them, and that organisations should test whether their security measures remain effective. These are useful acceptance criteria, not an assurance that any particular AI product is compliant. The ICO flags this guidance as under review following the Data (Use and Access) Act.

Existing products deserve a fair assessment before you commission a custom build. Microsoft 365 Copilot, an approved business AI workspace or a conventional client portal may meet the requirement with less complexity. None should be assumed suitable without checking its actual connectors, sharing settings and permission behaviour. A local model also needs the same checks.

Use invented clients and synthetic documents for acceptance testing. Give Client A a distinctive fictional project name and Client B a different fictional price. Then test as each client, as an unauthenticated visitor, as a member of staff with restricted access, and as a user whose access has just been removed.

Ask direct questions about the other client, indirect comparisons and requests for 'the previous customer'. Try requesting a summary of every document, guessing a download link and opening a shared conversation from another account. Include malicious instructions inside an uploaded document. The document is information to analyse, not permission to expand the search or send data somewhere else.

Check the evidence behind the answer. A model might refuse to print a secret while still receiving it in retrieved context. That is not successful separation. Your technical reviewer should inspect which records and passages were retrieved, which permissions were enforced and whether logs or citations expose information the visible response hides.

Write down the expected result for each test and retain the outcome. Repeat the relevant tests after changing a connector, permission group, search index, memory setting or model. Passing a test set reduces uncertainty; it does not prove that leakage is impossible. A supplier promising absolute safety from a short demonstration is offering confidence without sufficient evidence.

There is no honest universal price for client isolation. The cost depends on the number of systems connected, how their permissions work, whether customers log in, and the consequences of a mistake. Ask for separate line items for access design, implementation, testing, ongoing reviews and incident support. A licence price alone is not the cost of running a trustworthy assistant.

Here is illustrative arithmetic, not a supplier quote or market benchmark. If an internal reviewer spends four hours testing at an assumed employment cost of £40 an hour, that review represents £160 of staff time. Repeating it after three material changes adds another £480. This excludes engineering, licences and legal advice. The point is to make checking visible in your budget, not to suggest that £160 buys security.

Sometimes the cheapest adequate option is not AI. A searchable client portal with separate folders can solve document access without generating new answers. A staff-only assistant using approved public material may be a sensible first phase while confidential client integration remains switched off.

Use the same discipline when comparing proposals. Ask what happens when a new client is added, who approves access, whether testing is included after changes, and what you pay for export and closure. If the supplier cannot describe those operational obligations, a low setup fee tells you little about the actual commercial risk.

Do not launch a client-facing assistant over confidential files if you cannot reliably identify the user, separate the records and investigate retrieval activity. Where an error could reveal health information, privileged advice or commercially sensitive negotiations, obtain appropriate specialist review before expanding access. A staff-only workflow with human checking may be the better starting point, but internal access still needs controls.

If separation fails, stop the affected route and revoke the relevant access while you investigate. Preserve appropriate logs, identify what was disclosed and to whom, and involve the person responsible for data protection and incident handling. Do not keep testing with real client information or assume that asking the recipient to delete a message resolves the incident.

Assess personal data breach reporting and notification obligations promptly with suitable advice. A confidentiality incident can also involve contractual duties even when it contains no personal data. The right response follows the actual information and harm, not the supplier's preferred description of the event.

The practical buying decision is simple: approve the assistant only when someone can explain and demonstrate its boundaries, own the ongoing checks and switch it off safely. For wider access decisions, see our guide to controlling AI access to email, files and CRM data. If you need help assessing a proposed client-facing assistant, ask for an access-boundary review before committing to the build.