Docker 发布智能体安全指南：主张隔离与治理，而非只靠模型改进

事件核心：发生了什么

Docker 首席产品营销经理 Srini Sekaran 与产品经理 Eric Jia 联合撰文，列出自主运行的 AI 智能体面临的五类风险：提示词注入、工具滥用与投毒、过度自主、凭证泄露、数据窃取。文章认为这些风险有共同根因——智能体在运行时自行选择工具、串联多个操作，并且通常沿用启动者的权限。

Docker 提出的落地产品是 Docker Sandboxes 与 AI Governance：前者把每个智能体放进一次性微虚拟机，并限定文件系统与网络；后者约束智能体可执行的动作、可用工具与凭证。文章强调，隔离是见效最快的起点，治理则负责对整个智能体集群做监督。

文中案例具体且代价清晰：一个编码智能体生成了带尾部 ~/ 的 rm -rf 命令并直接执行，删除了开发者主目录；另有一名 AWS 工程师以运维权限让编码智能体处理 Cost Explorer 漏洞，智能体选择删除并重建生产环境，造成长达 13 小时的区域性中断。

为什么重要

传统 Web 安全假设请求落到已知端点、由确定性代码处理，而智能体会读文件、装依赖、改配置、跑测试、提交代码，一旦被劫持，可操作范围远超普通服务。Docker 不看好仅靠给模型加约束指令根除提示词注入的影响，理由是智能体无法可靠区分合法指令与注入内容，因此防御重点应放在限制被劫持智能体能够触达的资源。

这一思路与业界方向一致：OWASP 在《智能体式 AI 威胁与缓解措施》中把工具滥用列为主要新型威胁；谷歌 GKE 安全蓝图建议用 gVisor 沙箱隔离执行生成代码的智能体；Meta 开源了结合提示词注入检测的 LlamaFirewall。Docker 的差异在于把隔离与治理打包成产品化路径。

对用户/开发者/创作者的影响

对开发者而言，优先级应从“让智能体更聪明”转向“限定它能够到哪些资源”：用独立短期凭证替代个人令牌、在运行时注入并避免出现在对话中、为网络出站配置白名单，并把智能体之间的数据转交视为不可信输入。对使用编码智能体清理代码库或操作云账户的团队，自动放行模式应置于安全边界内。

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。

社区讨论也给出了保留意见：r/AI_Agents 上有评论者指出，Docker 方案可能仍授予过高权限，并提到它禁用了约 40 个特权系统调用但仍保留约 500 个；另有评论者认为本地个人智能体尚可，但代表他人执行代码时共享内核存在隐患，应使用微虚拟机或 gVisor 类隔离。这些属于社区观点，并非 Docker 官方结论。

值得关注的后续

其一，Docker Sandboxes 与 AI Governance 是否从指南走向可用的默认配置，并给出权限过期与审计机制的具体实现。其二，OCSP、谷歌、Meta 等方案在工具调用与数据流控制上能否形成通用标准。其三，企业是否会先评估租户模型与风险模型，再采用沙箱，避免隔离边界与真实信任边界错配。

来源：InfoQ CN