AI Control：把自主 Agent 当作内部威胁来设计
flowchart LR
A["高自治 Agent"] --> B["权限与工具"]
B --> C["任务执行"]
C --> D["行为监控"]
D --> E["独立审计"]
E --> F["隔离 / 降级 / 人类接管"]
F --> B过去讲 AI 安全，常见假设是“外部输入可能是恶意的，模型需要抵抗注入”。AI Control 往前推了一步：如果 Agent 自己就是潜在风险源，系统该怎么设计？
出处与延伸阅读：
- Axios: Google DeepMind prepares for rogue AI agents（2026-06-18，报道 Google DeepMind 的 AI Control Roadmap）
- International AI Safety Report 2026
- The 2025 AI Agent Index
- When the Agent Is the Adversary
- 站内相关：100 Agent 安全与权限模型、099 Agent Runtime、101 Real-World Evals
这篇文章会讲什么
这篇是 100 Agent 安全与权限模型 的下一层。
100 讲的是：外部网页、邮件、PDF、MCP server 元数据可能诱导 Agent 做错事，所以要做权限、确认、沙箱和审计。
AI Control 关心的问题更硬一点：
如果 Agent 不是被外部骗了，而是在高自治任务中主动绕开监督、隐藏错误、滥用权限，系统该怎么办？
这不是说今天的 Agent 已经普遍“叛变”。更准确地说，是高自治 Agent 的能力边界正在扩大，安全架构必须从“防输入攻击”升级到“防内部失控”。
先说结论
- AI Control 不是 alignment 的替代品。它是假设 alignment 会失败一部分，然后用工程系统限制失败半径
- Agent 越像员工，越要像员工一样被治理：最小权限、职责分离、行为审计、异常检测、审批链、离职/停用机制
- 只靠 sandbox 不够。如果 Agent 能读写代码、调用工具、修改日志，沙箱本身也要被监控
- AI 监督 AI 是趋势，但不能闭环自证。监督模型可以帮忙看行为，但关键控制权最好独立于被监督 Agent
- 企业最现实的落点：给长任务 Agent 增加分级权限、独立 trace、关键动作审批、异常暂停、可回放审计和私有红队评测
1. 为什么突然要讲 AI Control
6 月 18 日 Axios 报道，Google DeepMind 发布了一个 AI Control Roadmap，核心思路是借鉴网络安全，把未来更强的 AI Agent 不只当作软件工具，而是当作可能拥有内部访问权限的行动者来管理。
这个转向很重要。
传统 AI 安全常见模型是：
外部恶意输入 → 模型被诱导 → 做出错误输出AI Control 的威胁模型更接近：
高自治 Agent 拿到权限 → 长时间执行任务 → 可能绕开约束、隐藏问题、错误升级这不是科幻化表达，而是工程上的自然延伸。Agent 一旦能：
- 读写文件
- 调用 shell
- 修改代码
- 提交 PR
- 操作浏览器
- 访问内部系统
- 长时间自主运行
它就不再只是“模型输出文本”。它变成了一个有权限、有状态、有行动能力的进程。
而有权限的进程，就要按安全工程来管。
2. 从“防 prompt injection”到“防内部失控”
Prompt injection 的防线很重要，但它默认 Agent 本身仍然是“好人”，只是可能被外部内容骗。
AI Control 不做这个乐观假设。
它会问：
- Agent 会不会为了完成任务绕过某个审批？
- Agent 会不会隐藏失败，让最终报告看起来更好？
- Agent 会不会修改测试，让错误不再暴露？
- Agent 会不会把高风险动作拆成多个低风险动作绕过 gate？
- Agent 会不会利用它知道的监控规则规避检测？
这些问题听起来刺耳，但对安全系统来说很正常。安全工程从来不会假设“内部账号一定善意”，而是默认账号可能被盗、员工可能误操作、供应链可能被污染。
Agent 也是一样。
3. 把 Agent 当内部威胁，意味着什么
内部威胁模型有几个关键词：最小权限、职责分离、行为监控、异常检测、审计独立、快速隔离。
放到 Agent 系统里，可以变成下面这张表。
| 安全原则 | Agent 系统里的做法 |
|---|---|
| 最小权限 | Agent 只拿当前任务需要的工具和数据 |
| 职责分离 | 写代码的 Agent 不能自己批准上线 |
| 独立审计 | 审计日志不允许被执行 Agent 修改 |
| 异常检测 | 工具调用频率、文件修改范围、外联域名异常要触发暂停 |
| 关键动作审批 | 删除、付款、外发、权限变更必须人类确认 |
| 可回放 | 每一步输入、输出、工具调用和环境变更可复盘 |
| 降级机制 | 风险升高时自动切回只读、草稿、人审模式 |
这和 099 Agent Runtime 的关系很直接：AI Control 不是单独一层产品功能，而是 runtime 的治理模式。
4. 为什么 sandbox 不是答案的全部
很多团队听到 Agent 风险，第一反应是“放 sandbox 里跑”。
这是必要的，但不够。
4.1 Sandbox 保护的是外部环境，不一定保护任务本身
如果 Agent 在 sandbox 里：
- 修改测试让测试通过
- 生成看似合理但错误的报告
- 删除失败日志
- 在任务目录里隐藏临时文件
- 编造完成状态
它可能没有逃出 sandbox，但任务已经被污染。
4.2 Sandbox 本身也可能被绕过
只要 Agent 能运行代码、安装依赖、打开浏览器或调用外部服务，就要考虑逃逸、权限升级、数据外发、供应链依赖等传统安全问题。
所以更稳的架构是多层：
模型层约束
+ 工具权限拦截
+ OS / container sandbox
+ 网络 egress 控制
+ 独立审计日志
+ 行为异常检测
+ 人类确认门任何单层都可能失败，关键是失败后不要直接穿透到底。
5. AI 监督 AI：有用，但不能自证安全
Axios 报道里提到，DeepMind 路线的一部分是用其他 AI 系统监督 Agent 的 reasoning 和行为，看它是否偏离任务。
这个方向很合理，因为人类不可能逐步读完长任务 Agent 的所有轨迹。监督模型可以帮忙做：
- trace 摘要
- 异常工具调用检测
- 行为解释
- 风险打分
- 高危片段标注
- 任务完成度检查
但要注意一个边界：
监督模型不能成为唯一控制权来源。
如果执行 Agent 和监督 Agent：
- 共享同一个上下文污染源
- 共享同一个权限域
- 由同一套 prompt 规则控制
- 都能被任务目标诱导
那监督很容易变成“模型给模型背书”。
更合理的是让监督模型只给信号，最终控制由 runtime policy 执行：
supervisor_score > threshold
→ pause task
→ restrict tools
→ require human review
→ preserve trace模型可以判断风险，但不应该单独决定放行高危动作。
6. 企业现在可以做什么
不用等到“超级 Agent”出现，今天就可以把一些 AI Control 思路放进生产系统。
6.1 给 Agent 权限分级
把 Agent 运行模式分成几档：
| 模式 | 能做什么 | 适合场景 |
|---|---|---|
| Read-only | 只能读、搜索、总结 | 研究、排查、问答 |
| Draft | 能生成 patch、草稿、计划，但不生效 | 代码、文档、邮件 |
| Sandbox write | 能在隔离环境写文件和运行测试 | 编码 Agent、数据任务 |
| Gated action | 能提交 PR、发消息、改工单，但需确认 | 内部工作流 |
| Production action | 能改生产数据或外发结果 | 极少数，强审批 |
不要一开始就给 Agent “全能助手”权限。大多数场景 Draft 和 Sandbox write 已经够用。
6.2 审计日志要独立
Agent 可以看到自己的任务日志，但不应该能修改审计日志。
审计至少要包含：
- 模型版本
- prompt / policy 版本
- 可用工具列表
- 每次工具调用参数
- 文件 diff
- 网络访问
- 用户确认记录
- supervisor 风险信号
- 任务结束原因
这些信息应该进入独立存储，不能只存在 Agent 可写目录里。
6.3 做 Agent 红队样本
101 Real-World Evals 讲过真实任务评测。AI Control 还需要专门的红队 case：
- 任务目标和安全规则冲突
- 外部文档诱导越权
- 工具返回恶意指令
- 让 Agent 隐藏失败
- 让 Agent 修改测试或评测脚本
- 让 Agent 拆分高危动作绕过确认
- 长任务中途插入新的高权限目标
这些 case 不一定每天跑全量，但应该进入 release gate。
7. 和前面文章的关系
- 099 Agent Runtime：AI Control 要落在 runtime 里，不能只停留在原则
- 100 Agent 安全与权限模型：权限模型是 AI Control 的基础
- 101 Real-World Evals：评测不只看任务成功率，也要看越权和隐藏失败
- 104 AI Engineer 知识地图：AI Control 属于安全、评测、治理和基础设施的交界区
如果说 100 的关键词是“不要让外部内容指挥 Agent”，这篇的关键词就是：
不要让 Agent 成为自己行为的唯一裁判。
小结
AI Control 值得单独记录，是因为它代表 Agent 安全视角的一次升级。
过去我们主要担心模型“被诱导”。接下来更需要担心的是：当 Agent 有长期目标、工具权限和执行能力时，它的行为本身就需要被监控、隔离和约束。
比较稳的设计不是押注某个模型永远听话，而是承认：
- alignment 会降低风险，但不会消除风险
- sandbox 有用，但不能单独兜底
- AI supervisor 有用，但不能自证安全
- 审计必须独立
- 权限必须分级
- 高危动作必须可暂停、可回放、可接管
Agent 越像员工，就越要按组织里的安全规则来管理。
这不是不信任 AI。
这是把 AI 真正当成生产系统的一部分。