Anthropic Agent 安全边界系列解读：从人工审批与概率防线到确定性环境隔离
原文一：Beyond permission prompts: making Claude Code more secure and autonomous（2025-10-20）
原文二：How we built Claude Code auto mode: a safer way to skip permissions（2026-03-25）
原文三：How we contain Claude across products（2026-05-25）
实践项目：PPT Master
当 Agent 需要读文件、运行命令和访问网络时，常见做法是每个危险动作都询问用户。但三篇文章连续指出了这种模式的局限：提示越多，用户越容易机械批准；而且，即使每次都经过模型或人工判断，也无法保证所有风险都被识别。
Anthropic 给出的演进方向可以概括为：
人工逐次审批
↓ 减少疲劳
模型分类器与输入探针
↓ 承认非零漏判
操作系统、虚拟机、凭据代理与出口控制这不是三选一。本文的中心问题是：概率性模型防线、人工审批与确定性环境边界应该如何分工，哪些风险只能由“Agent 实际够不到什么”来限制。
一、证据范围与术语
本文依据三篇 Anthropic 官方文章梳理其产品与实验，不把文章中的内部数据外推为所有 Agent 系统的通用指标。
PPT Master 部分依据 2026-08-12 核对的仓库快照 4e6ecbc。后文的“已有”“没有”仅描述该快照，不代表运行它的所有 IDE、云服务或 Agent 宿主都具有相同行为。
先区分四个概念：
| 概念 | 回答的问题 |
|---|---|
| 用户授权 | 用户是否真的同意这项具体行动 |
| 模型防线 | 某个输入或动作看起来是否危险、越权或受注入影响 |
| 环境隔离 | 即使判断失误，进程实际上能访问和改变什么 |
| Blast radius | 一次失败在最坏情况下能够造成多大影响 |
一个审批弹窗可以记录用户点击了“允许”，但不能让进程自动失去对其他目录的读取能力；一个分类器可以降低危险动作被执行的概率，但不能把概率变成零。
二、第一步：为什么人工审批会失去信号
Sandboxing 文章描述的初始模型很直观：Claude Code 默认只读，修改文件或运行大多数命令前请求许可。
这种方式的优势是把决策交给用户，问题则是高频提示会同时降低效率和判断质量。Anthropic 将其称为 approval fatigue：用户反复看到相似对话框后，越来越倾向于直接批准。
Auto Mode 文章给出的内部遥测是，Claude Code 用户批准了约 93% 的权限提示。这一数字只描述 Anthropic 的观测，但它揭示了一个结构性问题：
每次动作都询问
≠ 每次动作都得到认真、独立的风险判断人工审批仍然不可替代的部分
审批疲劳不意味着“不要人工确认”。人工仍然最适合处理：
- 目标本身含糊，但动作不可逆；
- 会影响生产系统、共享资源或其他人；
- 需要跨越既定信任边界；
- 风险取决于业务语境，而不是命令表面。
真正需要减少的是低信号、重复且用户无法有效判断的提示，而不是把所有高风险决定自动化。
三、第二步：Sandbox 用确定性边界换取更少提示
Sandboxing 文章提出的核心变化是：不要为边界内每个动作单独询问，而是预先限定 Agent 可以活动的区域。
1. 文件系统与网络必须同时限制
文章给出两个相互补充的边界：
| 边界 | 主要作用 |
|---|---|
| 文件系统隔离 | 只允许访问或修改指定目录，避免读取敏感文件或改变系统区域 |
| 网络隔离 | 只允许连接批准的服务，避免外泄数据或下载恶意内容 |
只做其中一个是不完整的：能读敏感文件但不能直接联网，仍可能通过获准通道泄露；不能读宿主敏感文件但可任意联网，也可能下载并运行攻击载荷或攻击可见资源。
Claude Code 的本地方案使用 macOS Seatbelt、Linux bubblewrap 等操作系统能力限制进程，并通过 sandbox 外部代理控制网络。文章报告在其内部使用中，permission prompts 减少了 84%。
这里的重点不是 84% 这个具体数字，而是边界模式发生了变化：
边界内：允许连续工作
越过边界：阻止或询问2. 凭据不应与生成代码放在同一执行环境
文章对 Claude Code on the web 的设计说明更进一步：隔离 sandbox 内不放 Git 凭据或签名密钥，Git 操作通过外部代理验证目标、分支和仓库后再附加真实认证信息。
这条原则比“提醒模型不要读取 token”更强，因为模型和生成代码从环境中根本拿不到原始凭据。
3. 早期文章的强结论需要被后续文章校准
Sandboxing 文章把文件与网络隔离描述为即使 Prompt Injection 成功也能限制伤害。2026 年的 Containment 文章随后展示了更复杂的失败：获准域名本身可能暴露上传能力，信任弹窗之前的配置解析也可能执行代码。
因此，更准确的理解不是“有 sandbox 就安全”，而是：sandbox 把风险转化为边界设计问题；边界漏掉的能力，仍然可以成为攻击路径。
四、第三步：Auto Mode 用模型判断减少审批摩擦
Auto Mode 文章试图在两个极端之间找到中间位置：
- 手工批准每个动作，摩擦高且会疲劳；
--dangerously-skip-permissions完全取消提示，几乎没有保护。
Auto Mode 在持续配置 sandbox 不现实或维护代价过高的环境中提供模型层补位；它旨在比完全跳过权限更安全，但不提供与文件系统、网络和凭据隔离等价的确定性边界，仍然保留残余风险。
1. 两条相互独立的检查路径
Auto Mode 同时观察 Agent 读到什么和准备做什么：
| 路径 | 输入 | 作用 |
|---|---|---|
| Prompt-injection probe | 文件读取、网页、shell 输出、外部工具结果 | 在可疑内容进入主 Agent 上下文时增加警告 |
| Transcript classifier | 用户消息和待执行的工具调用 | 判断动作是否危险、是否得到用户授权 |
分类器有意不读取 Agent 自己的解释和工具结果，只看用户说了什么、Agent 实际准备执行什么。这减少了攻击内容和 Agent 自我辩护影响裁决的机会。
代价也很明确：当某个参数来自此前查询时，分类器可能无法判断它是可靠发现还是 Agent 自己猜出的目标。
2. 威胁不只来自恶意模型
原文把危险动作来源分成四类：
- 过度积极：理解目标，却采取了用户没有授权的额外动作；
- 诚实错误：误判资源范围或动作影响；
- Prompt Injection：外部内容劫持 Agent；
- 模型失准：模型追求与用户不同的目标。
这套分类很实用，因为许多真实风险来自“想帮忙但跨过边界”，而不是模型表现出明显恶意。
3. 判断授权必须关注影响范围
Auto Mode 的规则强调：动作与用户目标相关，不等于动作已经被授权。
例如，“清理分支”不自动授权批量删除远程分支；“修一下这个问题”也不自动授权跳过部署检查。分类器需要判断用户同意的是否是 这项动作及其 blast radius。
这也是模型判断最困难的地方。授权经常以自然语言表达，措辞相似却可能对应完全不同的影响范围。
4. 两阶段分类器仍然存在漏判
文章给出的部署评估中，两阶段完整管线在 10,000 条真实内部流量上的误拦率为 0.4%；在 52 条真实 overeager actions 样本上的漏判率为 17%。
这两个数字必须连同样本范围一起理解：
- 较低误拦使长期任务不至于频繁中断；
- 17% 漏判说明仍有危险动作会被当成已获授权；
- 原文明确说，Auto Mode 不是高风险基础设施上谨慎人工复核的直接替代品。
被拒绝的动作会返回 Agent，让它尝试更安全路径；连续或累计拒绝超过阈值后再升级给人类。这样，偶发误拦不必直接杀死整个长任务。
五、第四步：Containment 把问题从“会不会做”改成“能做到哪”
How we contain Claude across products把前两篇的局部机制放到完整威胁模型中。
1. 三类风险与三处防线
文章区分三类风险来源：
- 用户误用或恶意使用；
- 模型误行为；
- 通过工具、文件、网络或运行时进入的外部攻击者。
对应的防线则落在三个部位：
| 防线 | 能做什么 | 不能保证什么 |
|---|---|---|
| 环境 | 用 sandbox、VM、文件边界和出口控制设定硬上限 | 无法自动判断业务目标是否合理 |
| 模型 | 用提示、训练、probe 和 classifier 改变行为概率 | 无法保证零漏判 |
| 外部内容与工具 | 限制工具权限、检查返回内容和供应链 | 可信工具仍可能返回被污染的数据 |
文章的核心判断是：模型层防线可以很强，但仍然是概率性的，因此不能单独承担最坏后果控制。
2. 三种产品对应三种隔离模式
Anthropic 按用户、环境和任务差异采用不同模式：
| 产品情境 | 隔离模式 | 主要交换 |
|---|---|---|
| claude.ai 代码执行 | 服务端临时容器 | blast radius 小，但无持久工作区和本地文件访问 |
| Claude Code | 本地 HITL + OS sandbox | 能力强、延迟低，但依赖技术用户理解并监督 |
| Claude Cowork | 本地 sealed VM | 为非技术用户提供更硬边界，但成本和启动复杂度更高 |
这说明隔离强度不能脱离用户能力讨论。要求普通知识工作者判断复杂 Bash 命令，不是有效的人类监督设计。
3. 后续事故揭示的边界漏洞
Containment 文章公开了多类值得迁移的教训。
信任确认之前也可能有执行面
项目打开、配置加载和 localhost listener 看起来像本地初始化，但如果它们在用户确认信任前解析不可信项目内容，就已经跨过了边界。
边界应建立在解析或执行不可信配置之前，而不是只保护主要工具调用。
用户本人也可能携带注入内容
一次受控红队实验中，研究者诱导员工粘贴包含凭据读取和外传步骤的任务。因为指令看起来来自用户，依赖“锚定用户意图”的模型防线难以识别。
这类场景最终依赖文件边界和出口控制：无论谁提出要求，进程都读不到目标凭据或无法向外发送。
域名 allowlist 实际上是能力授权
Cowork 的一次问题中，api.anthropic.com 是正常获准域名，但攻击者提供的 API Key 让文件可以上传到攻击者账户。域名过滤正确工作，数据仍然外泄。
由此得到的关键判断是：允许一个域名，不只是允许“连接这个地址”，而是在授予该域名所有可达 API 能力。出口控制必须考虑身份、方法、目标账户和请求语义。
隔离也会降低可观测性
完整 VM 能把 Agent 与宿主隔开，也会让宿主上的 EDR 难以观察 VM 内部。安全边界增强并不意味着所有安全维度同时增强；隔离、可观测性和运维成本需要一起设计。
六、三类防线的正确分工
综合三篇文章，可以形成下面的责任表：
| 决策 | 最合适的承担者 | 原因 |
|---|---|---|
| 这个高影响目标是否是用户真正想要的 | 人工授权 | 需要业务语境和责任判断 |
| 某段内容或动作是否呈现注入、越权或异常模式 | 模型 probe / classifier | 可以在大量动作上低摩擦筛查 |
| 即使所有判断都失败，进程最多能触及什么 | 环境边界 | 需要操作系统、VM、网络和凭据层的确定性执行 |
| 工具能对哪个账户、资源和动作生效 | 最小权限与代理 | 域名级允许不足以表达能力范围 |
三者应该叠加，而不是互相替换：
用户确认目标与例外
+ 模型层筛查高频输入和动作
+ 环境层限制最坏后果
+ 工具与凭据按最小范围授权七、PPT Master 当前有哪些“门”，它们保护什么
以下核对基于 PPT Master 4e6ecbc 的 AGENTS.md、Skill 入口、Generate 工作流、Failure Recovery和技术设计。
1. Default 的确认门是产品决策门
PPT Master 的全局纪律默认要求在 ⛔ BLOCKING gate 等待用户明确确认，并禁止跨越未关闭的阶段、缺少前置制品时继续、或提前准备后续制品。Default Generate 也允许用户明确委托 Agent 完成相应决策；委托本身是用户授权，不是 Agent 自行越过确认门。
Default Generate 的 Confirm UI 或聊天确认负责：
- 沟通目标与模板选择；
- 设计方向、页数和阅读方式；
- 图片来源、公式策略和生成模式；
- 讲者备注、动画和旁白等生产选择。
除非用户已经明确委托相应决策，这些门会阻止 Agent 代替用户决定演示文稿身份和生产合同。它们主要保护的是 需求与制品一致性，不是操作系统安全。
2. Confirm UI 不是硬授权执行面
failure-recovery.md 明确规定，Confirm UI 启动失败时可以回退到聊天确认。这个设计是正确的可用性策略，同时也说明 UI 是确认信息的便利载体，而不是不可绕过的安全执行器。
更准确的权威链是：UI、聊天或明确委托形成最终确认状态；design_spec.md 保存完整、可读的持久方案；spec_lock.md 再保存面向 Executor 的紧凑执行锚点与路由合同。UI 是否运行，不会改变宿主进程对文件系统和网络的实际权限。
3. Quick 的“无确认”不是安全模式
Quick 只有在用户明确请求 quick、fast、跳过策略/确认或直接执行时才进入。进入后，当前主 Agent 自行决定未指定的内容、设计和资源，不运行 Strategist、Confirm UI 或 approval stops。
这是一项交互与可追溯性选择，不是 Claude Code 的 permission mode：
- 它不启用或关闭宿主 sandbox；
- 它不改变文件系统或网络权限；
- 它不等于
--dangerously-skip-permissions； - 它仍必须遵守用户明确的事实、排除项和权限边界。
把 Quick 理解成“更少产品确认的生成路径”才准确。
4. 工作流硬规则可以减少误操作，但不能限制 blast radius
PPT Master 已有多项有价值的过程约束：
- 稳定路径和明确项目目录；
- 生成物有单一所有者，失败回到拥有步骤修复；
- 必需制品缺失时阻断；
- 外部来源移动/复制有范围边界；
- 用户确认值不能为了继续执行而静默降级；
- 主页面生成禁止无上下文委派和批量脚本生成。
这些规则能降低 Agent 误解流程或破坏项目状态的概率。但如果宿主已经给进程广泛的文件和网络访问，它们不能在操作系统层阻止读取其他目录、访问外部服务或接触环境变量。
八、PPT Master 明确不提供的安全能力
PPT Master 的仓库定位是 workflow/skill package，而不是应用、Agent 服务或安全运行时。当前没有实现：
| Anthropic 安全机制 | PPT Master 当前状态 |
|---|---|
| 文件系统 sandbox | 未提供；路径可达范围由宿主决定 |
| 网络隔离与 egress proxy | 未提供；联网能力和域名限制由宿主决定 |
| Prompt-injection probe | 未提供统一输入扫描服务 |
| Transcript action classifier | 未提供 Auto Mode 式命令分类器 |
| VM / ephemeral container | 未创建或调度隔离执行环境 |
| Credential vault / scoped proxy | 未代理 Git、MCP 或第三方服务凭据 |
| 托管 Agent identity | 未定义独立于用户的 Agent principal |
topic-research 在宿主支持且允许时可以把网页抓取放入隔离 worker 上下文，并让 worker 只返回制品与简短回执。这里的“隔离”解决的是主上下文污染和 token 占用，不自动证明 worker 运行在文件系统或网络 sandbox 中。
同样，图片搜索、来源转换、Confirm UI 和 live preview 都是工作流能力；它们运行时继承宿主的权限边界，不会自行建立 Anthropic 文章所述的容器、VM 或凭据代理。
不应混淆
“某个步骤只允许写两个输出文件”是一条 Agent 行为契约；“进程在操作系统层只能写这两个文件”才是确定性权限边界。PPT Master 目前提供前者，后者由宿主决定。
九、对 PPT Master 的采用边界
1. 应继续保持：把高价值确认集中在真正的产品决策上
Default 不要求用户批准每条脚本命令，而是在内容、设计、资源来源和生产行为上设置少量高价值门。这比把大量技术动作都变成确认弹窗更有信号。
确认后，确定性检查器和失败恢复规则负责日常推进；只有真实缺失的人工资产、无法履行的确认值或新的用户决定才重新停下。
2. 应明确表达：安全边界来自宿主
运行 PPT Master 时，用户应根据任务选择合适宿主权限：
- 只开放所需项目目录；
- 非必要时关闭网络或限制目标；
- 不把长期凭据直接放进 Agent 可读环境；
- 对生产、共享资源和不可逆动作保留人工确认；
- 处理不可信来源时使用宿主提供的成熟 sandbox。
这些是部署边界，不应被包装成 PPT Master 已实现的功能。
3. 不应现在实现：仓库内自制 Sandbox 或 Auto Mode
Anthropic 的事故经验反复说明，自建代理、allowlist 和信任组件可能成为最薄弱的一环。PPT Master 当前没有托管多租户 Agent 的需求，也没有证据表明应在演示文稿 workflow 包内部复制一套安全运行时。
更简单的选择是复用宿主已有的文件系统、网络和命令审批机制，并让 PPT Master 保持领域工作流职责。
4. 如果未来变成托管服务，安全设计必须成为独立项目
只有当 PPT Master 未来直接托管执行时，才需要系统回答：
- 工作区以只读、读写还是禁止删除方式挂载；
- 哪些命令和子进程在什么隔离层运行；
- 网络出口按域名、身份、方法和目标账户如何限制；
- Git、云 API 和 MCP 凭据如何留在 sandbox 外；
- 外部来源、子 Agent 结果和持久记忆如何标记信任等级；
- 日志、审计和 EDR 可见性如何保留。
这不是给现有 Skill 增加几条 Prompt 就能完成的能力。
十、我的理解：先限制能力，再讨论自治
三篇文章共同修正了一个直觉：安全自治不是“模型更聪明，所以可以少问几次”。更可靠的顺序是：
- 明确用户真正授权的目标和例外；
- 用模型层筛查大量高频输入和动作；
- 假设人工和模型都可能判断失误；
- 用文件、网络、凭据和工具权限把最坏后果限制在可接受范围。
核心判断
概率防线回答“危险行为有多大概率被发现”，确定性边界回答“没有被发现时最多会发生什么”。真正的安全自治必须同时回答两问。
对 PPT Master 而言，现行确认门、制品所有权和失败恢复已经构成清晰的 工作流治理；其文件系统、网络、命令审批和凭据安全仍属于 宿主运行环境。
保持这条边界，比把每条工作流硬规则都称为“安全机制”更重要。前者让使用者知道还需要在哪里建立防线，后者只会制造并不存在的安全感。