Docker 给智能体安全泼冷水：光靠模型自觉没用，得把笼子焊死

一个开发者让编码智能体清理旧代码库，智能体生成了一条尾部带 ~/ 的删除命令，没等确认就执行，把主目录清空了。另一个案例更贵：AWS 工程师以运维权限让智能体处理成本漏洞，智能体选择删除并重建生产环境，造成长达 13 小时的区域性中断。这些不是科幻桥段，而是 Docker 在新指南里列出的真实事故样本。

一分钟速览

• 发布方：Docker 首席产品营销经理 Srini Sekaran 与产品经理 Eric Jia 联合撰文。
• 五大风险：提示词注入、工具滥用与投毒、过度自主、凭证泄露、数据窃取。
• 共同根因：智能体可在运行时自选工具、串联多步操作，并通常继承启动者的权限。
• 核心主张：防御重心应放在隔离与治理，而不是指望模型自己分辨善恶。

为什么传统安全措施不够用

传统 Web 安全有一个隐含前提：请求会到达已知端点，由确定性代码处理。智能体不符合这个前提。它收到一句指令后，可能读文件、装依赖、改配置、跑测试、提交代码，每一步都在扩大行动半径。一旦被劫持或误导，它能造成的破坏远大于一个普通服务。

提示词注入被列为标志性风险。攻击者不需要攻破系统，只要在智能体必然会读的材料里埋指令——网页、代码注释、issue、文档都行。Docker 的判断很冷静：智能体无法可靠区分合法指令和注入指令，所以别把希望寄托在「更强的系统提示」上，而应限制被劫持后能触达的资源范围。

权限、工具与「YOLO 模式」

第二类风险来自工具调用。给智能体分配超出任务所需的工具，等于扩大攻击面；工具描述文本本身也可能藏指令，诱导误用。这与 OWASP 的智能体威胁研究结论一致，后者建议访问验证、行为监控、操作边界和防篡改日志。

第三类是过度自主，Docker 直接把「自动放行」的 YOLO 模式点名。效率是真的，风险也是真的：没有边界的长期授权，等于把生产环境交给一个不会累、也不会犹豫的执行者。第四类是凭证——智能体不该继承开发者的个人令牌，否则每个动作都带着这个人的全部权限。更合理的做法是短期、运行时注入、不出现在对话里的独立凭证。第五类是数据窃取，多智能体互相转交任务时会进一步放大，因此需要出站白名单，并把智能体之间的数据传递一律当作不可信输入。

行业正在收敛到同一条路

Docker 的建议并非孤例。谷歌的 GKE 安全蓝图主张用基于 gVisor 的沙箱隔离执行生成代码或调用不可信工具的智能体，并用 Model Armor 检查提示词与响应；Meta 开源的 LlamaFirewall 把注入检测、推理检查和生成代码静态分析组合起来；DeepMind 的 CaMeL 研究则跟踪模型周边的控制流与数据流。路径不同，共识相似：把智能体当成不可信代码来跑。

趋势洞察

过去两年，智能体的能力演示跑得比治理快得多。现在账单开始来了：一次误删、一次误重建，损失就足以让企业重新审视授权模型。接下来能落地的智能体产品，大概率都要回答三个问题——它能碰什么、它碰过什么、出事时怎么停。答不上来的，很难进生产环境。

对开发者而言，最实际的建议是提前把「最小权限＋短期凭证＋出站白名单＋可回滚」当成默认配置，而不是等出事再补。模型会越来越聪明，但把笼子焊死这件事，永远不能外包给模型自己。