Docker AI 治理：解锁代理自主权，安全地

Docker AI Governance：安全解锁代理自主性 | Docker

来源 URL：https://www.docker.com/blog/docker-ai-governance-unlock-agent-autonomy-safely/

发布时间：2026-05-12T11:00:09-07:00

你的笔记本电脑成为新的生产环境

代理是现代工作场所几十年来最大的生产力提升工具，而工程领域的变化最为明显。开发人员不再仅仅使用代理来自动完成函数。他们现在使用代理来阅读整个代码库、跨服务重构代码，并从头到尾交付整个产品。这种编码方式已经成为现实，正在主分支上部署，并且今天在世界各地的笔记本电脑上都在发生。

同样的变化也在其他职能中蔓延。一类名为Claws的新代理已经投入生产，它们发送电子邮件、管理日历、预订旅行、提取CRM数据、核对报告并查询生产系统。市场营销、财务、销售和支持部门正以与工程部门相同的速度采用这些工具，因为生产力的提升太大，无法忽视，而且率先行动的公司将会超越那些没有行动的公司。原本需要数个季度才能完成的全组织推广现在可以在几周内完成。

比采用速度更有趣的是这一切实际运行的地方。代理和Claws存在于企业花费二十年时间加固的系统之外。它们不在CI/CD管道后面，不在VPC内部，也不遵循IAM模型。它们在开发者的机器上运行，使用开发者的凭据，访问私有仓库、生产API、客户记录和开放互联网，通常在同一会话中。笔记本电脑现在成为了企业中最强大的节点，同时也变得最易受攻击。笔记本电脑和代理环境成为了新的生产环境，需要像生产环境一样进行治理。

治理实际需要解决的问题

大多数企业的本能反应是使用现有的工具，但这些工具都无法看到代理在做什么。CI/CD看不到它，因为代理不是流水线的一部分。VPC看不到它，因为笔记本电脑位于边界之外。IAM也看不到它，因为代理是以开发者的身份行事。结果是CISO无法知道代理接触了什么、运行了什么或数据流向了哪里，也无法告诉业务方放慢速度。这是所有安全领导者目前面临的困境。

剥离问题回到基本原理，代理有两种路径可以造成重大损害。一种是自身执行代码，触碰文件并打开网络连接；另一种是通过MCP服务器调用工具来对外部系统进行操作。治理这两条路径就等于治理了代理。错过其中任何一个，治理就是不完整的。

这就是任何值得认真对待的AI治理解决方案必须通过的测试，它有两个部分。控制措施必须存在于代理实际执行的运行时层，而不是作为代理可以绕过的建议规则。并且它们必须在代理最终运行的任何地方都一致地工作，因为代理不会一直停留在笔记本电脑上。它们会迁移到CI运行器、暂存集群和生产环境中。只在一个地方有效的策略是一个等待被发现的漏洞。

为什么选择Docker

Docker是唯一满足这两个条件的公司，原因在于其结构。

Docker构建了沙箱，它包含了第一条路径。每个代理会话都在基于微VM的隔离环境中运行，文件系统和网络访问由硬边界控制，这意味着强制执行发生在进程级别，而不是作为代理可以忽略的建议。Docker还构建了MCP网关，它包含了第二条路径。每次工具调用都会通过一个单一的瓶颈，在到达外部系统之前进行身份验证、授权和日志记录。这些在基础层面的控制措施，Docker沙箱和Docker MCP网关，使强制执行严格而非建议。我们拥有代理运行的基础架构，因此策略不是围绕他人的运行时的包装，而是运行时本身。

第二个部分使其持久有效。相同的沙箱原语在开发者的笔记本电脑上、Kubernetes内部以及跨云环境中运行，具有相同的安全策略模型和相同的执行保证。当代理从开发者的机器移动到CI运行器再到生产集群时，策略也随之迁移，因为在三个地方底层运行时都是相同的。没有其他供应商能这么说，因为没有其他供应商是运行时本身。端点安全工具不扩展到集群。集群安全工具不触及笔记本电脑。云安全工具不在两者上运行。Docker覆盖了这三个方面，因为Docker在所有三个地方实际执行代理。

Docker AI治理是建立在这个运行时之上的控制平面。它将沙箱和MCP网关转化为集中政策，一次定义于管理员控制台，强制执行在代理触及的每一个节点，并可从端到端审计。

Docker AI治理如何运作

从单一的管理员控制台，安全团队可以定义和执行针对四个控制面的策略：网络、文件系统、凭据和MCP工具。一个不需要每台机器单独设置且能在数千名开发者间一致工作的策略层。

网络和文件系统沙箱策略。 管理员为域、IP 和 CIDR 定义允许和拒绝规则，并为文件系统路径定义挂载规则，包括只读或读写范围。每个代理会话都在一个隔离的沙箱中运行，在该沙箱中只有批准的端点可达，只有批准的目录可挂载，强制执行发生在代理层的代理和挂载级别，而不是作为代理可以忽略的建议层。

凭据治理。 代理的危险程度与其能够认证的身份成正比，因此 Docker AI Governance 控制代理会话可以看到哪些凭据、令牌和密钥，将其范围限制在会话期间，并阻止传输到未经批准的目的地。开发人员不再将令牌粘贴到提示中，而安全团队也不再担心这些令牌最终去了哪里。

MCP 工具治理。 管理员通过组织范围内的管理策略控制可用的 MCP 服务器和工具，默认情况下阻止未经批准的服务器。每个 MCP 调用都通过与网络、文件系统和凭据请求相同的策略引擎进行处理，因此没有单独的配置表面和绕过路径。

基于角色的策略分配。 不同的团队需要不同程度的访问权限，合理地，安全研究可能需要比财务更广泛的 MCP 使用。创建策略组，通过您的身份提供商 (IdP) 分配用户，并在组织范围内的护栏之上叠加团队特定规则，这些护栏不能被覆盖。通过现有的 SAML 和 SCIM 集成扩展到数千名开发人员，无需针对每个用户进行设置。

审计和可见性。 每个策略评估都会生成一个结构化事件，包含用户身份、时间戳、会话上下文以及触发决策的规则，并且日志干净地导出到您现有的 SIEM 和合规系统。这是 CISO 批准大规模使用 AI 所需的证据，而不是默许其私下使用。

自动策略传播。 当开发人员进行身份验证时，他们的机器会拉取最新的策略，更新会自动到达每台设备。管理员定义一次策略，Docker 在所有地方强制执行。

这解锁了什么

CISO 获得了他们所缺少的治理层，并获得了批准大规模使用代理的信心，而不是阻止它。平台团队获得了一种简单的方式来设置治理：通过定义一次策略并在所有地方强制执行，具有完整的可审计性。这消除了在整个公司范围内扩展 AI 采用的操作负担。开发人员获得了代理最初承诺的速度和自主权，治理不会成为障碍。我们根据这些原则构建了 Docker AI Governance：代理应该是自主的，治理应该是透明的。

现已提供

Docker AI Governance 现已提供。如果您是试图填补 AI 治理缺口的安全领导者，或者是一个准备推出代理而不牺牲控制的平台团队，它是为您打造的。

[联系销售](https://www.docker.com/pricing/contact-sales/)以了解更多信息。