沙箱里的自由——Claude Code 六层纵深防御体系全解

《Claude Code 架构解密》精读笔记 · 第13篇
覆盖章节：第8章全部（8.1-8.9, p.198-227）
主题：六层纵深防御模型、OS级沙箱、命令注入23 Validator、路径遍历防护、SSRF防护、秘密扫描、Unicode消毒、安全与可用性Trade-off

---

导语：当 AI 从"说话"变成"行动"

当 AI Agent 拥有了执行 Bash 命令、读写文件、访问网络的能力，它就从"只会说话的助手"变成了"能真正行动的执行者"。但行动能力是一把双刃剑——同样的 rm 命令既能清理临时文件，也能删除整个项目；同样的 HTTP 请求既能调用公共 API，也能探测内网元数据。

更危险的是，LLM 可能被 Prompt 注入攻击诱导执行恶意操作，而用户甚至不知道这一切正在发生。

Claude Code 用六层纵深防御体系回应这一挑战。每一层都假设上游可能被攻破，独立提供保护。这不是"多加几个 if 检查"——这是一套系统性的安全架构。

---

一、架构图解：六层纵深防御全景

┌─────────────────────────────────────────────────────────────┐
│                    六层纵深防御体系                            │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Layer 6：输入消毒 (sanitization.ts)                         │
│  ── Unicode 不可见字符剥离，防 ASCII Smuggling / Prompt 注入  │
│                                                             │
│  Layer 5：秘密扫描 (secretScanner.ts)                        │
│  ── 28+ gitleaks 规则，阻止 API Key/Token 泄露到团队记忆      │
│                                                             │
│  Layer 4：SSRF 防护 (ssrfGuard.ts)                          │
│  ── HTTP Hook 出站请求的私有 IP 拦截，防云元数据端点访问        │
│                                                             │
│  Layer 3：路径遍历防护 (pathValidation.ts)                    │
│  ── 30 种命令的路径参数验证，防越权文件访问                     │
│                                                             │
│  Layer 2：命令注入防护 (bashSecurity.ts)                      │
│  ── 23 个 Validator 检测解析差异攻击，防 Shell 混淆绕过        │
│                                                             │
│  Layer 1：沙箱隔离 (sandbox-adapter.ts)                       │
│  ── 进程级隔离 (bubblewrap/Seatbelt)，文件系统/网络白名单      │
│                                                             │
│  Layer 0：权限系统 (permissions.ts) [详见第5章]               │
│  ── 规则引擎 + AI 分类器 + 模式管理                            │
└─────────────────────────────────────────────────────────────┘

层号的编排揭示了设计意图：Layer 0（权限系统）是基础，Layer 1（沙箱）是底线，Layer 2-6 是纵深。即使上层所有应用级检查全部被绕过，操作系统级沙箱仍然提供最后一道物理隔离。

五项设计原则

原则	含义	体现
Fail-Closed	安全检查默认拒绝，只有全部通过才放行	任何一层返回"拒绝"即终止执行
纵深防御	每层假设上游已被攻破，独立提供保护	沙箱不信任权限系统的判断结果
最小权限	默认拒绝所有，仅显式允许必要资源	沙箱只开放工作目录的写入权限
零信任输入	所有外部输入一律经过消毒	MCP、深度链接、用户输入都经 Unicode 清洗
零值泄露	安全机制本身不应泄露敏感信息	秘密扫描只返回规则标签，不返回匹配值

---

二、核心点拆解

2.1 OS 级沙箱——最后一道物理防线

为什么需要 OS 级隔离？ 因为应用层的安全检查在同一进程空间内运行，原理上总是可以被绕过的。无论正则多精确、Validator 多完善，Shell 的语法复杂度意味着总有新的绕过方式。而操作系统级沙箱在内核层面强制执行隔离——即使进程内的所有检查都被绕过了，进程本身仍然无法访问沙箱外的资源。

信任边界越低，攻击者越难突破。应用层检查是"我们相信代码正确"，内核级隔离是"即使代码错误，操作系统也不允许"。

SandboxRuntimeConfig 数据结构——最小权限原则的精确表达：

interface SandboxRuntimeConfig {
  network: {
    allowedDomains: string[]     // 网络出站白名单
    deniedDomains: string[]     // 网络出站黑名单
    allowUnixSockets?: string[] // Unix Socket 白名单
    httpProxyPort?: number      // 代理端口
  }
  filesystem: {
    denyRead: string[]          // 读取黑名单
    allowRead: string[]         // 读取白名单
    allowWrite: string[]        // 写入白名单（默认其余只读）
    denyWrite: string[]         // 写入黑名单（优先级高于 allowWrite）
    ignoreViolations?: Record<string, string[]>  // 豁免规则
  }
}

硬编码的不可覆盖规则——"谁来监管监管者"的问题：

路径	防护目的
所有 settings.json 文件	防止沙箱逃逸——通过修改设置放宽安全限制
.claude/skills 目录	防止注入恶意 Skill 定义

如果沙箱允许修改自己的配置文件，攻击者就可以先修改配置放宽限制，再执行真正的攻击。硬编码这些路径的保护，确保安全底线始终存在。

Git Worktree 的智能处理：在 Worktree 中，.git 是一个文本文件指向主仓库的 .git 目录。Git 操作需要写入主仓库的文件，但这些文件在 worktree 的工作目录之外。Claude Code 检测 worktree 并自动扩展写入白名单——安全策略需要理解业务逻辑。

Bare Repo 攻击防护（来自真实漏洞 #29316）：攻击者在项目目录放置 HEAD、objects/、refs/ 等文件，Git 将该目录识别为 bare repository，攻击者设置 core.fsmonitor 为恶意命令实现沙箱逃逸。四步防护：配置时检查 → 已存在文件加入 denyWrite → 不存在文件加入 scrubPaths → 命令执行后删除新建可疑文件。

平台支持矩阵：Linux（bubblewrap）/ macOS（Seatbelt）/ WSL2+（Linux 子系统 bubblewrap）完整支持；WSL1 / Windows 原生不支持。

2.2 命令注入防护——23 个 Validator 的防线

核心挑战：解析差异攻击

echo test\;rm -rf /

这条命令安全吗？取决于谁在解析：

• Claude Code 的 shell-quote 解析器：将 \; 视为转义字符，认为整条命令是一个 echo，安全
• 真实 bash：在某些上下文中，\; 被反斜杠转义后仍然是分号，rm -rf / 作为第二条命令执行

攻击者正是利用解析器与真实 Shell 之间的差异来绕过安全检查。

双路径架构

用户 Bash 命令
  → bashToolHasPermission
    → tree-sitter 可用? ──YES──→ parseForSecurity (AST 结构化分析)
    → tree-sitter 不可用? ──NO──→ bashCommandIsSafe_DEPRECATED (23 个 Validator)

两套解析器还有一个金丝雀式安全监控角色：当两套解析器对同一命令的解析结果出现分歧时，触发 onDivergence() 告警。新发现的解析差异可能意味着新的攻击向量。

多视图字符串：五种不同的"看法"

type ValidationContext = {
  originalCommand: string          // 原始命令（含 heredoc）
  baseCommand: string              // 第一个空格前的词
  unquotedContent: string          // 单引号内容移除，双引号保留
  fullyUnquotedContent: string     // 所有引号内容移除 + 安全重定向剥离
  fullyUnquotedPreStrip: string    // 引号移除但保留重定向
  unquotedKeepQuoteChars: string   // 引号内容移除但保留引号字符本身
}

五种视图不是过度设计——不同的安全检查需要关注命令的不同"面"：

• validateBraceExpansion 使用 fullyUnquotedPreStrip——保留重定向，因为重定向中的 { 不是 brace expansion
• validateMidWordHash 使用 unquotedKeepQuoteChars——保留引号字符以检测 word 边界内的 #
• validateShellMetacharacters 使用 unquotedContent——检查双引号内的元字符

设计模式：多视图预处理——将同一输入预处理为多个针对不同检测目标优化的视图，集中式预处理既提高性能，也减少解析逻辑被遗漏的风险。

23 个 Validator 的三阶段执行

第一阶段：早期短路

• validateEmpty：空命令，直接放行
• validateIncompleteCommands：未关闭引号等不完整命令，询问用户
• validateSafeCommandSubstitution：安全的 heredoc 命令替换，放行
• validateGitCommit：简单的 git commit -m "msg"，放行

第二阶段：主检查链（19 个 Validator）+ 延迟裁决

关键机制：延迟裁决（Deferred Decision）。19 个 Validator 中，validateNewlines 和 validateRedirections 被标记为 non-misparsing：

• misparsing 意味着"解析器看到的和 bash 执行的不一样"——真正危险，必须立即拦截
• non-misparsing（如包含换行或重定向）仅仅是"可能有风险"——可以交给 AI 分类器做进一步判断

延迟裁决确保了更严重的问题不会被较轻的问题掩盖。

第三阶段：最终裁决

• 所有 Validator 通过 → 有 deferred 结果？→ 返回 deferred 结果 / 放行

典型攻击与防御映射

攻击向量	防御 Validator	来源
shell-quote 单引号 bug	hasShellQuoteSingleQuote	H1#3482049
反斜杠空格路径遍历	validateBackslashEscaped	parser differential
ANSI-C $'..' 编码引号隐藏 flag	validateObfuscatedFlags	—
Brace expansion 绕过	validateBraceExpansion	—
引号内换行隐藏	validateQuotedNewline	—
CR tokenization 差异	validateCarriageReturn	JS \s vs bash IFS
Zsh =cmd 展开	validateDangerousPatternZsh	—

许多 Validator 对应的是真实的安全漏洞报告（HackerOne 编号）。23 个 Validator 不是一次性设计出来的，而是在真实对抗中逐步积累的。

Heredoc 安全放行的严格约束

validateSafeCommandSubstitution 是早期放行路径，一旦返回 true 就跳过所有后续 Validator。判定条件极其严格：

1. 定界符必须单引号包裹（'DELIM'）或转义（\DELIM），确保 heredoc 内容无变量扩展
2. $(...) 必须处于参数位置，不能是命令名位置
3. 剥离 heredoc 后的剩余文本只能包含安全字符 [a-zA-Z0-9 \t"'.\-/_@=,:+~]*
4. 剩余文本必须递归通过完整的安全检查
5. 拒绝嵌套 heredoc

“快速路径必须证明安全”：走捷径可以，但你必须证明走捷径是安全的。

2.3 路径遍历防护——30 种命令的参数位置感知

为什么需要独立一层？ 命令注入关注"这条命令是否被 Shell 正确解析"，路径遍历关注"这条命令访问的文件路径是否在允许范围内"。cat /etc/passwd 在命令注入防护看来是安全的（没有注入），但在路径遍历防护看来却越权访问了系统文件。

30 种命令的分类验证：

操作类型	命令列表	数量
read	cat, head, tail, sort, uniq, wc, cut, paste, column, tr, file, stat, diff, awk, strings, hexdump, od, base64, nl, ls, find, grep, rg	23
write	mv, cp, sed（可降级为 read）	—
create	mkdir, touch	—
delete	rm, rmdir	—

每种命令有专用的路径提取器（PATH_EXTRACTORS），因为不同命令的参数位置和语义完全不同：

• grep "error" /var/log/app.log：第一个非选项参数是模式，不是路径
• mv /tmp/file.txt /home/user/project/：所有非选项参数都是路径

-- 选项结束标记的安全陷阱：rm -- -/../../.claude/settings.local.json 中，-- 之后的所有参数都应被视为文件路径。如果 filterOutFlags 不正确处理 --，以 - 开头的路径会被当作选项过滤掉，导致路径验证被完全跳过。

cd + 写操作的组合阻断：cd .claude/ && mv test.txt settings.json 中，路径验证会将 settings.json 解析为 ${原始CWD}/settings.json（安全），但实际上 cd 之后 settings.json 指向 ${原始CWD}/.claude/settings.json（受保护的配置文件）。解决方案：包含 cd 的复合命令如果涉及写操作，一律要求用户确认——"宁可过严"策略。

危险删除路径保护：根目录 /、家目录 ~、根目录直接子目录、Windows 驱动器根目录——不可协商的安全底线。

sed 的读写降级：sed 默认归类为 write，但 sed -n 'p' 等只读命令被白名单降级为 read——细粒度安全：同一工具在不同使用方式下有不同的安全级别。

2.4 SSRF 防护——阻止 Agent 探测内网

被阻止的地址范围

IPv4 CIDR	说明	处理
127.0.0.0/8	回环地址	放行（本地开发需要）
0.0.0.0/8	未指定/当前网络	阻止
10.0.0.0/8	RFC 1918 私有	阻止
100.64.0.0/10	CGNAT（含阿里云元数据）	阻止
169.254.0.0/16	链路本地（含 AWS 元数据端点）	阻止
172.16.0.0/12	RFC 1918 私有	阻止
192.168.0.0/16	RFC 1918 私有	阻止

回环地址被放行——Claude Code 可能需要与本地策略服务器或开发工具通信。这是安全与可用性权衡的缩影。

IPv4-Mapped IPv6 的递归防护

攻击者使用 ::ffff:169.254.169.254 绕过纯 IPv4 黑名单。三步递归处理：

::ffff:169.254.169.254
  → expandIPv6Groups() → [0, 0, 0, 0, 0, 0xffff, 0xa9fe, 0xa9fe]
  → extractMappedIPv4() → 检测前 6 组为 0...0xffff → 提取 "169.254.169.254"
  → isBlockedV4("169.254.169.254") → true → 阻止

"递归降维"策略：无论攻击者使用何种地址编码方式，最终都归结到同一套 IPv4 黑名单检查。

DNS Rebinding 防御——原子验证-使用模式

攻击者控制域名 DNS 记录：第一次解析返回公共 IP（通过检查），第二次解析返回私有 IP（实际连接）。如果验证和连接使用独立的 DNS 解析，攻击者利用时间窗口完成绕过。

Claude Code 的防御：ssrfGuardedLookup 替代 axios 的默认 DNS 解析函数——验证后的 IP 就是 socket 实际连接的 IP，验证和连接使用同一个 IP，消除了 DNS Rebinding 的时间窗口。

这是"原子操作"式的安全设计：将"验证"和"使用"合并为不可分割的操作，从根本上消除 TOCTOU 竞争条件。

代理感知的安全权衡

当系统配置了 HTTP 代理时，SSRF Guard 自动失效——因为代理服务器代为执行 DNS 解析，Guard 验证的是代理服务器的 IP 而非最终目标 IP。这不是"不安全"，而是"安全职责分层"：SSRF Guard 在代理模式下退让，安全责任转移到代理层自身的访问控制。

2.5 秘密扫描引擎——防止凭证泄露到团队记忆

一种容易被忽视的泄露路径

Agent 在分析代码时看到了 .env 文件中的 API Key，将其作为"项目配置"记录到团队记忆中——Agent 不是在"泄露"信息，它是在忠实地执行"记录有用信息"的任务——只是它不理解什么是"敏感信息"。

四项核心原则

原则	实现
客户端侧扫描	所有扫描在本地完成，敏感内容永远不离开用户的机器
高置信度优先	仅采用有明显前缀/后缀特征的规则，舍弃泛化规则
零值泄露	匹配结果只返回规则类型标签（如 “GitHub PAT”），不返回匹配到的 Secret 文本
运行时前缀组装	Anthropic API Key 前缀通过 join() 构造，避免构建产物触发静态扫描

高置信度优先——秘密扫描引擎的规则源自 gitleaks 社区，但并非全盘照搬。只选取具有明确前缀特征的规则（如 GitHub PAT 以 ghp_ 开头、AWS Access Key 以 AKIA 开头），需要上下文才能判断的模式被刻意排除。因为在 Agent 工作流中，误报的代价非常高——每一次误报都在消耗用户的信任存量。

运行时前缀组装——安全工具的"元安全"

const ANT_KEY_PFX = ['sk', 'ant', 'api'].join('_')
// 运行时拼接为 "sk-ant-api"，避免在源码中留下完整前缀

如果直接写 "sk-ant-api03-"，对 Claude Code 仓库自身运行秘密扫描时就会产生误报。通过 Array-join() 在运行时拼接，源码和构建产物中都不存在完整前缀字面量。安全工具自身不应该触发安全告警。

双重拦截点

拦截点	位置	作用
拦截点 1	工具层写入（FileWriteTool/FileEditTool）	预防——在 Secret 进入文件系统之前拦截
拦截点 2	同步层上传（teamMemorySync）	兜底——确保 Secret 永远不离开本地机器

用户可能直接用编辑器修改团队记忆文件绕过拦截点 1，但拦截点 2 仍然会在上传前捕获。纵深防御——不要假设任何单一拦截点是完美的。

2.6 Unicode 输入消毒——对抗不可见的 Prompt 注入

隐形攻击：你看不到的字符

Unicode 标准中存在大量不可见字符——零宽空格（U+200B）、格式控制符（U+200C-200F）、双向文本标记（U+202A-202E）、Tag 字符（U+E0001-E007F）等。这些字符在大多数文本编辑器和终端中不会显示，但 LLM 的 tokenizer 可能会处理它们。

攻击者在看似正常的 MCP 工具返回值中嵌入零宽字符序列编码的隐藏指令——用户在终端中只能看到正常输出，但 LLM 可能会读取并执行隐藏指令。已有真实安全报告（HackerOne #3086545）。

三步迭代清洗算法

while (current !== previous && iterations < MAX_ITERATIONS) {
  步骤1：NFKC 规范化 → 处理组合字符序列、全角→半角
  步骤2：Unicode 属性类剥离 → Cf(格式控制符)、Co(私有使用)、Cn(非字符)
  步骤3：显式范围兜底 → 零宽空格/LTR-RTL marks/BIDI控制符/BOM/BMP私有使用区
  iterations++
}

为什么需要循环？ NFKC 规范化的副作用——某些组合字符序列在规范化后可能产生新的格式控制符。如果只执行一次，新产生的控制符就会残留。迭代直到字符串不再变化（收敛），确保所有嵌套的、间接产生的危险字符都被彻底清除。

正常输入一次迭代即可收敛。需要多次迭代的输入几乎可以确定是恶意构造的。

Fail-Closed 的崩溃策略

10 次迭代后仍未收敛 → 直接抛异常，让程序崩溃。不是返回空字符串，不是返回部分清洗结果，不是静默忽略——而是崩溃。

安全宁可"大声崩溃"（loudly crash），也不可"静默放行"（silently pass）。10 次迭代仍未收敛意味着要么清洗逻辑有 bug（应该修复），要么输入是精心构造的恶意载荷（应该阻止）。无论哪种情况，崩溃都比放行更安全。

六个调用点的全覆盖

调用位置	防护场景
MCP 客户端	MCP 工具输入/输出的隐藏指令防护
深度链接解析	URL 参数的 Unicode 混淆防护
会话存储反序列化	持久化数据的注入防护
文件编辑工具	文件内容的控制符防护
安全审查	审查输入的清洗
Tag 命令	用户标签输入的清洗

"零信任输入"原则——任何来自信任边界之外的数据都必须经过消毒，无论它看起来多么无害。

---

三、安全与可用性的 Trade-off

安全系统的"可用性论"

过严的安全策略可能比没有安全策略更危险——如果一个 Agent 系统每执行一条命令都要弹出权限确认，用户很快就会养成"无脑点确认"的习惯——权限系统虽然在技术上运行着，但在实际上已经形同虚设。这就是"狼来了"效应。

平衡矩阵

安全层	对用户可见性	精准度要求	用户体验影响
Layer 1：沙箱	完全透明	低（内核级，误报 ~0）	无
Layer 2：命令注入	部分可见（触发时提示）	高（误报→频繁中断）	中
Layer 3：路径遍历	部分可见（触发时提示）	高（误报→频繁中断）	中
Layer 4：SSRF	完全透明	中（静默拦截）	无
Layer 5：秘密扫描	触发时提示	极高（误报→信任丧失）	高
Layer 6：输入消毒	完全透明	低（静默清洗）	无

两类安全层：

1. 透明层（Layer 1/4/6）：后台静默运行，可以相对激进
2. 交互层（Layer 2/3/5）：触发时需要用户确认，必须追求极高精准度

过严策略的三个代价

1. 权限疲劳：最严格的 default 模式几乎没人能坚持，用户反而切换到 yolo 模式——中等严格但用户愿意使用的模式，比极度严格但被绕过的模式更安全
2. 工作流中断：50 条 Bash 命令中 20 条触发安全提示 → 用户感受不是"AI 助手帮我编码"，而是"AI 不断问我问题"
3. 安全剧场：安全措施在形式上存在但在实质上无效——用户形成"所有提示都是误报"的心理模型，真正危险操作时仍然习惯性点"允许"

Claude Code 的四项平衡策略

1. 分层静默：不需要用户参与的安全检查（沙箱、SSRF、消毒）完全静默化
2. 渐进信任：批准 npm install 一次后，后续不再提示
3. 精准分类：misparsing 直接拦截 / non-misparsing 交给 AI 分类器——分级处理避免"一刀切"
4. sed 读写降级：只读 sed 降级为 read 操作——细粒度安全

---

四、四条安全链的协同

每条安全链都经过多个安全层，没有任何一条链只经过单一安全层：

Bash 命令安全链：

用户/LLM 提交 → [L6] Unicode 清洗 → [L0] 权限系统 → [L2] 命令注入防护 → [L3] 路径遍历防护 → [L1] 沙箱隔离 → 执行 → [L1] 沙箱清理

HTTP Hook 安全链：

Hook 配置触发 → [L4] SSRF 防护 + DNS Rebinding 防御 → [L6] Hook 返回值 Unicode 清洗 → 注入对话

团队记忆安全链：

AI 生成内容 → [L5] 拦截点1：工具层写入拦截 → 本地存储 → [L5] 拦截点2：同步层上传拦截 → 上传服务器

MCP 工具安全链：

MCP 服务器返回结果 → [L6] Unicode 清洗 → [L0] 权限系统检查 → 注入对话上下文

---

五、横向对比

六层纵深防御 vs 其他安全模型

维度	Claude Code	Docker 容器安全	浏览器沙箱
防御层数	6 层 + 权限系统	3-4 层（namespace/cgroup/seccomp/capabilities）	4-5 层（进程隔离/站点隔离/同源策略/CSP/CORS）
核心威胁	Prompt 注入 + 命令注入	容器逃逸	XSS/CSRF
独有挑战	LLM 语义理解可被攻击者操控	无	无
命令注入检测	23 Validator + AST 双路径	无（依赖镜像签名）	无（不同威胁模型）
秘密扫描	内置 28+ 规则 + 双重拦截	外部工具（Trivy/Snyk）	无
Unicode 防御	迭代收敛清洗	无	部分浏览器 IDN 规范化
代理感知	自动退让 + 职责转移	无特殊处理	代理自动感知

Claude Code 的独特之处：Agent 系统面对的威胁模型比传统系统复杂得多——攻击者可以操控 LLM 的语义理解过程，这不是传统安全模型能覆盖的。

---

六、实战启示

启示 1：纵深防御的核心价值是"攻击成本指数级增长"

单层防御被绕过 = 攻击成功。六层纵深防御被绕过 = 攻击者必须同时突破所有层。从"绕过一层"到"同时绕过所有层"，攻击成本呈指数级增长。

实践建议：每新增一层防御时，问自己"这层与已有层是正交的吗？"——如果两层检测的是同一类攻击的不同变体，纵深感不足；如果两层检测的是完全不同类型的攻击，纵深价值最大。

启示 2：透明层可以激进，交互层必须精准

沙箱、SSRF 防护、输入消毒对用户完全透明——误报只影响性能，不影响体验。命令注入、路径遍历、秘密扫描触发时需要用户确认——每次误报都在消耗用户耐心。

实践建议：在设计安全系统时，先把能静默化的检查移到透明层，再对交互层做精准度优化。目标是让每次提示用户时都是有意义的。

启示 3：安全宁可"大声崩溃"，也不可"静默放行"

Unicode 消毒 10 次未收敛 → 崩溃。这不极端，这是正确的 Fail-Closed 姿势。如果安全系统无法确定输入是否安全，唯一安全的选择是拒绝它。

启示 4：安全工具自身是攻击面

运行时前缀组装避免安全工具触发自身告警。三文件同步约束（包装器列表）是潜在漏洞来源。在设计安全系统时，始终问自己"安全机制本身能否被利用？"

启示 5：中等严格但用户愿意使用的模式，比极度严格但被绕过的模式更安全

这是安全设计的反直觉真理。Plan 模式（只允许读操作自动执行）比 default 模式更宽松，但因为它减少了中断频率，用户更愿意持续使用，实际安全效果反而更好。

---

七、设计模式速查

模式	核心思想	本章体现
原子验证-使用	将安全检查与资源使用合并为原子操作	SSRF Guard 的 DNS lookup 替代
零值泄露	安全机制的输出不包含敏感信息	秘密扫描只返回规则标签
迭代收敛清洗	反复清洗直到不再变化，超限则崩溃	Unicode 消毒的 while 循环
双重拦截	在数据流的多个节点设置独立拦截	秘密扫描的写入时 + 上传时检查
安全剧场免疫	让安全提示足够精准以维持用户信任	高置信度规则 + 延迟裁决 + sed 降级
多视图预处理	将同一输入预处理为多个优化视图	ValidationContext 的五种视图
延迟裁决	严重问题不被轻微问题掩盖	misparsing 优先于 non-misparsing
快速路径证明安全	走捷径必须证明安全	Heredoc 放行的 5 条严格约束
递归降维	将复杂编码统一到同一检查体系	IPv4-Mapped IPv6 递归处理
运行时组装	避免安全工具自身成为攻击面	API Key 前缀的 Array.join()

---

下期预告

第 14 篇，我们将进入第9章前半——Hook 事件系统，解析 Claude Code 的扩展架构：27 个 Hook 挂载点、动态执行器的多态构型、会话生命周期 Hook、幂级配置合并。当安全是"不让坏事发生"，扩展就是"让好事更容易发生"。

第14篇预告：27 个 Hook 节点与动态执行器——Agent 扩展的事件驱动骨架

---

本篇为《Claude Code 架构解密》精读笔记第13篇，覆盖第8章全部（8.1-8.9, p.198-227）。
上一篇：[第12篇] System Prompt 三层组装与 CLAUDE.md 四级覆盖
系列持续更新中，关注获取更多精读内容。