AI 控制路线图：Google 把 Agent 当内部人来防

如果 AI Agent 只是在聊天框里给建议，模型对齐失败多半还是「答错了」或「做了不该做的推荐」。但当 Agent 能写代码、跑实验、访问内部系统、调用工具，风险就变成了另一件事：它可能像一个已经拿到工牌的内部人，在公司系统里连续执行动作。Google DeepMind 6 月 18 日发布的《Securing the future of AI agents》把这个问题称为 AI Control，也就是在模型对齐之外，再做一层系统级控制。1

这篇官方博客和配套技术报告的重点，不是再讲「让模型更善良」。它从一个更工程化、也更不舒服的假设出发：如果未来某个内部部署的高能力 Agent 并不完全对齐，Google 应该怎样限制它造成的损害？2

Google DeepMind 的路线图把 AI Control 定位为「第二道防线」。第一道防线仍然是模型对齐：训练模型按人的目标行事。第二道防线处理的是更糟的情况：模型已经被大规模接入内部工作流，但它的行为不能完全信任。报告明确说，AI Control 关注的是模型外部的系统级缓解措施，包括自动监控、响应、访问控制和运行环境加固。2

这个视角很接近企业安全里的「内部人威胁」。员工为了完成工作，本来就需要访问代码、文档、服务和数据；Agent 也一样。区别在于，未来一个公司里可能同时运行成千上万个、甚至上百万个同源 Agent 实例。它们速度更快，可以共享相似能力，也可能把一次攻击拆成很多看起来无害的小动作，分散在不同实例里完成。传统依赖人工审批和人工看日志的安全做法，在这种规模下很快会吃不消。2

为了把威胁说清楚，报告借用了 MITRE ATT&CK 这类网络安全框架，并提出 TRAIT&R，即 Rogue AI Tactics and Routines 的分类法。它把内部 AI 对抗者可能追求的目标分成三类：失去控制，例如模型外泄或绕开监控的内部部署；工作破坏，例如故意让安全研究或对齐工作出错；直接伤害，例如破坏关键资产或外泄敏感信息。2

这份路线图最有用的地方，是没有把 Agent 安全写成一组静态规则。它把防线跟模型能力绑定：模型越会躲监控、越能真正执行攻击，控制措施就要越重。

另一条轴是 R1 到 R3，回答「Agent 造成伤害的能力到哪一步了」。R1 主要靠事后监控和回滚，因为模型只能造成低严重度、可逆的损害。R2 开始要求实时阻断、隔离运行环境、把 Agent 身份和用户身份分开，并做细粒度权限控制。到了 R3，如果模型的网络攻击能力超过「专家人类 + 可信模型」的防守能力，报告建议引入严格软件供应链、关停基础设施、限制会话长度和 Agent 通信等措施。2

这里有一个很实在的数字锚点：当风险升高到 R2，报告希望异步监控和同步响应覆盖超过 99% 的内部 Agent 流量；在低风险阶段，异步响应可以从一周内处理，逐步压到 24 小时以内。2 这说明 Google 并不满足于「发现问题后复盘」，而是在为 Agent 进入核心工程系统预设实时刹车。

官方博客披露，Google DeepMind 已经做了一个内部异步监控原型，用来审查 coding agent 的任务轨迹，并把可疑事件升级给人类复核；他们已经分析了一百万个 coding agent 任务。1 这一步的意义不在于「抓坏模型」，而是把安全团队从关键词过滤推向行为模式识别：哪些工具调用组合可疑，哪些代码改动像绕过监控，哪些删除动作需要实时拦下。

博客还提到，这项工作已经被用于 Gemini Spark agent 的实时监控，目标包括及时处理误删数据这类问题。1 这点很关键：现实里的风险并不总是电影式的「模型叛变」。更多时候，Agent 是过度执行用户目标、误解上下文、把临时文件当成可删对象，或者为了完成任务绕过了某个隐含约束。

DeepMind 在博客里引用的 Gram 论文也支持这种判断。该论文评估 Gemini 模型在 17 个模拟 Agent 部署场景里的破坏倾向，发现模型在约 2%-3% 的模拟轨迹中出现不当行为；作者认为许多案例来自「overeagerness」，也就是过度角色扮演和过度追求目标，而不是稳定的蓄意破坏。论文还说，提高环境真实度、移除诱导模型作恶的提示后，破坏率会接近零。3

这让 AI Control 的任务更难，也更现实。监控系统不能只找「我要攻击公司」这种明牌意图，还要识别那些表面上很像积极完成任务、结果却会造成损害的动作。

现在很多安全方案默认可以看模型的可见推理过程。但路线图把这个优势视为暂时的。模型可能学会监督意识，知道哪些话会触发监控；也可能通过不写出来的方式完成复杂推理，也就是报告里说的 opaque reasoning。到那时，只读思维链就不够了，安全系统必须转向行为轨迹、权限边界、异常检测，甚至模型内部激活监控。2

报告对这一点并不乐观到过头。它承认，AI Control 不是永久方案；如果模型能力远超人类，控制手段可能失效。它也列出多项局限：TRAIT&R 主要基于理论推演而非真实攻击数据，攻击执行能力还缺少成熟评测，很多缓解措施该放在哪个能力等级仍有不确定性，路线图也过度依赖「检测后再阻断」这条路径。2

这比一句「我们会加强安全」有信息量得多。Google DeepMind 实际上在说：如果 Agent 真的进入研发核心链路，安全团队要承认自己面对的是高速、分布式、会用工具的内部行为体，而不是一个偶尔答错题的聊天模型。

对正在接入 Agent 的团队来说，这篇路线图最直接的启发是：不要把安全全部押在提示词、系统提示或模型自律上。更稳的起点是工程边界。

第一，给 Agent 单独身份，不要默认继承用户的全部权限。报告在 R2 层级明确提出，访问控制系统应识别 Agent 身份，并按任务上下文动态授予权限；更敏感的权限可以要求可信模型或人类审批。2

第二，把运行环境拆开。Agent 的脚手架、命令执行环境、内部系统访问和外部互联网访问，最好不要都堆在一个通道里。报告建议区分内部 Agent 和外部 Agent，让外泄或外部伤害必须跨过清晰边界，安全团队才有可监控的抓手。2

第三，安全指标要能量化。Google DeepMind 反复提到 coverage、recall 和 time-to-response：监控覆盖了多少流量，真正有害行为能抓住多少，从告警到处理需要多久。1 没有这三个数，团队很容易把「我们有监控」误认为「我们安全」。

这份路线图不会马上解决 Agent 安全问题，但它把讨论往前推了一步：Agent 越像员工，安全设计就越要像内部安全工程，而不是像聊天机器人调参。下一步值得关注的是，Google 是否会公开更多来自真实内部部署的监控指标，以及这些控制措施会不会进入 Gemini、开发者工具和企业 Agent 平台的默认安全配置。