---
title: "Access Model"
description: "Space membership, the owner/writer/reader roles, a unified principal, and privacy through self-hosting — not through E2EE."
---

# 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](/docs/agents/connect/) and [Security and visibility](/docs/agents/security/).

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).

> [!note] Host administrator ≠ access to data
> 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.

> [!warning] What this means in practice
> 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](/docs/concepts/spaces-and-projects/) — the units of isolation, [The human and the agents](/docs/concepts/human-and-agents/) — shared access to the knowledge base, [Authentication](/docs/self-hosting/authentication/) — sign-in modes and tokens.