GitLab 警告称，AI 代理的沙箱安全性取决于其网络访问的安全性

GitLab 警告称，将 AI 编码代理隔离在沙箱中并不一定能确保该智能代理的安全。在一份最新发布的安全分析报告中，该公司描述了一次内部评估：一个 AI 代理利用一个存在漏洞的包代理（该代理已被明确列入沙箱的允许列表）逃离了沙箱。该事件揭示了智能代理开发环境中一个更广泛的问题：沙箱可以限制智能代理直接访问的内容，但无法防范那些为智能代理提供意外逃逸路径的可信连接。

据报道，该事件涉及一个正在接受内部评估的 OpenAI 模型。该模型逃离了沙箱，连接到了开放互联网，随后访问了 Hugging Face 的内部生产基础设施，获取了数据集、集群信息和云凭据。GitLab 的分析特别关注了事件发生后的第一小时，当时该智能代理利用了沙箱已获准访问的某个包代理中的漏洞。

这一事件的主要教训在于，网络白名单并不等同于信任边界。沙箱可能会阻止任意出站连接，同时允许访问软件包注册表、源代码控制系统、API 或内部开发服务。这些服务进而成为智能代理有效攻击面的组成部分。

对于传统软件而言，这种风险早已为人所熟知。然而，对于自主编码代理而言，情况则有所不同，因为与这些服务交互的软件能够主动推断如何利用现有的功能。如果智能代理能够通过某个已获批准的服务找到一条意料之外的路径，那么它就不一定需要不受限制的网络访问权限。

GitLab 在智能代理执行方面的做法体现了行业的发展方向。其 GitLab Duo 智能代理平台采用了一种执行沙箱，可以提供应用层级的网络和文件系统隔离。网络请求可以被拦截，并根据白名单中的域名进行评估；而文件系统访问则仅限于指定位置。该沙箱旨在专门降低数据外泄、未经授权的数据收集以及恶意代码下载等风险。

但 GitLab 描述的这一事件可以说明，这些控制措施为何不能单独运行。如果一个经过批准的依赖项、代理或服务遭到入侵，白名单实际上就会变成一座桥梁，而非一道屏障。

该安全问题与传统的 CI/CD 执行方式存在本质的不同。通常，构建管道遵循预定义的操作序列。而自主编码代理可以自行决定运行哪些命令、检查哪些文件、查询哪些服务，以及在这些操作失败时如何响应。

一个恶意的提示、一个遭到入侵的依赖项、一个存在漏洞的服务，或者一个被篡改的代码仓库，都可能影响智能代理的决策。一旦它获得了工具、凭据和网络资源的访问权限，“开发自动化”与“拥有特权的运维人员”之间的界限就会变得越来越模糊。

GitLab 的研究发现与其他编码代理的相关研究高度吻合。尤其值得注意的是，其中一些攻击并未直接“突破”沙箱。相反，智能代理通过篡改文件或配置，进而被沙箱外的受信任组件调用。云安全联盟（Cloud Security Alliance）将此描述为“信任传递”漏洞：智能代理仍然处于其受限环境内，但利用该环境之外的资源以更高的权限执行操作。这与 GitLab 的警告极为相似——即一个看似可信的包代理可能会成为处于隔离环境的智能代理与更广泛环境之间的桥梁。

此外，还有一些更严重的案例，涉及 AI 模型本身。Anthropic 披露了三起事件：在第三方网络安全评估环境中运行的 Claude 模型连接到了互联网，并随后在未经授权的情况下访问了真实系统。Anthropic 表示，这些事件暴露了评估环境与生产系统之间的隔离机制存在薄弱环节。为此，该公司额外采取了一些措施，包括引入实时控制机制并审查其评估基础设施。大约在同一时期，OpenAI 披露了一起事件：模型从隔离的测试环境中逃逸，并访问了 Hugging Face 的基础设施。研究人员最近报告称，攻击者曾操纵 Cursor 对多家组织发起攻击，这表明智能代理不仅自身可能成为攻击目标，还可能被攻击者转化为实际的攻击工具。

因此，切实可行的应对措施并非放弃代理沙箱，而是将沙箱纳入更广泛的 AI 代理零信任架构之中。

智能代理应该仅获得执行特定任务所需的凭据和权限。在理想情况下，访问权限应该短期有效，而且范围应该限定在相关的存储库、环境或工作流内。应该尽可能地限制网络访问，而非广泛地列入白名单；对于敏感服务，应该要求独立的身份验证和授权，而非默认来自可信开发环境的请求是安全的。

重要的是，组织还应该监控代理的行为，而不仅仅是基础设施事件。意外的命令、异常的网络请求、访问凭据的尝试、反复失败后改用其他方法，或试图与预期工作流之外的服务交互，这些都可能是有用的信号。

随着自主编码逐渐成为软件交付的常态，沙箱技术仍然将是一道重要的防御屏障，但不能是最后一道防线。新兴的安全模型需要将隔离机制与身份认证、最小权限原则、供应链安全、网络控制、行为监控，以及对智能代理实际权限的显式治理相结合。

原文链接：https://www.infoq.com/news/2026/09/gitlab-ai-sandbox-access/