主题精读：Agent 工具权限与沙箱——最小权限、审批流、审计日志与隔离执行 未开始

题记与说明

• 主题：Agent 工具权限与沙箱：最小权限、审批流、审计日志和隔离执行（主题研究）
• 精读日期：2026-11-04
• 方法：检索后全文精读 7 个来源（官方文档 ×2、第三方安全分析 ×1、学术论文 ×1、从业者分析 ×1、治理/审计指南 ×2），交叉比对工业界两个标杆实现（Claude Code、OpenAI Codex CLI）与学术系统（CaMeL）的权限模型、审批设计、审计要求与 OS 级隔离机制。所有引述均来自本次会话内全文抓取（WebFetch 全文摘要抽取），非逐字节对 HTML 原文核对——引述可信度高但个别措辞可能与原始 HTML 有出入，已在各节标注。
• 来源清单（7 个，均已全文精读）：
  1. Anthropic Claude Code 官方文档：*Configure permissions* — https://code.claude.com/docs/en/permissions
  2. Anthropic Claude Code 官方文档：*Configure the sandboxed Bash tool* — https://code.claude.com/docs/en/sandboxing
  3. agent-safehouse.dev（Agent 安全逆向分析站）：*Codex* Agent Investigation — https://agent-safehouse.dev/docs/agent-investigations/codex
  4. Debenedetti et al.（Google DeepMind 等），*Defeating Prompt Injections by Design*（CaMeL），arXiv:2503.18813v2，IEEE SaTML 2026 — https://arxiv.org/html/2503.18813v2
  5. Simon Willison：*Design Patterns for Securing LLM Agents from Prompt Injections*（2025-06-13）— https://simonwillison.net/2025/Jun/13/prompt-injection-design-patterns
  6. Permit.io：*AI Agent Audit Trail: Proving What an Agent Did and Why* — https://www.permit.io/blog/ai-agent-audit-trail
  7. WorkOS：*Best Practices for AI Agent Access Control* — https://workos.com/blog/ai-agent-access-control-best-practices

一、核心问题：这份工作在解决什么问题

LLM Agent 的本质矛盾：模型要干活就需要高权限工具（shell、文件系统、网络、邮件、支付），但模型本身既会犯错、又可能被提示注入劫持——注入者不需要攻破系统，只需要让模型"自愿"调用你已经授权给它的工具。这个主题把矛盾拆成四个可操作的子问题：

贯穿全线的根驱动是提示注入未解决。CaMeL 论文与 Willison 都把这一点作为出发点：

"we believe it is unlikely that general-purpose agents can provide meaningful and reliable safety guarantees."
（我们认为通用型 agent 不太可能提供有意义且可靠的安全保证。）
— Willison 引述的论文判断，*Design Patterns for Securing LLM Agents*

"any exposure to potentially malicious tokens entirely taints the output for that prompt"
（任何对潜在恶意 token 的暴露都会完全污染该 prompt 的输出——包括文本输出和它能发起的工具调用。）
— Simon Willison 的心智模型

既然模型层不可信，安全的锚点就必须下沉到模型之外的机械层：规则引擎、审批人、操作系统内核、审计账本。这就是四层结构的由来。

二、主要主张：四层防御的收敛

七个来源虽然立场不同（厂商文档、学术系统、逆向分析、治理指南），但收敛到同一个四层模型：声明式权限规则 → 人在环审批 → OS 沙箱 → 审计日志。每一层的存在理由都是"上一层可以被绕过"。

2.1 第一层：声明式权限规则（快，但官方自己承认不是安全边界）

Claude Code 的权限规则是三层求值的声明式系统，核心设计是 deny-first：

"Rules are evaluated in order: deny, then ask, then allow. The first match in that order determines the outcome, and rule specificity doesn't change the order."
（规则按 deny → ask → allow 顺序求值，第一个命中的决定结果，规则的具体程度不改变求值顺序。）

"An allow rule can't carve an exception out of a deny rule."
（allow 规则不能从 deny 规则里挖出例外。）

三个值得记录的工程细节：

1. 规则由 harness 而非模型执行："Permission rules are enforced by Claude Code, not by the model."——prompt 和 CLAUDE.md 里的任何话都改变不了允许范围。这是所有可靠权限系统的共同前提：策略点（PDP）必须在模型之外。
2. 裸工具名 deny 是从模型上下文里直接删除工具（如 Bash），模型根本"看不见"这个工具；而带参数的 deny（如 Bash(rm *)) 保留工具但拦截匹配调用。前者更彻底，因为连"尝试-失败-变通"的循环都不会发生。
3. 字符串层规则的天然缺陷被官方文档自己承认：Bash(curl *) 这类 deny 挡不住 /usr/bin/curl 或 sh -c 'curl ...'，文档明说这类模式 "are fragile"，不是安全边界，真要兜底请上沙箱或 hooks。compound command（&&、| 等）要求每个子命令都被允许才能免提示，是对这个缺陷的部分修补。

设置层级也是最小权限的一部分：managed settings（企业管控）最高、任何层级包括命令行参数都不能覆盖——"no other level, including command line arguments, can override a managed permission rule"；跨层冲突一律 deny 赢（"if user settings allow a permission and project settings deny it, the deny rule blocks it"）。bypassPermissions 模式的文档警告与主题直接相关：只该在"isolated environments like containers or VMs"里用。

2.2 第二层：审批流（人在环）——按可逆性分类，且必须 out-of-band

Claude Code 用权限模式（permission modes）把"问不问人"变成显式档位：default（首次使用每工具提示）、acceptEdits（自动接受文件编辑）、plan（只读）、auto（免常规提示但由后台分类器审查 shell/网络动作）、dontAsk（一律拒绝本应提示的调用）、bypassPermissions（跳过提示，仅限隔离环境）。"Yes, and don't ask again" 的保存粒度也有讲究：Bash/域名规则按仓库+命令/域名永久保存，文件修改类批准只在会话内有效——批准的半衰期与动作的可逆性挂钩。

WorkOS 给出审批分类的通用标准，这是七源中对审批流最系统的表述：

按三轴分类动作：reversibility（可逆性）、blast radius（爆炸半径）、sensitivity of data touched（触碰数据的敏感度）。低风险（读、草稿、查询）自动放行；高风险（发送、部署、转账、删除、授权）——"human approval in the loop is a primary control, not a courtesy"（人的批准是主控制，不是礼节）。

两条容易被忽视的硬约束：

"a confirmation prompt that the agent itself renders and answers provides no security at all."
（由 agent 自己渲染、自己应答的确认框没有任何安全价值——被劫持的模型连确认框一起伪造。）

二元的"完全自主 vs 事事都问"都不可取：前者爆炸半径失控，后者会退化成"security theater"——用户形成反射性点"允许"的习惯。

Permit.io 补上审批的证据属性：当策略要求人工批准时，"the approval is part of the authorization evidence, not a side conversation in Slack"——审批人、时间、关联请求必须进入审计账本并共享同一个 trace ID，否则审计时无法证明"策略要求批准 → 某人在某时批准 → 副作用随后执行"这条链。

2.3 第三层：OS 沙箱（机械兜底）——两个标杆实现的共同设计

这是本次精读信息密度最高的部分。Claude Code 与 Codex 的沙箱在互不知会的情况下收敛到几乎相同的设计：

"The Bash sandbox is a boundary that the operating system enforces around the shell commands Claude runs on your machine."
（Bash 沙箱是操作系统对 Claude 所运行 shell 命令强制施加的边界——由内核执行，不由模型遵守。）

"sandbox restrictions still apply even if a prompt injection bypasses Claude's decision-making."
（即使提示注入绕过了 Claude 的决策，沙箱限制依然生效。）

共同设计模式（两实现逐项对照）：

Codex 的进程加固是 Claude Code 文档未展开的一层：ptrace(PT_DENY_ATTACH) 反调试、RLIMIT_CORE=0 禁 core dump、清除 DYLD_*/LD_*（防库注入/preload 注入）、release 版拒绝在系统临时目录下运行 CODEX_HOME。这些防的是"沙箱内进程攻击沙箱本身"。

一个清醒的边界：agent-safehouse 对 Codex 的分析开宗明义——

Codex "sandboxes its own tool calls, not itself — the main Codex process runs unsandboxed; only the shell commands it executes for the AI are sandboxed."
（Codex 沙箱化的是它自己的工具调用，不是它自己：主进程不沙箱，只有它替 AI 执行的 shell 命令被沙箱化。）

Claude Code 同样："The sandbox covers shell commands only."——文件工具、WebFetch/WebSearch、hooks、MCP 服务器全部运行在沙箱之外，只受权限规则约束。两个工业标杆的沙箱都只罩住了最危险但最不可控的攻击面（任意 shell），而不是整个 agent。

2.4 第四层：审计日志——遥测不是证据

Permit.io 的核心区分是本主题对"审计日志"最有价值的贡献：

"Telemetry explains model behavior. AuthZ evidence explains control enforcement."
（遥测解释模型行为；授权证据解释控制是否被强制执行。）

LLM trace 记录模型说了什么，tool trace 记录什么跑了，但两者都证明不了"这个动作在当时的策略版本下、对那个 agent、代表那个用户、针对那个资源是否被允许"。最小证据包（authorization envelope）共九项：agent 身份、人类 principal 或委托链、工具与参数、资源与动作、策略 ID 与版本、决定（allow/deny）与理由、审批记录、时间戳/请求 ID/租户环境、副作用结果。

三条工程规则：

1. 在执行点记录，不是事后补："If you log only after the tool runs, you missed the control point."——授权日志应发生在 PDP 或 MCP 网关这个策略评估点，并与工具 trace、下游变更用共享 correlation ID 串起来。
2. deny 日志反而是控制存活的证明："Explainable deny logs prove the control is active."——只记录 allow 的审计在事后看来等于没有控制。
3. Replay 是重建决策而非重跑模型："does not mean re-running the model with a new temperature"——用同一 principal、agent、工具、资源、策略版本、属性、审批状态重放授权决策，供审计员核对。为此日志必须不可篡改（immutable, append-only）且受到保护——WorkOS 补一刀："A rotated key that still lives in a forgotten log is not rotated"（日志里躺着旧密钥等于没轮换）。

2.5 最小权限的四个粒度：从"少给权限"到"数据级能力"

把七个来源的说法叠起来，最小权限在这个领域至少有四个递进粒度：

1. 工具级：不需要的工具直接从模型上下文删除（裸 deny）。——Claude Code
2. 路径/域名级：写范围 = 工作目录 + 临时目录 + 显式 add-dir；网络 = 空 allowlist 起步；读默认近乎全机但要 deny 掉 ~/.ssh、~/.aws/credentials。——Claude Code 沙箱
3. 身份级：agent 是独立 principal，"should not authenticate by reusing a user's session cookie, OAuth token, or long-lived API key"；用 token exchange（RFC 8693）让结果 token 同时携带 agent 与用户两个身份声明；agent 权限永远不超过 agent 权限与用户权限的交集（confused deputy 防御的核心句式："never exceed the intersection of what the agent and the user are each permitted to do"）；凭证寿命"measured in minutes"。——WorkOS、Permit.io
4. 数据级（能力标签）：CaMeL 给每个值挂 provenance（来自用户/工具/转换）与 allowed readers（可见者集合），依赖图随数据流传播，每次工具调用前对完整依赖图校验策略。例如护照号标记为"只能被受信政府工具处理"，而姓名/电话可以流向订票工具。这是最小权限从资源维度到数据维度的下沉，思想源自 libcap/Capsicum/CHERI。——CaMeL

2.6 根驱动的系统级解法：CaMeL 与六模式

CaMeL 的主张是：与其让模型"识别注入"，不如让注入数据在结构上进不了控制流：

CaMeL "provides an environment where predefined policies prevent unintended consequences caused by prompt injection attacks."

双 LLM 结构：P-LLM（特权）只看用户查询、产出 Python 计划代码，"only interacts with the user query and not the data returned by tools"（工具输出进变量，P-LLM 永远看不到内容）；Q-LLM（隔离）无工具权限，只把非结构化数据解析成 schema，且"the Q-LLM cannot communicate to the P-LLM what information it needs, as this could be a vector for prompt injections"（连"我还需要什么信息"都不能回传，因为那本身就是注入通道）。自定义 Python 解释器维护数据流依赖图，STRICT 模式让控制流块内的语句依赖其条件/迭代对象，封堵条件取图、异常侧信道等位泄漏。

Willison 把这类结构总结为六个约束 agent 循环的设计模式：Action-Selector（LLM 调制的 switch，永不看响应）、Plan-Then-Execute（接触不可信数据前先定计划）、LLM Map-Reduce（子 agent 只回窄输出如布尔值）、Dual LLM（Willison 2023 原始版）、Code-Then-Execute（CaMeL，"an improved version of my dual LLM pattern"）、Context-Minimization。他给 CaMeL 的定位是行业里"第一个可信的、面向工具使用 LLM 系统的方案"，并明确接受代价："We don't have a magic solution to prompt injection, so we need to make trade-offs."（没有魔法解，就必须做取舍——限制 agent 干任意任务的能力。）

三、方法：各来源怎么论证

方法上的互补关系：官方文档告诉你怎么配，逆向分析告诉你配了之后内核里真实发生什么，论文告诉你理论上还能收紧到什么程度，治理指南告诉你怎么向审计员证明这一切有效。

四、数据与证据

CaMeL（唯一有量化基准的来源）：

• 基准：AgentDojo（Workspace/Banking/Travel/Slack 四套件，949 个攻击样本）。
• 安全性：带策略的 CaMeL 在解决 77% 任务的同时实现可证明安全（undefended 系统任务解决率 84%）——用 7 个百分点效用换零注入成功。
• 无策略裸 CaMeL 已见效：Gemini 2.5 Pro 上成功攻击从 300 降到 0；Claude 3.5 Sonnet 上 CaMeL 0 次成功攻击 vs 最佳提示词基线 8 次；GPT-4o mini 的原生 instruction hierarchy 被攻破 276 次，套上 CaMeL 后 0 次。
• 开销：中位任务约 2.82× 输入 token、2.73× 输出 token。
• 成本优化：Q-LLM 换便宜模型（Haiku 配 Sonnet）仅损失 ~1% 效用、省 ~12% 成本。
• 作者自认："No, prompt injection attacks are not fully solved."（侧信道、策略维护负担、用户疲劳、ROP 式 gadget 攻击仍开放。）

Claude Code（文档披露的语义事实）：deny→ask→allow 求值顺序；deny 跨作用域必胜；managed 规则不可被任何层级覆盖；沙箱默认读范围包含 ~/.ssh 与 ~/.aws/credentials（所以必须显式 credentials deny——这是个反直觉的默认）；代理拒绝 loopback 与 169.254.169.254；.git internals 与 .claude 属 protected paths；strict 模式忽略 dangerouslyDisableSandbox；原生 Windows 无沙箱。

Codex（逆向分析确认的代码事实）：Seatbelt profile (deny default) 开头；.git/、.codex/ 自动只读子路径；Linux 三件套 bubblewrap+Landlock+seccomp；网络限制到代理 loopback 端口；env_clear()、kill_on_drop(true) 的子进程孵化；ptrace 反调试 + core dump 禁用 + DYLD/LD 清洗；该报告弱点评估为 "None identified"。

WorkOS / Permit.io（规范性主张，无实验数据）：短时凭证、RFC 8693 委托流、九项证据包、enforcement-point 记录原则、out-of-band 审批原则。注意：这两篇是最佳实践推断，没有量化效果数据支撑（如"审批疲劳导致多少漏批"无实证）。

未验证项（明确标注）：① Reddit 有帖称 Codex 存在两个沙箱逃逸漏洞可致宿主机命令执行——本次未验证原始披露，agent-safehouse 报告结论却是 "None identified"，两者矛盾，以未定论处理；② Codex 的审批策略细节（untrusted/on-failure/on-request/never 档位）出现在检索摘要中，但 agent-safehouse 全文明确"approval policies not covered in this document"，本次未能从一手来源核实，不作主张；③ Claude Code 的 auto 模式分类器细节有专门页面，本次未读。

五、结论

1. 四层模型是行业收敛点，不是某家发明：声明式规则（快、可绕）→ 人在环审批（慢、覆盖不可逆动作）→ OS 沙箱（内核执行、注入绕过决策也出不去）→ 审计（事后证明控制有效）。每层单独都不充分：官方文档自己承认字符串规则 fragile，沙箱只罩 shell，审批会被反射性批准稀释，审计不落在执行点就是废纸。
2. 最小权限正在从"资源粒度"下沉到"数据粒度"：工业界（Claude Code/Codex）停在路径+域名+凭证粒度；学术前沿（CaMeL）已把最小权限做成 per-value 的能力标签与依赖图，代价是 ~2.8× token 开销与策略维护负担。
3. 防自我提权是沙箱设计中最容易被忽视的一课：agent 能改自己的配置/hook/git hooks = 无条件提权。两个标杆都把"agent 可自我修改的面"设为最高保护（.git/.codex/.claude 只读），这个模式应推广到所有 agent 系统。
4. 审计的对象是"授权决策"而非"执行过程"：九项证据包 + 策略版本 + 不可篡改 + 执行点记录 + deny 日志，才构成"控制存在且生效"的可证明命题；LLM trace 和 tool trace 只是遥测。
5. 提示注入决定天花板：在通用 agent 上不做取舍的安全方案目前不存在；可行路径是 Willison 六模式 + CaMeL 式系统结构 + 分层防御，明确牺牲一部分 agent 能力换取可证明边界。

六、局限

来源层面：

• 两个治理指南（Permit.io、WorkOS）是规范性综合，无实证数据；审批疲劳、reflexive approval 的真实发生率在所有来源中都没有量化研究。
• Codex 一侧缺官方审批策略一手文档（本次未读到），其 Windows 沙箱（默认关闭）与 ExternalSandbox 的实际行为依赖第三方逆向，未经厂商确认。
• Codex 沙箱逃逸的 Reddit 报道与 agent-safehouse "None identified" 结论矛盾，本次无法裁决。
• Claude Code 沙箱的对抗性评估（红队结果）不在官方文档中；"sandbox restrictions still apply even if a prompt injection bypasses Claude's decision-making" 是设计承诺而非已发表的攻击测试结论。
• CaMeL 的评估在 AgentDojo 上进行——基准攻击与真实世界注入的分布差异是论文类工作的通病；其作者自己承认侧信道（时序、异常位泄漏、间接推断）未完全关闭。
• 所有 WebFetch 引述经摘要抽取传递，个别措辞可能与原始页面 HTML 有出入（已在方法栏声明）。

主题本身的局限（跨来源综合判断）：

• 四层模型对文件/shell 类工具覆盖最好，对 MCP 工具、hooks 是明显洼地（两者都运行在沙箱之外、只受字符串规则约束）——两个标杆实现共同的剩余风险面。
• 数据级能力标签（CaMeL）要求为每个工具/数据类型写策略，维护成本让它在工业界尚未落地；现有生产系统普遍停留在第 1-3 粒度。
• "agent 沙箱化自己的工具调用而非自身"意味着主 agent 进程的内存、密钥、上下文仍在信任边界内——这是架构性局限而非配置问题。

七、对我的启发

1. 四层模型可直接套用于自己的 agent/工具权限设计：先 deny-by-default（裸工具名 deny 直接从上下文删除），再收路径与域名，高风险动作走审批，全程在策略评估点落审计。判断一个 agent 系统的安全性，先问四个问题：deny 是否赢？审批是否 out-of-band？有没有 OS 层兜底？deny 日志是否存在？
2. "防自我提权"清单：任何 agent 系统都要把 agent 能修改自身的面（配置文件、hook 定义、MCP 注册、启动脚本、git hooks）列为最高保护级。这个检查项在通用安全清单里常缺位，但两个标杆都把它当核心设计。
3. 审批设计的两条铁律：① agent 自己渲染的确认框不算审批；② 按可逆性×爆炸半径×数据敏感度三轴分档，避免"事事都问"退化为反射性放行。审批记录要进证据链（审批人/时间/trace ID），否则事后无法向任何人（包括未来的自己）证明控制有效。
4. 审计日志的实现位置：在策略执行点（网关/PDP）记授权决策九元组，而不是事后从 tool trace 里"整理"审计——"If you log only after the tool runs, you missed the control point."这一条对自己的动态工作流系统（subagent、任务编排）同样成立。
5. 写作素材：Claude Code vs Codex 的沙箱对照表（2.3 节）是现成的对比分析框架；".git 只读防 pre-commit 劫持"和"169.254.169.254 元数据端点封堵"是两个能讲清"为什么需要 OS 层"的具体故事；CaMeL 的"用 7% 效用换可证明安全 + 2.8× token"是"安全-能力权衡"的最佳量化案例。
6. 读安全类系统设计的方法收获：官方文档给语义、逆向分析给事实、论文给上界、治理指南给证据需求——对同一主题取四种视角，才能区分"宣称的设计"与"实际执行的机制"。

附录：关键原文引述备查