> ## Documentation Index > Fetch the complete documentation index at: https://docs.cortex-labs.ai/llms.txt > Use this file to discover all available pages before exploring further. # Understand project sharing boundaries > Understand what sharing a project chat exposes and which context remains protected by separate access rules. This draft describes the intended Arc sharing boundaries. The current source marks shared chats and composers as unfinished. Audience checks and context exclusions need release-build verification before publication. A chat project organises your conversations and selected context. Each chat retains its own access rules. Sharing a chat gives the permitted audience access to that conversation; it does not share the whole project. ## Organising and sharing have different effects Adding two chats to one project lets you organise the same task and reuse selected instructions and files. It does not give the reader of one chat access to the other chat. Project context used in a shared turn must be authorised for that turn's audience. Access held by one participant cannot make private material available to everyone. The interface identifies excluded context without revealing its contents. | Material | What sharing one chat means | | - | - | | That chat's messages, attachments, tool results, and outputs | The audience must be permitted to receive them. Retained context is checked when the audience changes. | | The parent chat project | Sharing the chat does not share the project. | | Other chats in the project | Their individual access rules remain in force. | | Project instructions and reference files | Their inclusion in a shared turn requires authorisation for the receiving audience. Chat sharing does not grant direct access to the project's files. | | Your project memory | It remains scoped to your user and project. Personal memories do not become a shared memory store. | | Workspace content retrieved during research | It needs its own source access and permission to disclose the result to the chat's audience. | ## A shared research chat does not expose the project Suppose your transport project contains a source-research chat, a private planning chat, and a reference file. You share only the source-research chat with a colleague. The colleague does not gain access to the private planning chat or the project merely by receiving that share. The reference file also requires its own checks before its content can be used in the shared conversation. If required context is excluded, the shared answer can have less context than your personal conversation. Check the reported exclusion before assuming the answer used the whole brief. Identify material the audience is permitted to receive before adding it to the shared discussion. ## Co-writing does not combine permissions One user submits each turn. Model and tool operations use that person's current authority, tool eligibility, and limits. Other contributors' permissions are not combined with theirs. For example, your colleague can help draft a question about a project file, but their ability to read it cannot authorise a turn submitted by someone who lacks access. The returned content must also be suitable for the receiving audience. The same rule applies to prior-work search. A participant's access to an earlier conversation does not make its title, snippets, or content available to a shared chat. Search checks both the source and receiving audience. ## Intended audience-change checks These are required sharing boundaries. The unfinished collaboration controls must be checked against the release build before this page can be treated as a description of available interfaces. Adding a participant requires the retained conversation context to be checked for the new audience. Private context must remain protected rather than being exposed through earlier messages, previews, or live updates. Removing a participant blocks subsequent protected reads and writes, including live updates. It cannot recall material already delivered. Changing an audience does not grant review or publication authority. ## A chat project is separate from a workspace A project groups chat context for a user. It does not establish Vantage workspace membership or grant access to workspace data. A workspace's grants do not automatically expose personal chats or project files either. Finding earlier work does not change its owner or grant new access. It also does not turn that work into project memory or transfer an Arc artefact into Vantage automatically. For the sharing procedure, use [Share and co-write a chat](/arc/chats-and-research/share-and-co-write). To choose what later project conversations can use, follow [Use project memory and reference material](/arc/projects-and-context/memory-and-reference-material). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.