Docker谈智能体五大风险：隔离与治理比改模型更关键
Docker 发布指南，介绍当 AI 智能体在人工监督有限的情况下浏览网页、运行代码、调用工具时会产生的五大安全风险。
Docker 近日发布一份指南，梳理了 AI 智能体在人工监督有限的情况下上网、执行代码、调用工具时可能遇到的五类安全风险。该公司首席产品营销经理 Srini Sekaran 与产品经理 Eric Jia 联合撰文提到，智能体之所以有价值，靠的正是自主能力，可这份自主也让传统应用安全控制手段不再够用。Docker 给出的主防线是隔离加治理，而非只盯着模型改进。
博文列出的风险包括提示词注入、工具滥用与投毒、过度自主、凭证泄露和数据窃取。在 Docker 看来，这些问题的根子是同一个：智能体能在运行时挑选工具、把多步操作串起来，而且往往顶着启动者的权限干活。
一旦智能体自行去浏览网页、跑代码、调用工具，它就不再只是回答问题；此时一条出错或被操纵的指令，带来的可能不只是答错，而是真实的破坏。
Eric Jia 和 Srini Sekaran，Docker
传统 Web 安全的假设是：请求打到已知端点，由确定性代码来处理。智能体却不符合这套模式。一个编码智能体接到指令后，可能去读文件、装依赖、改配置、跑测试，再提交代码。Docker 指出，一旦它被劫持或被误导，能做的事情比传统服务多得多。
提示词注入被 Docker 视为最具代表性的一类：攻击者不必直接攻破系统，只要把指令藏进智能体要读的材料里，比如网页、代码注释、issue 或文档。文中举了一个例子，某个代码智能体执行了代码库内容中隐藏的指令，干了用户根本没要求的事。
给模型加几句约束指令就能根除提示词注入？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 这份指南恰好把随之而来的问题梳理了一遍。它讲得最扎实的一点是：安全团队要先把智能体的输入当成可能带恶意的，再围绕这个前提去搭系统，让一次错误判断不至于演变成大面积失守。不过真正难办的还在后头——智能体到底该拿到哪些权限、这些权限怎么到期作废、又是谁去查这些权限之下干了哪些事。
