How access works
One shared read rule, workspaces isolated by the database, spaces and sensitivity labels, private items, roles, and why no language model decides who sees what.
Breno's access model is built to be simple to state and hard to get around.
One read rule#
Every way of reading knowledge goes through one shared rule: search, answers, the graph, memory recall, citations, MCP, token REST requests, exports, duplicate detection and the quiz. It is the same code in every place, and a test fails if a new read path skips it.
The rule keeps an item only if all of these hold:
- It is in your workspace.
- If it is in a space, you are in that space (or your role covers it).
- Its sensitivity label is one you are cleared for, including by role grants.
- If it is private ("Only me"), you are its owner.
One write rule#
Every change goes through a matching rule: a role check, plus a space check for the item. Some actions are limited to managers (Owners and Admins): source management, merging entities in the graph and workspace-wide exports.
Workspaces are isolated by the database#
Each workspace's data is separated by row-level security in the database, enforced on every table that holds workspace data. A query that forgot to scope itself to a workspace still cannot return another workspace's rows. Production refuses to start unless this is enforced, with a database role that is not a superuser, and a test fails by name if a table that holds workspace data is neither covered nor deliberately exempt.
No model decides access#
Who may read what is decided by rules, never by a language model's judgement. A model is only ever given text the rule has already let through.
Visibility and sensitivity#
| Control | Values | Set by |
|---|---|---|
| Visibility | workspace, Only me | The item's owner (and Admins, except they cannot make another member's item private). |
| Sensitivity | public, internal, confidential, restricted | The owner or an Admin, and only to labels they are cleared for. |
| Space | A named group of members | Set from the item's page. |
Roles#
Owner, Admin, Member and Viewer, plus a platform-level super admin. Viewers are read-only, and a token cannot give its holder more than the holder's role allows. See Roles and permissions.
Tokens inherit, never exceed#
A personal token sees exactly what its owner sees, and loses access the moment its owner does. See Tokens.
What access does not do yet#
One further caveat is in Known limits: the description of an entity shared across items can still be drawn from an item you cannot read.