> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lighton.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Document Access Management in the Admin Tool

> Document confidentiality is a top priority. For this reason, the platform's admin tool and API are designed to ensure that users can only see and interact with documents they are explicitly authorized to access.

🔒 Document confidentiality is a top priority. For this reason, the platform's admin tool and API are designed to ensure that users can only see and interact with documents they are explicitly authorized to access.

## 🧭 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.

This approach ensures **structural transparency** without ever compromising **data confidentiality**.

***

## ⚙️ 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.

Any unauthorized request returns either an **authorization error** or an **empty response**. This is enforced across **all endpoints** without exception.

***

## 🧱 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**.