Docker 谈智能体安全：隔离与治理比模型改进更关键

Docker 近日发布了一份指南，梳理 AI 智能体在人工监督有限的前提下浏览网页、运行代码、调用工具时可能出现的五大安全风险。Docker 首席产品营销经理 Srini Sekaran 与产品经理 Eric Jia 联合撰文表示，自主能力让智能体有了价值，却也令传统应用安全控制手段不再够用。Docker 给出的主要防御思路是隔离与治理，而不是只靠模型层面的改进。

博文列出的五类风险是提示词注入、工具滥用与投毒、过度自主、凭证泄露和数据窃取。Docker 认为它们共有一个根因：智能体能在运行时自行选择工具、把多个操作串联起来，而且往往以启动者的权限运行。

智能体可不光是回答问题，它还能自己上网浏览、跑代码、调用各种工具。这么一来，一条出错或被操控的指令，造成的就可能是真实损害，而不只是一个答错的回复。

Eric Jia 和 Srini Sekaran，Docker

过去的 Web 安全通常假设请求会抵达已知端点、由确定性代码处理，智能体却不符合这一模式。一个编码智能体接到指令后，可能去读文件、装依赖、改配置、跑测试、提交代码。Docker 指出，智能体一旦被劫持或误导，它能做的操作远比传统服务多。

提示词注入被看作标志性风险：攻击者不必直接攻陷系统，只需把指令藏进智能体要读取的材料里，比如网页、代码注释、问题或文档。Docker 举了一个案例：某个代码智能体执行了代码库内容中隐藏的指令，做了用户并未要求的操作。

在 Docker 看来，光给模型加约束指令很难根除提示词注入，因为智能体无法可靠区分合法指令和注入指令。它更倾向的办法是限制被劫持智能体能够访问的资源，这样即便注入得手，造成的影响也可控。

“智能体无法可靠区分合法指令和注入指令，所以防御思路是限制被劫持智能体能够触达的资源范围。”

Eric Jia 和 Srini Sekaran，Docker

第二类风险出在工具调用上。智能体要靠连接器、数据库查询、文件操作、代码执行来操作外部系统。Docker 警告，分配给智能体的工具超出任务所需，攻击面就会扩大；工具的描述文本本身也可能夹带隐藏指令，诱导智能体误用工具。

这与 OWASP 发布的指南方向一致。OWASP 在《智能体式 AI 威胁与缓解措施》研究工作中（InfoQ 于 2025 年 9 月报道）把工具滥用列为主要的新型威胁。攻击者操纵智能体滥用已授权的工具，在已授予权限范围内获取未授权的数据访问或操纵系统。OWASP 的建议包括访问验证、行为监控、操作边界设置和防篡改执行日志。

Docker 提出的第三类风险是过度自主。文章把“YOLO 模式”（智能体操作自动放行）当作无限制长期授权的典型例子。这种模式可能很高效，但必须放在安全边界内，防止智能体碰到不该触碰的系统和数据。

Docker 举了一个例子：一名开发者要求编码智能体清理一个旧代码库。智能体生成了一个带有尾部~/ 的 rm -rf命令，还没等确认就直接执行，把开发者的主目录给删了。Docker 还提到一位 AWS 工程师的例子：他给了编码智能体运维人员权限，让它去处理一个 Cost Explorer 漏洞，结果智能体选择删掉生产环境再重建，区域性中断持续了 13 小时。

凭证处理与这个问题密切相关。Docker 表示，智能体不应继承开发者的个人令牌，否则每个操作都会带上该用户的全部权限。它建议改用独立的短期凭证，在运行时注入，并避免出现在对话中。提示词、配置文件或镜像环境变量里的密钥同样有风险，因为注入的指令有可能从智能体上下文中读到这些密钥。

数据窃取是最后一个风险点。智能体若有网络访问权限，上下文里又带着敏感信息，就可能把这些内容发到不该去的地方。Docker 称，在多智能体系统里，一个智能体把工作交给另一个智能体时，这种风险会更大。Docker 给出的办法是：配好网络出站白名单，并且把任意智能体之间转交的数据都当成不可信输入来处理。

这些建议和 InfoQ 报道过的其他方案思路相近。谷歌的 GKE 安全蓝图（2026 年 7 月报道）建议基于 gVisor 的 GKE Sandbox，用于隔离执行生成代码或调用不可信工具的智能体。它还使用 Model Armor 检查提示词和响应结果中的注入和敏感数据泄露。更早之前，Meta 开源了 LlamaFirewall，结合了提示词注入检测、推理检查和生成代码静态分析。谷歌 DeepMind 的 CaMeL 研究（同样被 InfoQ 报道）则采取了不同的方法，跟踪模型周边的控制和数据流。

Docker 的方案是 Docker Sandboxes 和 AI Governance。Sandboxes 让每个智能体运行在一次性微虚拟机中，并定义文件系统和网络控制。AI Governance 定义和约束智能体可以执行的操作、可用的工具和凭证。Docker 表示，隔离是见效最快的起点，治理则为整个智能体集群提供监督。

社区里的讨论说明，设计层面的问题，光靠隔离解决不了。r/AI_Agents 有个讨论帖，评论者 HectaMan 在帖中写道，团队应该先把租户模型和风险模型评估清楚。此人认为 Docker 或许用着方便，但给出的权限仍可能过高，还指出它禁用了约 40 个特权系统调用，可用的仍有约 500 个。其建议是默认拒绝权限、遵循最小权限原则、设置策略执行点，并对信息流加以控制。

另一位评论者 Groady 认为，Docker 在本地跑个人智能体时表现不错，可一旦智能体是替别人执行代码，共享内核就有隐患。这种情况下，此人建议改用微虚拟机，或者基于 gVisor 做隔离。讨论反映出的关键在于：真正要比的不是“要不要容器”，而是隔离边界和工作负载的信任边界是否对得上。

Docker 这份指南把一个问题摆上了台面：编码智能体已经能往代码库、云账户和生产系统里写东西，这类权限带来的风险正越来越明显。指南的核心判断是，安全团队要把智能体的输入当成可能带恶意的东西来看待，再把周边系统设计好，让一次错误决策不至于演变成大范围失守。真正难办的是另外几件事——智能体到底需要哪些权限、这些权限怎么到期收回、权限之下执行的操作又由谁来审计。