Access control

Access in KobiGPT is defined across two layers. The first is assistant scope: each assistant sees only the documents attached to it and cannot cite another assistant’s files.

The second is user role: which user can talk to which assistant is set by role definition. The two layers work together; neither provides adequate protection alone.

The practical consequence is that the most reliable way to protect a file is attaching it to the right assistant — not attaching it to the wrong one and trying to block access with a role rule.

In an internal assistant the most serious risk is not a wrong answer but a right answer to the wrong person. However good the model, a viewer-level user who can get an answer from the payroll file is a design failure.

This risk is silent: the system raises no error, the user receives a correct answer, and the problem surfaces only when somebody notices. Access control is therefore behaviour that must be tested at setup.

The test is simple: attach a restricted file to an assistant and try to query its content as a user who should not have permission. If an answer comes back, the scope arrangement is not working as expected.

Access rules should be written down before deployment. Which document sets exist, which assistant does each belong to, and which roles can talk to that assistant?

Once those three questions are answered, setup becomes mechanical. Deployments that start without them usually collect every file into one general assistant, after which separation becomes impractical.

Periodic review belongs in the plan too. Scope widens as new files are added; checking occasionally which assistant sees which files prevents access debt from accumulating.