Ohhnews

分类导航

$ cd ..
Jetbrains Blog原文

JetBrains Air云端Agent沙箱机制解析

#jetbrains air#ai代理#沙箱隔离#云端执行#安全防护

最近,我们在 JetBrains Air 中发布了云 Agent 的预览版。云 Agent 让你能够在 JetBrains 托管的云环境中远程运行 AI Agent,为它们提供一个隔离的工作空间,无需依赖你的本地机器。

以下是它在实际使用中的样子。在这个视频里,我在 IntelliJ IDEA 中启动了一个任务,从浏览器和手机上跟进它,并在 Agent 完成后审查它所做的更改。

云 Agent 目前面向组织用户开放,可通过 Air in IDEs 和浏览器中的 Air Teams 使用,面向个人用户的更广泛版本计划于稍后推出。但它们也牵涉到一个更大的问题:当 AI Agent 能够读取文件、执行代码、使用工具并与外部服务交互时,如何安全地运行它们。

在本文中,我将解释 Agent 沙箱化的含义、它为什么重要、目前有哪些执行方案,以及基于云的执行如何融入更广泛的沙箱化图景。

为什么 AI Agent 需要沙箱化

对 AI Agent 进行沙箱化,是指在隔离且严格受控的环境中运行 Agent,限制它可以访问哪些资源、允许执行哪些操作。沙箱不是授予对宿主机系统、网络或敏感数据的无限制访问权限,而是围绕文件、API 和外部服务实施预定义的边界,同时应用最小权限原则、资源限制、审计机制和追踪。

这种做法之所以重要,是因为现代 AI Agent 能够执行代码、使用工具并自主行动,这会带来各种风险,例如非预期的系统修改、数据泄露,以及当 Agent 行为异常或被攻陷时遭到利用。通过将 Agent 限制在定义明确的安全边界内,沙箱化可以限制故障或攻击造成的影响,为在开发、企业和生产环境中部署 AI Agent 提供更安全、更可靠的基础。

运行 AI Agent 的五种方式——及其安全权衡

我们可以归纳出启动 Agent 的五种主要场景,它们可分为两大类:本地和远程。

运行 Agent 的五种方式

本地部署与你的机器共享环境。远程部署则将 Agent 移到其他地方,并默认将其隔离。

Agent 运行的环境可以是:

  • 你自己的机器
  • 一个工作副本
  • 为每个任务新建的环境
类别模式运行环境默认与你的机器隔离由谁设置
本地本地工作区在你自己的工作副本中工作否——它可以离开工作目录无需设置;任何限制都必须由客户端强制执行
本地Git worktree在你机器上的独立副本中工作部分——它的文件更改与你的分开,但仍可离开该目录客户端创建 worktree
远程SSH通过 SSH 在你提供的机器上工作是你手动设置
远程Docker为每个任务在本地或远程主机上新建的容器中工作。Docker Sandboxes 为每个 Agent 使用一个 microVM是客户端,或组织管理员通过 Docker Sandboxes 设置
远程云为每个任务新建 VM、microVM 或容器中工作。Air 在 VM 内使用容器是自动,基于你的团队或组织管理员定义的设置

默认情况下,在本地场景中,Agent 很容易离开当前的工​​作目录,无论是无意的,还是由于提示注入所致。它们的文件系统和网络访问可以通过操作系统级的沙箱化工具加以限制(Linux 上的 landrun、macOS 上的 sandbox-exec、Windows 上的 Sandboxie)。不过,随后就由客户端(用户用来与 Agent 交互的程序,或 Claude Code、Codex 之类的 CLI 工具)来包装所启动的 Agent 并强制执行所需的策略。

远程执行默认提供更好的保障:Agent 的环境与开发者的环境相互隔离。Agent 对资源的访问可以通过文件系统和网络控制加以限制,从而缩小影响范围。

这些方式之间的主要区别,主要在于所需手动配置的量。SSH 主机需要用户自行提供机器并手动配置。Docker 既可以由客户端配置,也可以由组织管理员配置。Docker Sandboxes 更进一步,为每个 Agent 运行独立的 microVM。云解决方案则应基于你的团队或组织管理员定义的设置,自动处理环境的配置。

Air 中的云 Agent 沙箱化如何工作

为 Air 中的云 Agent 提供支持的 Agent 核心采用了 Docker Sandboxes 所用的方式。每个任务都会在云中启动一个 VM(microVM 即将推出),Agent 则在该 VM 内的 Docker 容器中运行。该 VM 被视为不可信:它不会在任务之间复用,且只被允许访问有限的内部资源。VM 中会设置一个代理,来自 Agent 容器的所有连接都经由它路由。

[LOADING...]

每个 Air 任务都在自己的 VM 中运行,Agent 位于网络代理之后的容器中。

默认情况下,代理只允许连接到预设的可信源代码管理和包注册表域名列表(例如 npm)。你可以为你的工具链、包管理器或内部服务添加域名,允许所有域名,或者完全关闭互联网访问。

机密信息以加密形式存储,并作为环境变量暴露给任务。团队成员可以使用共享机密而无需看到其值,个人机密则保持私密。每个任务还受开发者本人的仓库权限约束,因此它永远不会看到开发者本就无法访问的仓库。

Agent 在哪里运行,与其能做什么同样重要

Agent 沙箱化正成为安全使用 AI Agent 的重要一环。随着 Agent 变得能力更强、更加自主,问题不再仅仅是它们能做什么,还包括它们在哪里运行、能访问什么,以及一旦出现问题会造成多大影响。

基于云的执行是一种方式,可以默认提供更强的隔离、减少本地设置需求,并让组织对网络访问、环境配置和任务执行策略拥有更多控制权。

在组织中工作的开发者已经可以在 Air in JetBrains IDEs 和浏览器中的 Air Teams 中试用云 Agent。

有问题或反馈?在 X 上 @getsome_air 联系我们——Dennis 和 Air 团队会阅读提及并回复。