Brain Document Access（权限继承）

背景：Brain 的两层访问控制

Brain 访问控制分两层，Document access 是第二层。默认 source scope 是唯一门禁：能看到源的人能检索源里一切。Document access 让 Google Drive 源可进一步按每份文档自己的 Drive 权限约束检索。

┌──────────────────────────────────────────────────────────────────────┐
│                  Brain 访问控制 — 两层模型                             │
├──────────────────────────────────────────────────────────────────────┤
│  第 1 层：Source scope（所有源都有）                                   │
│  ┌──────────────────────────────────────────────────────────────┐   │
│  │  决定"谁能看到并搜索这个源"：Personal / Team / Organization     │   │
│  └──────────────────────────────────────────────────────────────┘   │
│         │  默认：scope 是唯一门禁                                       │
│         ▼                                                             │
│  第 2 层：Document access（仅 Google Drive 源，v10.10.0 新）            │
│  ┌──────────────────────────────────────────────────────────────┐   │
│  │  Gumloop access（默认）/ Original source（权限继承）             │   │
│  └──────────────────────────────────────────────────────────────┘   │
└──────────────────────────────────────────────────────────────────────┘

两种模式

目标

1. 消除数据越权——检索结果不含用户在源系统无权查看的机密文档
2. 尊重源系统 ACL——Brain 检索权限与企业既有文档权限对齐
3. 通过企业安全审查——满足 SOC2/ISO27001 对"AI 检索尊重源 ACL"的要求
4. Fail-closed 保守姿态——宁可漏检，不可越权

2.1 同步时快照 + 检索时强制

「Original source」分两阶段工作：同步时快照每份文档的 Drive 权限（按邮箱）；检索时按用户连接的 Google 邮箱逐文档检查快照。权限不是实时查 Drive，而是同步快照——Drive 权限变更要等下一次同步才生效。

┌──────────────────────────────────────────────────────────────────────┐
│  阶段 1 — 同步时（Sync time）：权限快照                                 │
│  Gumloop 读取每份文档，快照其当前 Drive 权限（谁有访问权，按邮箱）        │
│         │  权限快照随索引一起存储                                        │
│         ▼                                                             │
│  阶段 2 — 检索时（Search time）：逐文档强制                             │
│  用户检索 → 对每个候选文档检查该用户是否有权                              │
│  匹配依据：用户【连接的 Google 账户邮箱】                                 │
│         │                                                             │
│    ┌────┴────┐                                                        │
│    ▼         ▼                                                        │
│   有权       无权                                                      │
│    │          │                                                       │
│    ▼          ▼                                                       │
│  返回内容   文档不浮现（fail-closed）                                    │
└──────────────────────────────────────────────────────────────────────┘

2.2 Fail-closed 设计（关键安全姿态）

Gumloop 原则："fails closed rather than over-share"（宁可少给也不过度分享）。并非所有 Drive 授予方式都能被强制：

2.3 模式切换触发重新同步

改变源的 Document access 设置会排队重新同步，按新模式重新快照权限。切到 Original source → 重新快照所有文档权限；切到 Gumloop access → 丢弃快照、回到 scope-only 门禁。

2.4 支持范围（Google Drive + Salesforce）

Document access 选项只出现在支持它的源上。当前支持 Google Drive 与 Salesforce（v10.23.0 起）；其他源（Notion/Slack/GitHub/Confluence/Zendesk/文件上传）始终用 Gumloop access。Gumloop access 模式下不检查逐文档权限——能看到源的人能检索源里任何内容，文档建议把此类源 scope 到预期受众。

2.5 Salesforce 记录权限（v2.0 · v10.23.0）

Salesforce 是第 8 个 native source（CRM 域首个）：同步 CRM records + Knowledge articles，object 粒度勾选；每条 record 一个文档，字段值带标签索引为文本，ID/系统时间戳/复合字段剔除。权限继承比 GDrive 更深一层：

• 权限每次 sync 重新快照——Salesforce 里的授权变更在下一次 sync 后生效于 Brain
• 评分（本更新）：7/13（战略2 护城河2 用户1 复杂度2 创新0）——CRM 是企业数据合规门槛最高的域，"每记录一文档 + 字段级权限快照"复检了 v1.0 架构的可复用性

模块 A — Document access 配置

模块 B — 权限快照与强制

模块 C — 模式切换