Runtime Enforcement, Not Runtime Advice

AI 治理：运行时执行，而非运行时建议 | Docker

Docker Captain

运行时执行，而非运行时建议

发布于 2026年7月22日

Karan Verma

在第1部分中，我们探讨了传统安全模型在处理自主代理时面临的挑战。随着开发者开始将越来越多的工作委托给AI系统，越来越多的活动发生在仓库、CI/CD流水线和部署环境等熟悉检查点之外。这自然引发了一个新问题：如果治理需要存在于代理实际执行工作的位置，那么在实践中会是什么样子？

仅靠政策并不足够

大多数组织已经拥有相关政策。

• 不得泄露客户数据。
• 未经授权不得访问生产系统。
• 不得执行不可信代码。
• 不得在未经批准的工作流程中使用凭证。

挑战不在于编写这些规则，而在于当软件系统能够越来越多地自主采取行动时，如何执行这些规则。这时一个关键区别显现出来：

提示可以影响行为。

运行时可以限制行为。

随着代理获得对文件、终端、API和外部工具的访问权限，这种区别变得越来越重要。

开发者信心背后的三个边界

当我简化这个问题时，大多数治理挑战都涉及三个领域。在单独分析这些边界之前，值得先思考为什么它们重要。当治理讨论仅聚焦于安全时，很容易忽略开发者为何关心这些控制。大多数开发者并不是要求更多限制，而是要求可预测性。在将工作委托给代理之前，开发者希望了解：

• 它可以访问什么？ • 它可以修改什么？ • 它可以使用哪些工具？ • 它可以使用哪些凭证进行操作？

这些答案越清晰，就越容易信任代理处理重要任务。从这个意义上说，边界不仅仅是安全控制。它们是建立信任的机制，帮助将代理从有趣的实验转变为日常开发工具。

1. 执行边界

第一个边界是执行。

代理可以：

• 读取文件
• 修改代码
• 执行命令
• 安装依赖
• 建立网络连接

考虑一个正在排查失败测试套件的编码代理。它可能会检查配置文件、生成临时脚本、安装调试依赖、执行诊断命令，并在人类审查最终结果之前反复运行测试。

治理决定了这些操作发生的边界。更重要的是，它让开发者确信这些边界确实存在。当团队了解这些限制的位置以及它们如何被强制执行时，他们更愿意将工作委托给代理。

2. 工具边界

现代代理很少单独运行。

它们与以下系统交互：

• 源代码控制平台
• 问题跟踪系统
• 沟通工具
• 云服务
• 内部API
• 数据库

一个编码代理可能创建拉取请求、更新Jira工单，或通过MCP连接的工具检索文档。这些操作不需要本地代码执行，但仍然会影响真实系统。这意味着治理不仅关乎执行，还关乎访问权限。只控制其中一个而忽略另一个会留下重大盲区。

3. 凭证边界

大多数有用的代理最终都需要访问某些有价值的内容。

这可能是：

• 一个GitHub仓库

• 云环境

• 内部 API

• 数据库

• 客户支持系统

这些系统背后涉及凭证、权限和身份控制。问题的关键不在于代理是否能使用某个凭证，而在于如何控制、监控和审计访问权限。随着代理自主性的提升，凭证治理的重要性将与执行治理同等关键。

简化的架构视图

从宏观层面来看，治理可以理解为对执行、工具访问和凭证的边界约束。

图2. 代理治理需要在执行、工具访问和凭证三个层面建立控制机制。运行时强制执行为隔离、策略和可见性提供了基础。

隔离的作用

计算领域最古老的安全部件之一是隔离。容器、虚拟机和沙箱环境的存在目的相同：为软件可访问和影响的范围创建边界。随着代理能力的增强，这些概念变得愈发重要。组织不必允许自主系统无限制地访问开发环境，而是可以引入受控的执行边界。目标不是降低代理的能力，而是使能力变得可预测。Docker沙箱就是隔离概念被应用于代理执行流程的一个例子，它有助于更清晰地界定代理可访问和执行的范围。

隔离能够回答关键问题：

• 代理可以访问什么？

• 它可以修改什么？

• 它可以执行什么？

• 它可以与什么通信？

缺乏边界时，这些问题将难以得到一致的答案。

超越代码执行的治理

执行只是故事的一部分。现代代理越来越依赖外部工具和服务。编码代理可能更新问题跟踪系统，支持代理可能检索文档，平台代理可能与云基础设施交互。这带来了第二个治理挑战：不仅要关注代理能执行什么，还要关注代理能访问什么。随着组织采用MCP等协议将代理与工具连接，可见性和策略的重要性与能力本身同等关键。目标不是阻止代理完成有用的工作，而是确保这些工作始终处于可观察、可控和可追责的状态。

通过边界建立信任

AI治理有时被描述为对自主性的限制。实际上，它的作用截然不同。当代理的可见性、访问权限和执行范围存在明确边界时，组织更可能信任这些代理。信任并非仅源于能力，而是源于能力与可见性、控制和问责的结合。这就是为什么治理最终超越了单纯的基础设施问题。清晰的边界带来可预测性，可预测性产生信心，而信心正是开发者将越来越多工作委托给能力不断增强的代理的基础。随着代理的普及，那些早期建立这种信心的组织可能能够更快前进，而非更慢。

在第三部分中，我们将探讨为什么治理最终既是开发体验挑战也是安全挑战，以及那些平衡好这两方面关系的团队可能能够更快而非更慢地采用AI代理。

了解更多

• 阅读关于AI代理为何需要隔离的文章

• 阅读本AI治理系列的第一部分

• 了解 Docker 的 AI 治理解决方案如何在所有工具中发挥作用

AI Agent

Docker 沙箱

社区

目录

相关文章

• 2026年7月16日 开发者已改变，开发者大会也应随之改变

发现 Docker 为何与 WeAreDevelopers World Congress North America 联合主办，以及 AI Agent 如何正在改变软件开发和开发者社区。Terri Avnaim 立即阅读

• Docker 资深工程师 2026年7月22日 运行时管控，而非运行时建议

探索运行时层的治理机制，了解为何隔离、策略执行和受控工具访问正成为智能体系统的基石。Karan Verma 立即阅读

• 2026年7月22日 智能体 AI 需要防护措施，而非猜测推断

Docker 聚合企业安全领导者共同应对智能体 AI 的最大挑战：如何在不减缓开发者效率的前提下治理 AI 智能体。以下是他们的见解。Mark Lechner 立即阅读

• 2026年7月20日 编码智能体恐怖故事：那个删除生产环境的智能体

了解一个 AI 编码智能体如何引发 13 小时停机事故，以及 Docker 沙箱如何通过作用域身份和隔离执行降低风险。Ajeet Singh Raina 立即阅读