🧭 Document Access Rules: Who Can See What?
Regardless of a user’s role or group, access to documents in clear text within the admin tool is strictly conditioned by their relationship to a company and specific workspaces.✅ A user can only see a document in clear text if it is in:
-
The “Company” workspace of their own organization
→ The user can access all documents in the company workspace linked to their company (each user belongs to one and only one company).
→ “Company” workspaces from other organizations are entirely anonymized. -
Their own personal workspace
→ The user can view documents in clear text only in their own personal space.
→ Documents in other users’ personal workspaces are completely anonymized. -
A shared workspace the user is explicitly a member of
→ The user has clear access to documents in workspaces they are associated with.
→ In all other workspaces of their company, documents are anonymized (only the ID is shown, no name or content).
👁️🗨️ What Happens When a User Doesn’t Have Access?
If a user does not have access rights to a document:- They can see that the document exists within the workspace structure (e.g., in a team workspace).
- The document is displayed with:
- Only its unique identifier (ID).
- No visible metadata (title, content, snippets).
- No available actions to consult or open the document.
⚙️ Technical Behavior in the Admin Tool
Each model linked to documents applies conditional filtering functions (“redact functions”) based on the rules above. These functions dynamically determine what each logged-in user is allowed to see.| Model / Admin | Display Rule |
|---|---|
| Chat response | Filters chunk links based on access rights to linked documents |
| Chat session | Shown only if the user has access to the linked documents (M2M relation) |
| Chat message | Message text shown only if the user has proper rights |
| Chunk response links | Filtered based on access to Document Chunk or Vision Chunk |
| Document extract | Displayed only if the user has access to the parent document |
| Collections | Displayed if at least one document is accessible, internal docs filtered |
| Document chunk | Visible only if the user can access the parent document |
| Document | Shown in clear text only if access conditions are met |
| Pipeline event | Displayed only if linked to an accessible document |
| Vision chunks | Filtered based on access to the source document |
| Query suggestions | Generated only from documents the user can access |
🔐 Extended API Security
The same filtering rules apply strictly at the API level. A user cannot:- Access the content of a document they are not authorized to see.
- View metadata of documents they don’t have access to.
- Indirectly query data using unauthorized endpoints.
🧱 Database Storage: A Controlled Necessity
To support platform features like search, agents, and indexing, documents must be stored in the database. All access rights are strictly enforced at the UI level, within the admin tool, and via the API:🔒 A user can never access a document unless explicitly permitted. 👉 However, direct access to the database bypasses these application-level protections.
This is outside the scope of the platform: it is the client’s responsibility to strictly limit database access to a small group of trusted administrators.
✅ Summary
| Document Location | Clear Access Condition |
|---|---|
| Company workspace (same company) | ✅ Yes |
| User’s own personal workspace | ✅ Yes |
| Shared workspace the user belongs to | ✅ Yes |
| Workspace of same company (not a member) | ❌ Anonymized (ID only) |
| Workspace from another company | ❌ Completely hidden |
- 📄 Documents are filtered in real time based on the rules above.
- 👁️🗨️ Inaccessible documents appear anonymized (ID only).
- 🔐 The API enforces the same access logic as the admin tool.
- 🧱 Document storage is required, but DB access must be tightly restricted by the client.