---
title: "访问模型"
description: "空间成员资格、owner/writer/reader 角色、统一的主体，以及通过自托管而非 E2EE 实现的隐私。"
---

# 访问模型

在 Notarium 中，访问权限是在空间层面授予的。以某个角色加入某个空间的成员资格就是访问的最小单位：成员能看到该空间中的全部内容，非成员则什么也看不到。同一套模型对人和 AI 智能体一视同仁：二者都通过同一个机制获得访问权限。

## 角色

空间成员资格是一个三元组：「空间 + 参与者 + 角色」。角色共有三种：

| 角色 | 权限 |
|---|---|
| `reader` | 读取空间中的一切：笔记、搜索、图谱、文档流、历史、导出 |
| `writer` | reader 的全部权限，外加创建、编辑和删除笔记 |
| `owner` | writer 的全部权限，外加管理空间的成员资格 |

reader 角色是真正意义上的只读：界面会隐藏所有写入操作（创建、编辑、删除、拖放、从回收站恢复），而且服务器无论如何都会拒绝这些操作。

无法只对空间的一部分授予访问权限：要共享笔记的某个子集，就另建一个独立空间。也没有针对单条笔记的权限（per-note ACL）——访问权限只在空间层面授予。

## 统一的主体

主体就是执行某个操作的一方：持有会话的人，或持有个人令牌（PAT）的 AI 智能体。二者都走同一套授权机制，每个请求都要经过同一道检查：「这个主体能否对这个资源执行这个操作？」

最终访问权限是两件事的交集：**账户所允许的**（令牌的权限上限）与**主体拥有成员资格的范围**。人的会话上限可达到管理级操作；智能体令牌则被限制在读取或写入。管理级操作（签发令牌、变更成员资格）位于写入级别之上，因此即便智能体令牌泄露，也无法授予访问权限或签发新令牌。关于令牌与接入智能体的更多内容，参见[接入智能体](/docs/agents/connect/)与[安全与可见性](/docs/agents/security/)。

每位用户都拥有一个不可删除的个人空间——一个别人无从触及的私有知识库：无法向个人空间邀请第二位参与者（服务器会禁止）。

> [!note] 主机管理员 ≠ 访问数据
> 管理用户、恢复访问权限，与读取内容是彼此分离的两层。实例管理员创建用户并修复成员资格，但要读取某个空间的数据，他必须是该空间的成员。未经授权的请求会返回与请求不存在之物相同的「未找到」响应——这样就无法通过暴力探测来查明系统中到底存在些什么。

## 隐私：自托管，而非 E2EE

Notarium 刻意**不是**一款端到端加密（E2EE）产品。一个「聪明」的服务器——全文与语义搜索、版本历史、运行中的 AI 智能体——就其本质而言需要以明文访问内容。端到端加密将使这些功能无法实现。

因此隐私是以另一种方式构建的：你自己持有服务器和文件（自托管），数据始终是你自己的 Markdown 文件，绝不离开你的基础设施。这是一种刻意的立场：隐私保障存在于所有权之中，而不在于服务器无法读取的密码学。

> [!warning] 这在实践中意味着什么
> 服务器以明文看到你笔记的内容——否则它无法对笔记进行搜索，也无法把内容交给智能体。如果你需要一种服务器根本无法读取笔记的模型，Notarium 并不提供。Notarium 不会在客户端对单条笔记加密。

Notarium 是为单实例自托管而设计的：它没有开放注册，也没有多租户云。

相关主题：[空间与项目](/docs/concepts/spaces-and-projects/)——隔离的单位，[人与智能体](/docs/concepts/human-and-agents/)——对知识库的共享访问，[身份验证](/docs/self-hosting/authentication/)——登录模式与令牌。