The short answer
Project labels help organize knowledge; enforced access controls determine who can retrieve it.
Design project scope, access boundaries and negative tests so similar names and shared folders do not mix one client's knowledge into another's work.Similar work creates plausible wrong answers
Two clients use the same supplier. Both have a project called "Phase Two." An agent finds a delivery date and puts it in a client update. The date is accurate, but it belongs to the other client. The sentence looks fine until someone checks the source.
Set the active client and project before retrieval. The agent should not infer scope from a short name when several projects share it. A task packet can state the approved sources and the records that must remain outside the task.
Separate organization from authorization
| Mechanism | What it can do | What it does not prove |
|---|---|---|
| Folder or tag | Make the intended project easier to select. | That another agent cannot read the other folder. |
| Retrieval filter | Narrow results within a supported query. | That the caller cannot remove the filter. |
| Enforced access control | Restrict available data for an identity. | That every downstream export preserves the restriction. |
| Separate workspace | Reduce accidental mixing. | Complete isolation if the agent can still access both. |
Choose controls based on the required boundary. A convention in a prompt is useful context, but it is not equivalent to a permission enforced by the storage or tool layer.
Write an explicit task boundary
Active client: Fictional client Alder
Active project: Phase Two / A-204
Approved sources: The designated Alder project copy
Excluded sources: Other client folders and private notes
Shared supplier facts: Use only explicitly approved public records
Output: Draft update with source references
Uncertain scope: Ask for resolution; do not combine recordsUse stable project identifiers where available. If a fact is deliberately shared, record why it can be reused and which version is approved. Avoid copying private context into a general "common knowledge" file for convenience.
Test the boundary with lookalikes
Build two synthetic projects with the same short name but different dates. Give each a unique harmless marker. Ask for the active project's date, then ask a question only the other project can answer. Inspect retrieved passages and tool access where available.
If the agent has no permission to read the other project, it should not be able to answer from it. An answer that happens not to mention the other client is not proof that the other client's data was inaccessible. Check the actual permissions and logs, not just the final wording.
Review the outputs that leave the workspace
A summary, handoff or exported graph can cross the boundary even when the original sources remain separate. Inspect the export for client identifiers, private passages and links that reveal another workspace. Keep a source trail so reviewers can see why a fact was included.
Repeat the check when you change retrieval tools, access permissions or shared-source policy. A new connector can widen the available data without changing the visible task prompt.
Match the product to the boundary you need
Gigabrain runs locally. If you need separate access controls for each client, you must arrange those in your storage and agent setup. Buying more licences does not add enterprise tenant isolation. Review the operating model and agent access before deciding where to use it.
Use the boundary checklist with synthetic data first. If the supported setup fits your requirements, compare packages for the actual users and workflows.
