Docker 呼吁通过隔离与治理保障智能体安全

Docker 发布了一篇指南，介绍当 AI 智能体在人工监督有限的情况下浏览网页、运行代码、调用工具时会产生的五大安全风险。Docker 首席产品营销经理 Srini Sekaran 与产品经理 Eric Jia 联合撰文指出：让智能体具备价值的自主能力同时也导致传统应用安全控制措施变得不足。Docker 将隔离和治理（而非仅靠模型改进）作为主要的防御手段。 这篇 博文 "将提示词注入、工具滥用与投毒、过度自主、凭证泄露和数据窃取列为主要风险。Docker 认为这些风险有一个共同根因：智能体可以在运行时选择工具、将多个操作链接在一起，并且通常以启动者的权限运行。 “智能体不只是回答问题，它会自行浏览、运行代码和调用工具，因此一条错误或受操纵的指令可能变成实实在在的破坏，而不仅仅是一个错误的答案。”Eric Jia 和 Srini Sekaran， Docker " 传统的 Web 安全通常假设请求到达已知的端点并由确定性代码处理，但智能体并不符合这种模式。一个编码智能体在收到一条指令后，可能会读取文件、安装依赖项、修改配置、运行测试并提交代码。Docker 指出，一旦智能体被劫持或误导，它能执行的操作范围远大于传统服务。 提示词注入被视为标志性风险：攻击者无需直接攻陷系统，而是在智能体需要读取的材料中嵌入指令，例如网页、代码注释、问题或文档。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 的指南很好地总结了一个日益凸显的问题。其核心观点很有说服力：安全团队应假设智能体的输入可能是恶意的，并设计好周围的系统，使错误的决策不会变成大范围的妥协。困难的部分在于决定智能体真正需要哪些权限、这些权限如何过期，以及谁来审计这些权限下执行的动作。 查看英文原文： https://www.infoq.com/news/2026/11/docker-ai-agent-security/ "