Knowledge base access and sharing between organizations
Who in an organization sees and changes a knowledge base, what the owner, the administrator and the main administrator do, how to give another organization read-only access to a base, how to revoke it and what goes into the audit.
A knowledge base belongs to an organization (tenant), and the rights to it are determined by the role of a member in that organization. This article describes the access model inside an organization and the sharing of bases between organizations in the "Read only" mode. The general role model is described in the article Organizations, roles and access.
Access inside an organization
All members of an organization see all of its knowledge bases: the list of bases, the documents, the chunks and the "Retrieval testing" tab. The current interface has no separate switch between a "personal base" and a "team base"; the permission field with the values me and team is kept in the API for compatibility, but it does not restrict the visibility of bases inside an organization.
| Action | Who can do it |
|---|---|
| Viewing bases, documents and chunks, checking search, using a base in chat | Any member of the organization |
| Uploading, processing, turning on and off and deleting documents, editing chunks and metadata | Any member of the organization that holds the base |
| Creating a base, changing the name, description and processing settings, deleting a base | The owner or an administrator of the organization |
| Any actions in any organization | The main administrator of the system |
After switching to a specific organization in the console, the main administrator sees only its bases; without switching, the resources of all organizations are available. You can restrict access to a base for some employees inside an organization at the level of assistants: an assistant is open to everyone or to selected users, and the bases connected to it determine what it sees.
Note
If an employee must not see the documents of a base, do not make them a member of the organization that holds the base. For isolated sets of documents, create separate organizations.
Access for another organization
The main administrator can open a base of one organization for reading to another one without copying the data:
- On the base card, open the menu and choose "Share with tenants".
- Choose the receiving organization and click "Grant access". In the same window, active permissions are withdrawn with the "Revoke" button.
The permission applies to all members of the receiving organization. They see the base with the "Read only" mark and the note "Shared dataset". What the recipient can do: search the base, open and download documents, connect the base to their own assistants and use it in search testing. What the recipient cannot do: upload, rename, reprocess and delete documents, and change chunks, tags, the graph and the settings. The processing and connector configuration of a shared base is not shown to the recipient.
Technical properties of the permission:
- the base, the documents and the index stay with the source organization, and no copies are made;
- the permission is tied to the pair "base, receiving organization" and to the current owner of the base; a transfer of ownership, the deletion of the base or the disabling of one of the organizations ends the access;
- there are no "to everyone" templates, no delegation and no transitive access; the recipient cannot pass the base on;
- only the main administrator can grant and revoke permissions; an organization administrator, a user and an API key of the organization cannot;
- query vectors are built by the embedding model of the source base, while the chat model and the reranker are taken from the settings of the recipient.
Through the API, the main administrator performs the same operations in a user session: GET /v1/kb_share/<kb_id> returns the recipients, PUT /v1/kb_share/<kb_id> with the body {"tenant_id": "..."} grants access, and DELETE with the same body revokes it. The operations are idempotent; granting access to the owner, to a nonexistent organization or to a disabled one is rejected.
Revoking access
Revocation applies to all new checks: the next search, the opening of a document and the next answer of the recipient's assistant will end in a denial. Files that were already downloaded, data that was already read and the conversation history are not deleted. A request whose processing began before the revocation may finish with the data that was accessible at the time of the check.
Warning
Granting a permission opens the base to all current members of the receiving organization, including those who join later. Before granting it, check the membership of the recipient and whether the base contains personal data.
The information security profile, if it is turned on in the installation, keeps a stricter rule: assistants use only the bases of their own organization.
Audit
The action log includes the creation, change and deletion of a base, the uploading and deletion of documents, metadata changes, and the granting and revoking of access for another organization (the events kb.share.grant and kb.share.revoke). The grant and the recording of the event are done in one transaction: if the event cannot be recorded, the permission change is rolled back. The main administrator reads the log in the console at /admin/audit; events are also passed to an external log collection tool, if one is configured.
Before an audit, it is useful to run a negative test: a member of the receiving organization must not be able to upload a document to the shared base, and after the revocation must not see it in the list.
Related materials: What is a knowledge base, Connectors and sync.
Ask Sema