Access Model
In Notarium, access is granted at the space level. Membership in a space with a given role is the unit of access: a member sees everything in that space, a non-member sees nothing. The same model applies to people and to AI agents alike: both get access through one and the same mechanism.
Roles
Space membership is a triple: "space + participant + role." There are three roles:
| Role | Permissions |
|---|---|
reader | Reads everything in the space: notes, search, the graph, the Feed, history, export |
writer | Everything a reader can do, plus creating, editing, and deleting notes |
owner | Everything a writer can do, plus managing the space's membership |
The reader role is truly read-only: the interface hides every write action (create, edit, delete, drag-and-drop, restore from trash), and the server would reject them anyway.
You cannot grant access to only part of a space: to share a subset of notes, you create a separate space. There are no per-note permissions (per-note ACLs) either — access is granted only at the space level.
The Unified Principal
A principal is whoever performs an action: a person with a session, or an AI agent with a personal token (PAT). Both go through one grant mechanism, and every request runs through the same check: "Can this principal perform this action on this resource?"
Effective access is the intersection of two things: what the account allows (the token's permission ceiling) and where the principal has membership. A person's session tops out at management-level actions; an agent's token is capped at read or write. Management actions (issuing tokens, changing membership) sit above the write level, so a leaked agent token cannot grant access or issue a new token. For more on tokens and connecting agents, see Connect an agent and Security and visibility.
Every user has their own personal space that cannot be deleted — a private knowledge base no one else can reach: you cannot invite a second participant into a personal space (the server forbids it).
Managing users and restoring access is a separate layer from reading content. The instance administrator creates users and repairs membership, but to read a space's data they need to be a member of it. Requests made without a grant return the same "not found" response as requests to something that does not exist — so you cannot probe by brute force to discover what exists at all.
Privacy: self-hosting, not E2EE
Notarium is deliberately not an end-to-end encrypted (E2EE) product. A smart server — full-text and semantic search, version history, AI agents at work — by its nature requires access to content in the clear. End-to-end encryption would rule out those features.
So privacy is built differently: you keep the server and the files yourself (self-host), and the data stays as your Markdown files and never leaves your infrastructure. This is a deliberate stance: the privacy guarantee lives in ownership, not in cryptography the server cannot see.
The server sees the content of your notes in the clear — otherwise it could not search across them or hand them to agents. If you need a model where the server cannot read a note at all, Notarium does not offer it. Notarium does not encrypt individual notes on the client side.
Notarium is designed for single-instance self-hosting: it has no open registration and no multi-tenant cloud.
Related topics: Spaces and projects — the units of isolation, The human and the agents — shared access to the knowledge base, Authentication — sign-in modes and tokens.