上线前安全评审

S8
深入解析 · 安全、对齐与智能体安全

上线前安全评审:一份实用的智能体部署清单。

前面的文章构建理论;本文把它转化为你上线前真正可执行的一次评审。它的组织方式是:杠杆最高、失败时趋关闭的控制排在最前,并包含常被遗漏的供应链维度:你连接的每一个 MCP 服务器和第三方工具都是你信任边界的一部分。

STEP 1

如何使用这份评审

这是一道关卡,不是一份问卷。无法用具体证据回答的条目("这是白名单"、"这是让绕过失败的测试")不算通过。上线前运行它,并在每次换模型、改提示、加工具或升级 MCP 服务器时重跑受影响的章节——这些都可能无声地重开一个已关闭的洞。

次序很重要。能力与信任边界控制(步骤 2–3)失败时趋关闭,移除影响。检测与监控(步骤 6)失败时趋开放,只增加可见性。若时间紧张,这份清单的顶部才是安全真正所在之处。

STEP 2

能力与最小权限(失败趋关闭——先做)

  • 存在工具清单;每个工具映射到一个需要它的任务。无用/"以防万一"的工具已移除。
  • 每个工具收窄到最小:尽可能只读、限记录/行数、单租户、无自由格式目的地字段。
  • 凭据短期、按任务、窄作用域。智能体环境中没有可触及的长期管理员令牌或云元数据。
  • 高影响工具按状态设关——仅在其有效的状态可用。
  • 对每个工具:有文档化的回答"若攻击者控制了这次调用的输入,最坏结果是什么?"且该结果可接受或被进一步约束。
STEP 3

信任边界、输入与供应链(失败趋关闭)

  • 四个输入通道全部枚举:直接输入、检索内容、工具/API 结果、持久化记忆/历史。
  • 每个通道的信任级别已文档化。任何可被外部影响之物(用户上传、公共网络、可编辑 wiki、工单、第三方 API)均按不可信处理。
  • 不可信内容与特权指令/工具位置隔离(例如 无工具读取器 → 经校验的结构化交接 → 特权执行者)。
  • 来源被追踪:代码能区分运营者指令与检索/工具文本。
  • MCP 与第三方供应链:每个连接的 MCP 服务器和外部工具都连同其所有者一起入册,并作为不可信输入源对待——其响应可携带被注入的指令,其工具定义可在你不知情时变化。
  • MCP 服务器与工具依赖被钉版/受版本控制;更新走同一套安全重评审(一个描述或行为变化的工具是一个新的信任决策)。
  • 任何代码执行沙箱的网络出站默认拒绝;出站目的地白名单。

上面最被忽视的一行是 MCP/第三方那条。连接一个外部服务器,等于把你智能体行为的一部分交给那个运营者的数据卫生和更新纪律。一个未钉版、定义会变的工具,即便没有攻击者在场,也是一个供应链攻陷向量。

STEP 4

动作控制与外泄(失败趋关闭)

  • 每次工具调用都通过一个确定性的执行前检查(状态内允许、schema 合法、目的地白名单、在速率/数量限制内)——以代码实现,而非一个同一提示能绕过的第二个 LLM。
  • 枚举网络工具之外的外泄汇:被渲染的 Markdown/HTML(自动加载图片、链接展开、预取)、写后读旁路(工单、PR 评论、共享日志)、错误/时序通道。
  • 被渲染的智能体输出经净化:外部图片/链接 URL 被剥离或代理;没有界面会自动获取攻击者选定的 URL。
  • 不可逆/对外可见/改变权限/高价值的动作,需经一份可审查摘要和一个上下文内攻击者无法伪造的带外确认进行人工审批。
  • 超时或不确定时默认拒绝:无审批,无动作。
STEP 5

对齐与目标卫生

  • 智能体的目标/奖励信号已审查是否存在可博弈的单指标代理;并与能捕捉退化策略的护栏指标配对。
  • 智能体工作可检视:在高影响提交前暴露计划、推理和一个可审查的 diff。
  • 尽可能利用验证不对称(测试/校验器廉价核查结果,而非信任智能体的声称)。
  • 不确定时保守默认:意图不清时,智能体询问或停止,而非优化代理指标。
STEP 6

评估、监控与响应(失败趋开放——可见性,最后)

  • 版本化的对抗性测试套件覆盖每个威胁模型类别,按有害结果评分,每次变更对上线系统运行。
  • 每个确定性控制至少有一个失败的绕过测试(边界成立的证明)。
  • 未参与设计的人做的独立对抗性审查,没找到任何能转化为结果的攻破。
  • 所有工具调用连同参数被记录;对首次出现的目的地、参数中异常数据量,以及读敏感数据后出口的序列发出告警。
  • 存在事件路径:终止开关/能力撤销,以及把每起真实事件转为永久回归测试的流程。
┌────────────────────────────────────────────────────────┐ │ PRE-SHIP GATE (top = fail-closed, highest leverage) │ │ │ │ ① capability & least privilege │ │ ② trust boundary · inputs · MCP supply chain │ │ ③ action checks · exfiltration sinks · approvals │ │ ④ alignment / objective hygiene │ │ ⑤ eval · monitoring · incident response (visibility) │ │ │ │ re-run ①–③ on every model/prompt/tool/MCP change │ └────────────────────────────────────────────────────────┘
问题
截止前我们无法满足全部。最小可行的安全上线是什么?

如果只做三件事:(1) 无情的最小权限,使一次注入能触及的最坏工具其自身可接受;(2) 把每个外部输入和每个 MCP/第三方工具都当不可信,并与特权动作隔离;(3) 对那一小撮不可逆/对外动作做人工审批。这些全是失败趋关闭的,覆盖了真实事件的大部分。检测和花哨过滤是锦上添花,不是这些的替代。

问题
这看起来像一次性的上线清单。智能体安全难道不是持续的吗?

两者皆是。关卡是上线门槛;尤其步骤 1–3 是重跑触发器,而非一次性,因为换模型、改提示、加工具或更新 MCP 服务器都可能无声地使先前的通过失效。把清单当作一道 CI 关卡,外加一个由变更触发的重评审,关卡之间持续运行监控与不断增长的回归套件。