AI蓝队解析：控制措施真正能立足的三个层面

问一个安全团队其 AI 护栏位于何处，答案通常会提到一份策略文档、一个系统提示词或某项供应商功能。这些都不是控制措施。控制措施是在行动发生的那一刻决定该行动是否发生的东西——而对于 AI 智能体来说，只有三个地方能做出决定：模型、它前方的网关，以及它周围的环境。蓝队能够诚实承诺的一切，都来自其中的第二个和第三个。这就是层级问题，它先于蓝队的其他每一项决策，包括记录哪些日志以及联系谁。这也是为什么实地证据很重要：AI 事件档案收录了从 2024 年 12 月到 2026 年 10 月 17 日的 400 起智能体事件，而且其中大多数并不是关于模型行为失常的故事。它们讲的是部署中没有任何一层能够说“不”。

AI 意义上的蓝队工作，就是把这些层部署到位、调整它们所关注的内容，并为其中某一层触发的那一天准备好一套演练过的应对方案。这项工作并不光鲜，也不会产出分数，但它是红队/蓝队这对组合中唯一能改变风险数值的那一半。

蓝队继承了什么，又没有继承什么

传统蓝队工作建立在一组假设之上，而 AI 部署正悄然打破这些假设。人们曾假定日志是完整的，因为网络能看到每一个数据包；曾假定资产是可枚举的，因为总得有人去配置它们；曾假定行为是确定性的，因为程序在给定相同输入时会做出相同的事。而这三条假设，在真正与智能体交手之后无一幸存。

蓝队接手的反而是一个这样的系统：其中最关键的决策发生在某个请求内部，而网络层会将该请求视为发往单一主机名的普通 HTTPS 流量。提示词、检索到的上下文、工具调用、补全内容——所有这些都包含在一个请求体中；如果没有人捕获并解析该请求体，那么无论外围防护多么完善，该部署在功能上就是未受监控的。因此，蓝队的首要任务不是检测，而是建立传感器。如果没有请求级和工具级可见性，就没有可供检测的对象，而所有下游控制都只是摆设。

谁才能真正执行这项控制？

一旦有了传感器，问题就变成了每个控件被允许放在哪里。绘制这张图时，有用的做法是按归属关系而不是按技术来画，因为归属关系决定了某个控件能否在下一个版本中保留下来。

模型层属于训练它的人。你无法配置它，也无法看透它的内部，而且它的行为会随供应商发布新版本而改变——可能就在某个周二。你能做的是固定一个版本，并把版本变更视为风险态势的变更，需要重新测试。你不能做的是在这里声称拥有一项控制措施。“模型会拒绝有害请求”是你所依赖的一种属性，而不是你操作的机制。

网关层是每个提示词和补全都流经你所拥有组件的地方。预算和速率限制在这里生效，允许列表和工具权限在这里强制执行，请求和响应日志在架构上就是完整的，并且任何请求都能在任何 token 计费之前被重写、阻止或重新路由。网关控制也是唯一在你更换模型时仍然保持附着的控制手段，这一点比听起来更重要：把控制措施放进提示词里的团队，在迁移模型的那天会彻底失去这些控制。

环境层是完全可以由你掌控的那一层：凭据及其作用域、网络出口、文件访问、沙箱对实际耗时和花费的限制。它也是被攻陷的运行造成破坏的地方。一个被诱导去恶意行动的智能体，其危险程度恰好与环境允许该行动触及的范围成正比——而环境正是这样一个地方：在这里，“最小权限”是一项配置变更，而不是一个研究难题。

对任何拟议的 AI 控制措施，实用的检验只需一个问题：这三层中的哪一层会强制执行它？如果答案是模型层，那么该控制只是一种希望。如果答案是“系统提示词”，那它是模型层内部的一条建议，这比希望更糟，因为它还附带着声称并非如此的文档。

检测：智能体实际输出的内容

针对智能体的检测所依据的信号集与针对人员的检测不同。没有可关联的登录异常。取而代之的是，一个结构异常丰富的请求流，以及四类值得触发告警的信号。

• 工具调用的数量和形态。如果一个智能体在单个任务中突然调用文件读取工具四十次，或者其工具序列从三步变成三十步，就值得关注——不是因为它有恶意，而是因为分布发生了变化。

• 边界处的内容溯源。提示词中哪些文本来自用户，哪些来自检索，哪些来自工具结果，哪些来自记忆。大多数提示注入检测都可归结为“指令性文本出现在本应只承载数据的通道中”，而除非网关在入口处标注来源信息，否则你无法判定这一点。

• 出站与范围边界。对允许列表之外目的地的请求、对范围之外路径的读取、尝试将凭据用于其预期服务之外。这些是高精度信号，而且成本很低，因为环境已经知道哪些操作是被允许的。

• 将支出和延迟作为代理指标。失控循环和系统失陷看起来都像是成本曲线斜率发生变化。预算告警是整套技术栈中最不起眼的检测手段之一，也是最快收回成本的检测手段之一。

那份清单中刻意缺席的，是一个被要求判断某次补全是否有害的分类器。这是团队最先想到、也是随时间的推移最容易被淘汰的检测思路：它会随模型一起漂移，它的误报率会让你的分析人员逐渐习惯性忽略它，而且它给不了你任何能写进运行手册的东西。

遏制：阻止糟糕走势的三个旋钮

对智能体而言，管控比看起来更简单，因为三个控制项几乎覆盖了一切。预算限制一次运行可花费的额度，从而既约束财务损失，也约束循环的影响范围。范围限制一次运行可触及的内容——为该任务启用的工具、路径和租户。沙箱限制其可运行的时长以及运行期间可访问的内容。这三者都是网关或环境设置，换句话说，它们都是可强制执行的。

真正重要的设计原则是按任务划定范围，而不是按智能体划定范围。拥有常设权限集的智能体，其权限会不断累积，直到有人对其进行审计；而在任务持续期间获得任务范围凭证的智能体，其边界会自动到期。后者的构建工作量更大，但防护成本要低得多。

这也正是网关名副其实之处。位于每次模型调用之前的控制措施——工具调用和 MCP 调用在运行前接受分级，内容策略和个人数据掩码在请求计费前生效——无论其背后的模型是你上个季度使用的那个，还是上周刚发布的那个，都是同一套控制措施。这种连续性才是真正的产品：不是更好的过滤器，而是一个让过滤器安身、且不会随模型更替而迁移的地方。

恢复：重放、修补、重新测试

AI 事故的恢复相比网络事故的恢复有一个优势：整个过程通常都会被记录下来。提示词、上下文、工具调用、补全内容、时序——只要网关记录了这些信息，事故就可以被回放，这比大多数取证工作所能获得的起点都要更有力。

回放按顺序有三个作用。它确认实际发生了什么，而不是经过几个人转述后记录所暗示发生的事。它找出本应触发的控制点，这正是修复症状与修复边界之间的区别。它还产出回归用例：一个现在必须被拦截的已记录输入，针对新配置运行以证明它确实被拦截。

补丁环节是蓝队最常瞄错方向的地方。如果该发现属于模型行为，那么可用的缓解措施全都在模型之外——缩小作用域、在网关处加一道过滤器、从环境中移除某项权限。如果该发现属于系统行为，修复就落在配置里，回归测试的成本也很低。重新测试无论哪种情况都不是可选项，因为修复和模型版本都在变，而一个针对上个月构建验证过的控制措施，只是在断言上个月的状态。

预演它开火的那一天

一本从未在压力下被读过的运行手册只是一份文档，而不是一种能力。真正值得做的演练是范围窄而具体的：选取一个可信的智能体事故，从头到尾走一遍，并为每一步计时。谁会注意到？要过多久才会有一名人类正在查看正确的那行日志？谁能中止运行——一个具名的人，还是一个委员会？谁能吊销凭据，吊销要多久才能生效？谁来决定是否通知公司外的任何人？

这些问题中有两个总会让团队栽跟头。“谁能叫停运行”之所以失效，是因为叫停需要依赖一个正在睡觉的人，所以答案必须是一种机制而非某个人——比如预算上限，或值班工程师可以独自拉下的急停开关。“撤销需要多长时间”之所以失效，是因为凭据往往缓存在并未出现在图中的组件里。

阅读归档记录是现有最廉价的演练形式，因为它让你继承他人的事故结构，而不是自己发明一套。挑选少量与你的部署相似的条目，并对每一条问上述三个问题。那些你无法回答这些问题的条目，就是你运行手册中的缺口；而且你是在事故之前而不是之后发现它们的。

值得直说的不对称

红队和蓝队并非对称的活动，因此不应把它们当作对称的来编制预算。红队的一次行动受时间表约束，产出的是一组会随着目标变化而衰减的发现。蓝队的控制措施则持续存在、不断累积，并且是真正挡在不良输入与不良结果之间的唯一屏障。一方的一次行动可以发现一条边界；只有另一方才能守住它。

这使得蓝队的诚实标准朴实无华且可核查。对于你声称拥有的每一项控制措施，你都应该能说出执行它的那一层、证明它已触发的日志行、在它未触发时通知你的告警，以及能够关闭该运行的人。四句话。如果缺少其中一项，这项控制措施就只是一份政策文件，而政策文件不会读取请求体。