模块 11 — 架构师问答题(security)

🎯 学习重点：回答每题都要包含威胁模型、控制位置、失败模式与可审计证据。

开放式问题,先自己口头/书面作答,再对照参考要点。每题附「考察点」与「参考答案要点」;要点中的关键论断均可在模块 README 第 11 节来源表中溯源(访问于 2026-08-30)。

AQ1. 为什么「在 prompt 里写禁令」不能算安全控制?请给出工程层面的论证,并说明 prompt 禁令在安全架构里的正确定位。

考察点:LLM 指令 ≠ 应用层强制;概率层 vs 确定性层。

参考答案要点:

• 禁令作用于模型的「意图」,而注入攻击的本质就是改写意图——防线与攻击目标是同一个变量。
• 三个量化论据:模型层注入攻击有非零失手率(Opus 4.7 在 Gray Swan ART 上单次约 0.1%、100 次自适应尝试后约 5–6%);审批疲劳(约 93% 权限弹窗被批准);auto mode 分类器拦约 83%、漏约 17%,官方定位是「沙箱内纵深防御的一层,不是沙箱的替代品」。
• 极端案例:钓鱼让用户亲手敲入外传指令,25 次中 24 次成功——模型层锚定用户意图,无异常可抓;只有 egress 控制与文件边界守得住。
• 正确定位:prompt 禁令/policy 声明是概率层的「行为整形」,用来降低日常误触发、配合审计;授权与红线必须由确定性组件执行:工具能力面设计、网关策略、审批门、沙箱、egress 控制。
• 一句话:当所有概率性防护都失手时,真正挡住攻击的是确定性边界。

AQ2. 为一个「读企业 wiki + 写工单 + 查订单库」的内部 agent 设计注入防御,列出你的分层清单,并说明每层失败时的兜底。

考察点:纵深防御落地;间接注入缓解清单。

参考答案要点:

• 入口层:用户输入过 harmlessness screen;wiki/订单库内容一律走 tool_result + JSON 编码 + 来源标注;system prompt 声明 untrusted content policy。
• 筛查层:工具输出过 injection screen(轻量模型 + structured output 布尔判定),可疑返回剥离摘要并告警。
• 授权层:三个工具分别最小粒度——wiki 只读、工单「单条创建 + 字段白名单」、订单库只读账号;网关逐调用校验 scope 与参数域(路径前缀/枚举/域名)。
• 环境层:文件系统边界(工作区内)、egress 域名白名单(收窄到 wiki/工单/订单 API)、无 shell 工具。
• 人审层:唯一高危动作(如删除工单)走 approval gate,带完整上下文呈现。
• 兜底逻辑:筛查漏报 → 授权层挡住越权工具;授权层配置失误 → 环境层限制数据可达;全部概率层失守 → 确定性边界封顶战果。
• 上线前:注入红队(带毒 wiki 页/工单返回);上线后:持续监控 + 定期红队。

AQ3. 你的团队想给 agent 配一个「运行任意 shell 命令」的工具,理由是通用性。作为架构师你如何回应?

考察点:最小权限工具设计;粒度与通用性的权衡。

参考答案要点:

• 通用性收益归 agent 的「任务上限」,成本归「战果上限」——万能 shell 把注入的爆炸半径扩到整个执行环境。
• 替代路径:把高频需求收敛为专用工具(read_file/run_tests/deploy_draft…),参数 schema 即权限落点;真正长尾的命令走审批门 + 沙箱内执行。
• 若必须保留 shell:OS 级沙箱(Seatbelt/bubblewrap)+ 工作区目录边界 + 默认断网 + 命令注入检测 + fail-closed(未匹配规则即审批)——Claude Code 的模式。
• 量化提醒:只有只读权限的 agent 可以部署得比能写生产库的 agent 广得多;审批弹窗密度决定人审是否还有意义。
• 决策框架:能力面 = 任务必需 ∪ 注入可达;每一项能力都要回答「被滥用时损失多少」。

AQ4. egress 白名单为什么会被「合规域名」打穿?设计白名单时应如何思考?

考察点:allowlist as capability grant。

参考答案要点:

• Cowork 案例:放行 api.anthropic.com(业务必需)同时放行了 Files API 上传——数据进了攻击者的账号;沙箱全程正常。
• 思维转换:白名单不是「这域名是好人」的目的地过滤器,而是「把这个域名背后的全部功能面授予了 agent」的能力授予;要按 API 能力粒度(上传/分享/发消息)评估,而不是按域名。
• 设计动作:① 能力审计——列出每个放行域名暴露的写/分享/外发接口;② 对高危能力走独立通道(会话 token 校验的防御型代理、接口级 scope、审批门);③ 内容扫描兜底上传/分享载荷;④ 自研代理要当最薄弱组件对待,重点测试(官方教训:成熟原语稳,自研件出事)。

AQ5. human approval 什么时候是真控制,什么时候是假安全?给出可操作的判据。

考察点:审批疲劳;匹配用户监管能力。

参考答案要点:

• 三个有效性前提:用户有能力评估动作(能读 bash);审批密度低(93% 批准率即失效);用户本身不是注入向量(钓鱼即穿透)。
• 假安全信号:高频弹窗、「全部允许」按钮被滥用、审批人不理解参数含义、把人审当唯一防线。
• 真控制形态:低频高危动作(资金、对外发送、不可逆删除);呈现完整上下文(工具、参数、影响资源、命令的自然语言解释);与作用域 token、审计日志绑定;可追责。
• 替代/组合:auto mode 分类器减少弹窗量(但它是概率层)、沙箱让边界内动作免打扰、审批只留给边界外。
• 原则:隔离强度匹配用户监管能力——对非技术用户用 VM/沙箱兜底而不是弹窗。

AQ6. MCP server 的接入治理与工具输出治理有什么区别?分别怎么做?

考察点:连接器信任 vs 数据信任;token passthrough/scope 设计。

参考答案要点:

• 接入治理(代码执行风险/供应链):允许清单进版本控制;本地 server 可锁版本可审计,远程 server 批准后随时可能变行为——安装时的信任会过期;目录内 connector 有评审但不等于安全审计,目录外当不可信。
• 数据治理(注入风险):「审计过的连接器 ≠ 审计过的数据」;一切工具输出按不可信内容处理:过 injection screen、走 tool_result 通道、必要时实时检查(事后日志只见合法调用,无信号可查)。
• 协议层反模式:token passthrough(绕过下游控制、审计断链)必须换成 server 自己的凭证;scope 渐进提权(最小初始 + WWW-Authenticate 挑战 + 提权日志)。
• 多 agent 注意信任升级:sub-agent 输出被当「自己人」而高信任,是新注入向量。

AQ7. 数据隐私维度,一个把客户邮件送 Claude API 的系统要过安全评审,你的检查单?

考察点:PII/脱敏/留存/驻留。

参考答案要点:

• 传输与合同基线:Commercial Terms 默认不训练(Inputs 权利归客户、Outputs 归客户);确认是否需要 ZDR;若用到 covered models 留意 30 天留存例外(截至 2026-08-30,2026-06-09 生效,仅影响开 ZDR 组织)与 CMEK/访问透明度选项。
• 输入侧:字段级 PII 识别 + 假名化/令牌化,回填在应用层;上下文最小化(按需检索,不整箱导出)。
• 日志侧:对话/trace/工具出入参全量脱敏;日志管道本身按敏感数据处理。
• 驻留:如需数据不出特定云,Bedrock / Google Cloud / Microsoft Foundry 承载;确认对应 ZDR 通路与合规边界。
• 组织侧:DPIA、retention 书面化、事件响应流程;给模型的工具面按数据分级再收窄(可触 PII 的 agent 禁出站)。

AQ8. 解释「审批门、沙箱、白名单、分类器」四种控制的角色差异,并说明为什么生产系统需要全部四种而不是选一个「最好」的。

考察点:纵深防御的组合逻辑;确定性与概率性的互补。

参考答案要点:

• 审批门:人的判断,处理「规则写不出的语义级风险」,弱点是疲劳与社工 → 只用于低频高危。
• 沙箱:环境硬边界(文件/网络/进程),不管意图只管可达;决定 blast radius 上限。
• 白名单/网关:能力授予的显式化,逐调用校验 scope 与参数域;配置错误是主要风险。
• 分类器:概率层,廉价可扩展,覆盖规则盲区;有漏报误报,只能减量不能兜底。
• 组合逻辑:概率层(分类器+模型抗性)降低攻击成功频率;确定性层(沙箱+网关)保证即使成功也偷不到/发不出;审批门处理确定性规则无法分类的残余高危。任何单层都有已知失效模式,缺一层就把该层失效模式变成系统失效模式。
• 官方三产品(claude.ai / Claude Code / Cowork)即按此逻辑组合出三种不同配比。