yi-ge · Oct 11, 2026 · Oct 11, 2026
diff --git a/docs/02-user-guide/11-security/05-ai-approval.md b/docs/02-user-guide/11-security/05-ai-approval.md
@@ -30,6 +30,29 @@ keywords: [AI 审批, 工具审批, 命令审批, 无人值守, 委派, 权限]
 
 对于原本以目标智能体作为审批设置来源的跨智能体资源操作，有人或无上级时仍保留该原来源；只在真实无人委派中采用直接上级设置。
 
+## 文件访问与审批独立设置
+
+在聊天输入框的审批胶囊或资源面板中，可以一起快速选择审批模式和**文件访问**。智能体详情的审批选择器及配置表单也提供对应设置。文件访问默认“无限制”；已有受限配置保持受限，选择成功后在下一轮生效。这项能力需使用包含该变更的客户端版本。
+
+| 文件访问选项 | 工作区内读写 | 工作区外读取 | 文件工具工作区外写入 |
+|---|---|---|---|
+| **无限制**（默认） | 允许 | 允许 | 允许 |
+| **读写限工作区** | 允许 | 拒绝，已有只读授权除外 | 拒绝，旧显式目录引用的读写授权除外 |
+| **工作区可读写、工作区外只读** | 允许 | 允许 | 拒绝；引用外部目录只增加读取权限 |
+
+所有“允许”仍受敏感路径、平台资源授权、团队隔离和本次运行的权限上限约束。平台记忆等基础数据沿用原授权。工作区由已配置的工作目录决定；要通过文件工具修改外部项目，先把它明确加入工作区。
+
+| 操作 | 新“工作区外只读”选项下的行为 | 审批 |
+|---|---|---|
+| 工作区内读取 | 允许 | 保持现状 |
+| 工作区内写入、编辑 | 允许 | 继续按当前审批模式；可写不代表免审批 |
+| 工作区外读取 | 允许普通文件，敏感路径继续保护 | 保持现状 |
+| 文件工具工作区外写入 | 拒绝 | “全部放行”、AI 或人工批准均不能扩大文件范围 |
+| Bash、PowerShell、终端及外部执行器 | 执行权限保持现状 | 命令规则、审批和管理员提权照旧 |
+| 无人委派 | 使用执行方文件范围及本次权限上限 | 普通审批仍读取直接上级设置 |
+
+文件访问选项控制文件工具，**不提供命令进程的文件系统隔离**。已批准的命令仍可能写到工作区外。临时 Worker 和已创建的后台任务保留原权限上限，不因选择新档位自动扩权。旧配置 `restrictToWorkDirs=true` 保持“读写限工作区”，省略/false 保持“无限制”；显式 `file_security.accessMode` 优先，七种审批模式及无人转换规则不变。
+
 ## 七种模式如何生效
 
 下表用于普通工具与命令审批。记忆规则、命令白名单命中和原有免批操作先按各自规则处理。

diff --git a/docs/04-concepts/12-agent-permission-boundary.md b/docs/04-concepts/12-agent-permission-boundary.md
@@ -8,7 +8,7 @@ keywords: [权限, 边界, 委派, 协作, 安全, 责任, Permission, Boundary]
 
 ## 一句话规则
 
-**每个智能体做事时，只受它自己的权限上限约束；如果发生越权，责任在执行操作的那个智能体，而不是发起请求的那一方。**
+**每个智能体做事时，受它自己的权限配置与本次运行已授权范围共同约束；如果发生越权，责任在执行操作的那个智能体，而不是发起请求的那一方。**
 
 ## 为什么需要这条规则
 
@@ -32,7 +32,7 @@ keywords: [权限, 边界, 委派, 协作, 安全, 责任, Permission, Boundary]
 
 **谁动手，就按谁的权限算。**
 
-- 乙同伴收到甲同伴的请求后，仍然完整地按**它自己**被授予的权限行事：它能读什么、能写什么、能调用哪些工具，只看它自己的配置。
+- 乙同伴收到甲同伴的请求后，按**它自己**被授予的权限和本次运行已有上限行事：它能读什么、能写什么、能调用哪些工具，由它自己的配置与本次运行的权限范围共同决定。
 - 甲同伴无法通过"请乙帮忙"这个动作，让乙做出超越乙自身权限的事 -- 因为乙的权限本来就是它的天花板。
 - 反过来，甲也无法通过"请乙帮忙"给自己扩权 -- 乙做的事记在乙的账上，产出回到甲手里，但**执行发生在乙的边界内**。
 
@@ -66,7 +66,7 @@ keywords: [权限, 边界, 委派, 协作, 安全, 责任, Permission, Boundary]
 
 - **你的授权仍然是唯一的来源。** 同伴的权限从来只由你配置，同伴之间不能互相授予权限，也不能通过协作绕开你的设置。
 - **[三层可控性](./three-layer-control) 完整生效。** 不管这一轮是你发起的还是别的同伴发起的，高风险操作照样触发人闸门、照样有回执、照样可回滚。
-- **边界更容易检查。** 你只需要回答"我给这个同伴开了什么权限"，而不需要在脑子里模拟"如果它被某个别的同伴调用，权限会变成什么样"。
+- **边界更容易检查。** 你只需要回答"我给这个同伴开了什么权限"，同时核对本次委派、团队和后台任务已有的权限上限。
 
 如果你不希望某个同伴具备某种能力，正确的做法是**收紧它自己的权限配置** -- 而不是指望别的同伴在调用它时替你把关。
 
@@ -93,3 +93,7 @@ keywords: [权限, 边界, 委派, 协作, 安全, 责任, Permission, Boundary]
 - 想了解整体的安全保障？请阅读 [三层可控性](./three-layer-control)
 - 想理解同伴之间如何协作？请阅读 [委派式交互模型](./delegation-model)
 - 想了解任务如何被分配给合适的同伴？请阅读 [智能任务编排](./task-orchestration)
+
+## 文件访问范围
+
+执行方可选择默认“无限制”、“读写限工作区”或“工作区可读写、工作区外只读”。它与七档审批独立：可写操作仍按原审批模式处理，批准不能扩大文件范围。平台资源专用授权、父级文件 ceiling、团队隔离和后台创建时冻结的上限继续约束本次运行；临时 Worker 保留原收窄规则。命令执行权限保持现状，这项文件工具设置不提供命令进程沙箱。配置兼容、快捷入口和完整组合表见[审批与文件访问](../02-user-guide/11-security/05-ai-approval.md#文件访问与审批独立设置)。
diff --git a/...usaurus-plugin-content-docs/current/02-user-guide/11-security/05-ai-approval.md b/...usaurus-plugin-content-docs/current/02-user-guide/11-security/05-ai-approval.md
@@ -30,6 +30,29 @@ Attendance is determined by the run entry and calling relationship: whether the
 
 Cross-Agent resource operations that previously read the target Agent's settings retain that original source when attended or without a parent. Only genuine unattended delegation uses the immediate parent's settings.
 
+## File access is independent of approval
+
+The approval pill in the chat composer and the resource panel offer quick choices for both approval mode and **file access**. The agent detail approval picker and configuration form also expose the setting. File access defaults to **Unrestricted**; existing restricted configurations remain restricted. A successfully saved choice applies on the next turn. This capability requires a client version containing the change.
+
+| File access option | Read/write inside the workspace | Read outside | Write outside with file tools |
+|---|---|---|---|
+| **Unrestricted** (default) | Allowed | Allowed | Allowed |
+| **Workspace only** | Allowed | Denied except existing read grants | Denied except legacy explicit directory read/write grants |
+| **Workspace read/write, outside read-only** | Allowed | Allowed | Denied; referencing an outside directory only grants reading |
+
+All allowed operations remain subject to sensitive path protection, platform resource grants, team isolation and the current run's permission ceilings. Platform data such as agent memory retains its existing grants. Workspaces come from configured work directories; explicitly add an outside project before modifying it with file tools.
+
+| Operation | With the new outside read-only option | Approval |
+|---|---|---|
+| Read inside the workspace | Allowed | Unchanged |
+| Write or edit inside the workspace | Allowed | Existing mode still applies; writable does not mean approval-exempt |
+| Read outside | Ordinary files allowed; sensitive paths remain protected | Unchanged |
+| Write outside with file tools | Denied | Allow-all, AI and human decisions cannot expand file scope |
+| Bash, PowerShell, terminals and external executors | Existing execution permissions | Command rules, approval and elevation remain unchanged |
+| Unattended delegation | Executor's file scope and the current run's ceilings | Ordinary approval still uses the immediate parent's settings |
+
+This option controls file tools; **it does not isolate the filesystem access of command processes**. Approved commands may still write outside the workspace. Temporary Workers and already-created background tasks retain their existing ceilings rather than gaining authority from the new selection. Legacy `restrictToWorkDirs=true` remains Workspace only; omission/false remains Unrestricted. Explicit `file_security.accessMode` takes precedence. The seven approval modes and unattended mappings do not change.
+
 ## Seven approval modes
 
 This table describes ordinary tool and command approval. Remembered rules, command allowlists, and existing non-gated operations are evaluated according to their own rules first.

diff --git a/...usaurus-plugin-content-docs/current/04-concepts/12-agent-permission-boundary.md b/...usaurus-plugin-content-docs/current/04-concepts/12-agent-permission-boundary.md
@@ -8,7 +8,7 @@ keywords: [permission, boundary, delegation, collaboration, security, accountabi
 
 ## The rule in one sentence
 
-**Every agent acts within its own permission ceiling. If something is done that shouldn't have been, accountability lies with the agent that performed the action -- not with whoever asked for it.**
+**Every agent acts within its own configuration and the authorized scope of the current run. If something is done that shouldn't have been, accountability lies with the agent that performed the action -- not with whoever asked for it.**
 
 ## Why this rule is needed
 
@@ -32,7 +32,7 @@ It sounds safer, but it falls apart immediately in real use:
 
 **Whoever acts is bound by their own ceiling.**
 
-- When companion B receives a request from companion A, it still acts entirely within the permissions **you** granted **B**: what it can read, what it can write, which tools it may call -- determined solely by B's own configuration.
+- When companion B receives a request from companion A, it acts within the permissions **you** granted **B** and the current run's existing ceilings: what it can read, what it can write, which tools it may call -- determined by B's configuration together with the run's authorized scope.
 - A cannot make B exceed B's own ceiling by asking, because that ceiling is absolute.
 - Conversely, A cannot expand its own reach by asking B. Whatever B does is recorded against B, and the results come back to A -- but **the execution happened inside B's boundary**.
 
@@ -93,3 +93,7 @@ Unattended delegation reads the immediate parent's approval mode and remembered
 - Want the full picture on safety? Read [Three-Layer Controllability](./three-layer-control)
 - Want to understand how companions collaborate? Read [Delegation Model](./delegation-model)
 - Want to know how work is routed to the right companion? Read [Task Orchestration](./task-orchestration)
+
+## File access scope
+
+The executor can choose Unrestricted (default), Workspace only, or Workspace read/write with outside read-only. This setting is independent of the seven approval modes: writable operations still follow the existing mode, and approval cannot expand file scope. Platform resource grants, parent file ceilings, team isolation and ceilings frozen when background tasks were created still constrain the run. Temporary Workers retain their existing narrowing rules. Execution permissions remain unchanged; this file-tool setting adds no command-process sandbox. See [approval and file access](../02-user-guide/11-security/05-ai-approval.md#file-access-is-independent-of-approval) for compatibility, quick controls and combination tables.