How to Prevent AI Agents From Mixing Client Data

A consultant asks an AI assistant to prepare a status report for Client A. It returns a persuasive summary—but one recommendation comes from Client B's confidential architecture notes. Nobody hacked the system. The assistant received context it should never have seen.

This is a context authorization failure, not necessarily a hallucination or prompt-injection attack. If retrieval joins information from separate clients before enforcing permissions, a well-behaved model can still disclose the wrong material.

The fix begins before the prompt: decide which sources, audiences, agents, and actions are authorized for each task. Here is a practical design for agencies, fractional executives, consulting teams, and others handling confidential workspaces.

1. Understand the dangerous data join

Imagine four collections:

• Client A: contracts, infrastructure notes, meeting decisions.
• Client B: separate contracts, decisions, and technical documents.
• Shared playbooks: methodologies approved for both clients.
• Personal notes: the consultant's private observations.

A naive search index ranks everything by topical similarity. Asked about Client A's deployment plan, it might retrieve a beautifully written deployment checklist from Client B. Once that passage enters a model's context, a prompt telling the model to "respect confidentiality" is a fragile last line of defense.

Instead, compute the authorized source set first. Rank relevant material only within that set. Relevance must never grant access. Apply the rule to semantic search, graph traversal, summaries, memory retrieval, and scheduled agent work—not just chat.

2. Separate storage boundaries from context boundaries

A vault or workspace describes where information lives and who owns it. A context scope defines what a particular audience and task may use. These are different responsibilities.

A consulting firm might maintain an organization workspace but define project-specific context for every engagement. A project scope references authoritative sources without copying note bodies. The access layer checks current identity, workspace membership, source grants, and inherited policy when resolving context.

Phasoric's Context Scopes documentation describes this model: a scope is not another vault or note store. Its contract includes personal, workspace, project, team, and session scope kinds. The documentation labels this capability approved partner preview; do not assume that every described interface is available to all accounts.

3. Share only what the whole audience can access

Joint AI sessions introduce a subtle mistake: taking the union of everyone's permissions.

Suppose a consultant can see private consulting notes plus a shared client brief. The client's project lead can see private client notes plus the same brief. Combining both people's complete access gives the shared agent confidential material neither participant intended to share.

A safer default uses the intersection: the joint session receives the shared brief, not either person's private collection. Additional sources require an explicit, verified grant to the shared context.

In the Phasoric scope design, server-authoritative membership and grants determine the audience floor. A client cannot supply a convenient list of audience IDs and manufacture new access. The general lesson: an LLM must never be allowed to choose its own effective audience.

4. Define the smallest useful source selection

For a new engagement, authorize only the documents required for its immediate task. A practical policy could say:

1. The agent may read an approved project brief and current decision log.
2. It may use common methodology documents expressly shared with that client.
3. It may not read another client's notes, private drafts, or billing documents.
4. It may cite retrieved material but cannot promote chat output to trusted shared memory.
5. It may draft deliverables, but external sending requires separate approval.

Use stable resource identities and verified permissions. A folder name alone is insufficient if users can rename or move files.

Phasoric's developer guide describes explicit hosted-source selection by mapping and individual notes or a whole vault. Whole-vault selection also authorizes future notes. For a narrow task, a few approved sources are preferable to granting an entire growing collection.

5. Make policy inheritance restrictive

Authorization often spans organization, workspace, project, agent, and session levels. A child should be allowed to tighten a parent policy, never silently loosen it.

A project agent may require more review than the organization's default. It must not gain an external-send capability prohibited by the organization.

Keep three permission dimensions separate:

• Evidence: what source classes and records may be read.
• Memory: whether an observation may become reusable knowledge.
• Actions: what may be written, sent, or automated.

This avoids the common workaround of granting write permission because a read returned nothing. Reading and modifying knowledge are different rights. The Phasoric MCP guide distinguishes read and write scopes while retaining account, mapping, and authorization checks.

6. Never turn a shared chat summary into trusted memory automatically

Imagine a joint meeting where a client lead asks, "Could we change the pricing?" An AI summary incorrectly states, "The team approved the new pricing." If that summary is automatically stored as permanent truth, later assistants may repeat a decision nobody made.

A safer lifecycle is:

Observation → candidate memory → source and audience references → authorized human review → accepted memory.

Attach the originating session, original evidence, intended audience, and target scope. Reviewers need a chance to reject or correct an interpretation.

Phasoric's architecture describes this separation. Its local adapter documents reviewed memory handling. The same documentation states that hosted shared-memory materialization should remain unavailable until it uses the authoritative permanent-memory protection path. This boundary matters when evaluating present-day capabilities; it should not be marketed as universally shipped.

7. Recheck permission after revocation

Checks performed only when an integration is first connected grow stale. Team members leave, client relationships end, grants expire, and resource ownership changes.

Resolve authority again before each sensitive read and consequential write. If a grant is revoked, the next request must omit that source; an old authorization snapshot should not defeat current access controls.

An audit receipt can record scope identity, effective resource references, policy fingerprint, omitted-source reasons, and agent version. It should not store the forbidden text merely to explain that a source was denied.

Revocation also has limits: it cannot erase information already exported to email or downloaded into a report. Minimize exposure at the source and require review before external delivery.

8. Test denial paths, not just successful searches

An assistant correctly retrieving Client A's brief does not demonstrate isolation. Build a small test matrix:

Test secondary channels too. Can a graph edge reveal a restricted title? Does an error echo forbidden content? Can a scheduled job reuse an obsolete policy? Search isolation is insufficient if another tool leaks the same data.

Repeat these tests when adding connectors, changing roles, or deploying new agent operations.

9. Run a two-client pilot

Create two test clients with a few clearly different documents and one deliberately shared playbook. Ask each agent a question whose answer exists exclusively in the other client's files. Then run a legitimate client-specific question.

Track four outcomes: permitted sources retrieved, forbidden sources excluded, citations returned, and actions requiring approval. A polished answer containing even one forbidden client fact is a failed test.

Hosted versus local boundaries matter. Phasoric's MCP documentation explains that hosted tools operate on authorized internet-reachable mappings; local-only and device-encrypted material cannot be assumed accessible through hosted retrieval. Its client-knowledge use case explores continuity across consulting engagements.

The principle worth keeping

Give an AI assistant only the information its task is authorized to use—not everything its operator could theoretically access.

Start with audience-aware source selection, enforce permissions outside the model, keep policy inheritance restrictive, make memory review separate from retrieval, and test both allowed and denied paths.

If you are evaluating Phasoric, consult the current Context Scopes contract and MCP guide, including the documented preview and plan boundaries, before adopting these workflows in production.