为什么编程 Agent 应该运行在远程沙箱中
英文标题：🔶 Why coding agents belong in remote sandboxes
如今的编程 Agent 不仅生成代码，还会执行命令、安装依赖、启动服务和访问网络，因此若直接运行在开发者笔记本上，往往会继承 SSH 密钥、云凭证、VPN 路由和浏览器会话等高权限访问能力。文章援引 Salt Security 的研究指出，90% 的安全负责人担忧 AI 生成代码的风险；风险不仅在于代码质量，更在于 Agent 在个人设备上不受约束地运行。远程沙箱通过隔离工作区、按需注入密钥、限制网络、集中审计和临时环境等机制，为团队建立可控边界。对企业而言，远程沙箱并非取代 Claude Code、Codex 等工具的本地权限控制，而是在其之外增加统一的组织级安全与治理层。
5.9 KB
125.3 KB
125.3 KB
中文
如今的编程 Agent 不只是编写代码；它们还会操作软件环境。Agent 会检查代码仓库、运行 shell 命令、安装依赖、启动服务、打开浏览器、调用 CLI、读取测试输出，并在开发者离开期间持续工作很长时间。
这种能力很有用，但也改变了安全模型。当公司在开发者笔记本电脑上运行 Agent 时，Agent 往往会获得与开发者相同的访问权限。这可能包括 SSH 密钥、云凭证、软件包令牌、浏览器会话、本地文件、VPN 路由和内部系统。这些访问权限中的许多可能会在一台笔记本电脑上保留多年。
企业对此的担忧正在迅速上升。Salt Security 的研究发现，90% 的安全负责人担忧 AI 生成代码带来的风险；而 Red Hat 则警告称，不受限制的 AI 辅助开发会造成安全与合规缺口。人们担心的不只是糟糕的代码，而是能力日益增强的编程工具在员工个人笔记本电脑上不受控制地运行时会发生什么。
本地 Agent 会继承笔记本电脑的访问权限
大多数本地编程 Agent 的配置，都始于一个合理的假设：Agent 应该能够使用与开发者相同的工具。但在实际中，开发者笔记本电脑通常拥有远超单个任务所需的访问权限。
最明显的风险是凭证暴露。一台笔记本电脑可能存有部署密钥、GitHub 令牌、云配置文件、数据库 URL、包管理器令牌、SSH Agent 访问权限，以及原本从未计划纳入 Agent 任务的一次性密钥。
Agent 并不需要怀有恶意意图，也可能泄露密钥。它可能在日志中打印环境变量，或将凭证加入生成的代码。它还可能运行会显示敏感数据的诊断命令。
接下来是网络访问风险。笔记本电脑通常可以访问内部工具、预发布系统、管理面板和私有软件包注册表。正在排查测试失败问题的 Agent，可能会发起 HTTP 请求、运行 CLI、拉取依赖或跟随链接，却并不了解哪些系统是敏感系统。如果 Agent 能够到达与开发者相同的所有位置，那么“就让 Agent 自行调查”就会成为安全问题。
最后，本地 Agent 很难被持续、一致地审计。终端记录或许能显示一些命令，但通常无法完整记录环境边界：存在哪些密钥、可访问哪些网络路径、有哪些长期运行的服务，或代码仓库以外还有哪些文件可供访问。
远程沙箱让团队能够控制访问权限
远程沙箱会将 Agent 的工作环境迁移到由公司控制的基础设施中。与其把一个长期存在的个人工作站交给 Agent，不如让每次执行都在专用环境中进行，其中仅包含任务所需的代码仓库、工具和项目配置。
这很重要，因为团队可以决定 Agent 获得哪些访问权限，而不是继承某位开发者笔记本电脑上碰巧存在的一切权限。
- 代码仓库隔离： 每次实现任务都可以在自己的独立空间中工作，因此并行 Agent 不会互相覆盖文件，也不会依赖开发者尚未清理的工作树。
- 范围受限的密钥： 沙箱只获取项目所需的密钥，而不是笔记本电脑上存在的全部凭证。
- 网络控制： 环境可以将出站访问限制为已批准的域名和软件包注册表，而不是继承广泛的 VPN 或工作站访问权限。
- 临时状态： 团队可以在任务结束后丢弃沙箱，从而清除临时文件、缓存、后台进程和意外变更。
- 集中式审计记录： 团队可以在一个地方审查 Agent 的命令、日志、差异和决策。这些记录会随工单保留，而不会分散在个人设备中。
远程沙箱也能降低工程风险。本地 Agent 工作被孤立在单台机器上：团队成员无法轻易介入、复现环境，或确认究竟是哪些本地设置改变了结果。在远程沙箱中，团队共享项目配置、服务、启动命令、测试命令和密钥。此外，每个并行实现任务都在独立沙箱中运行，因此 Agent 可以同时工作，而不会互相干扰文件、进程或数据库。
切换到远程沙箱并不意味着无条件信任每一个 Agent。它意味着，每个 Agent 都能在更严格、可控的环境中发挥作用。
本地沙箱又如何？
当然，编程 Agent 并不会完全在笔记本电脑上自由活动。Codex、Claude Code 以及其他 Agent 都提供不同程度的本地沙箱、权限提示、命令审批、文件系统限制和网络控制。本地沙箱已经有了很大改进，团队也应该使用它们。
不过，本地沙箱和远程沙箱解决的是不同问题。
本地沙箱是在开发者自行控制的工作站内部增加一层保护。具体的保护能力取决于工具、操作系统、shell 配置、项目设置，以及开发者当下授予的权限。它可能减少意外文件访问，或要求在执行高风险命令前获得批准，但它仍然紧邻这位开发者的凭证、浏览器会话、VPN 路由、软件包缓存、本地数据库和个人配置。
本地沙箱中更严格的权限也可能使开发者转向 YOLO 模式。在一篇关于本地编程 Agent 安全性的文章中，Nori 的 Amol Kapoor 描述了自主性、便利性与本地控制之间的矛盾。更严格的本地权限确实有帮助，但也会造成审批疲劳。这会使开发者逐渐转向限制更少的模式，而宽松模式会让 Agent 更接近开发者机器上的一切资源。
对于个人开发者而言，本地沙箱可以是处理轻量任务的良好默认选择。但对于需要在团队范围内标准化 Agent 使用方式的公司，更困难的问题适用于整个组织：
- 我们能否一次性定义默认的组织级或项目级网络策略，而不是依赖每台笔记本电脑的设置？
- 我们能否只在项目需要时共享密钥，而不是仅因为开发者拥有密钥，就让 Agent 获得默认访问权限？
- 无论由谁启动，每次实现任务能否都从一个干净的环境开始？
- 团队能否在一个地方审查工作日志、被阻止的网络请求、差异和环境配置？
- 我们能否监控整个组织中的 Agent 使用情况和 token 成本？
远程沙箱不会取代工具级沙箱。它会在工具级沙箱之外增加一个由团队控制的边界。编程 Agent 在沙箱内部仍可拥有命令审批和文件系统控制，但沙箱本身不再是开发者的笔记本电脑。
远程沙箱应当包含什么
只有真正受到约束的沙箱才有价值。至少，公司应当具备以下能力：
- 每次 Agent 尝试使用全新且隔离的工作区。
- 为运行时、服务、启动命令和测试命令提供项目级配置。
- 显式、范围受限且可撤销的密钥注入。
- 默认受限的网络沙箱，以及针对新增域名的审批路径。
- 展示命令执行、被阻止访问、环境配置和 Agent 推理过程的日志。
- 在变更合并或部署前始终由人工掌控的审查工作流。
- 用于监控全公司 token 支出、Agent 使用情况和工作区活动的使用仪表盘。
这正是 Superconductor 围绕其构建的模式。每个 Agent 都会获得一个远程云环境，其中包含所需的项目配置、范围受限的凭证、网络策略、工作日志、实时预览和审查上下文。团队还可以使用网络沙箱和工作区使用情况可见性，在全公司范围内控制和审查 Agent 活动。
随着编程 Agent 成为软件团队的常规组成部分，“Agent 在哪里运行？”将成为一个安全架构问题。对大多数公司而言，答案不应是“开发者碰巧在哪台终端上打开了窗口，就在哪里运行”。
English / 原文
Today's coding agents don't just write code; they operate software environments. Agents inspect repositories, run shell commands, install dependencies, start services, open browsers, call CLIs, read test output, and keep working for long stretches while a developer is away.
That power is useful, but it changes the security model. When a company runs agents on developer laptops, the agents often get the same access as the developers. This can include SSH keys, cloud credentials, package tokens, browser sessions, local files, VPN routes, and internal systems. Much of this access can remain on a laptop for years.
Enterprise concern about this is rising quickly. Salt Security research found that 90% of security leaders are concerned about risks from AI-generated code, while Red Hat has warned that unrestricted AI-assisted development creates security and compliance gaps. The concern is not just bad code. It is what happens when increasingly capable coding tools run unchecked on individual employee laptops.
Local agents inherit laptop access
Most local coding-agent setups begin with a reasonable assumption: the agent should have access to the same tools as the developer. In practice, though, a developer laptop usually contains more access than one task needs.
The most obvious risk is credential exposure. A laptop may have deploy keys, GitHub tokens, cloud profiles, database URLs, package manager tokens, SSH agent access, and one-off secrets that were never meant to be part of an agent task.
An agent does not need malicious intent to expose a secret. It can print an environment variable in a log or add a credential to generated code. It can also run a diagnostic command that shows sensitive data.
The next risk is network access. A laptop can usually reach internal tools, staging systems, admin panels, and private package registries. An agent troubleshooting a failing test may make HTTP requests, run a CLI, fetch a dependency, or follow a link without understanding which systems are sensitive. If agents can reach all the same places as the developer, "just let agents investigate" becomes a security concern.
Finally, local agents are hard to audit consistently. A terminal transcript may show some commands, but it usually does not capture the full environment boundary: which secrets existed, which network paths were reachable, which long-running services were present, or which files outside the repository were available.
Remote sandboxes let teams control access
Remote sandboxes move the agent's working environment into company-controlled infrastructure. Instead of giving an agent a long-lived personal workstation, each implementation runs in a dedicated environment with the repository, tools, and project configuration that the task needs.
This matters because teams can decide what the agent gets access to, instead of inheriting whatever happens to be on one person's laptop.
- Repository isolation: Each implementation can work in its own lane, so parallel agents do not trample one another's files or depend on a developer's dirty working tree.
- Scoped secrets: The sandbox only gets the secrets the project needs, not every credential present on a laptop.
- Network controls: The environment can restrict outbound access to approved domains and package registries instead of inheriting broad VPN or workstation access.
- Temporary state: The team can discard the sandbox after the task. This removes temporary files, caches, background processes, and accidental changes.
- Central audit records: The team can review agent commands, logs, diffs, and decisions in one place. These records stay with the ticket rather than being scattered across personal machines.
Remote sandboxes also reduce engineering risk. Local agent work is siloed on one machine: teammates cannot easily jump in, reproduce the environment, or identify the local settings that changed the result. In a remote sandbox, the team shares the project setup, services, startup commands, test commands, and secrets. Plus, each parallel implementation runs in its own isolated sandbox, so agents can work at the same time without stepping on one another's files, processes, or databases.
Switching to a remote sandbox doesn't mean every agent is trusted unconditionally. It means every agent is useful inside a tighter, controlled environment.
What about local sandboxes?
Of course, coding agents don't completely roam free on laptops. Codex, Claude Code, and other agents all include multiple degrees of local sandboxing, permission prompts, command approval, filesystem restrictions, and network controls. Local sandboxing has gotten much better, and teams should use it.
However, local and remote sandboxes solve different problems.
Local sandboxing adds a protection layer inside a developer-controlled workstation. The exact protection depends on the tool, operating system, shell configuration, project setup, and the permissions an individual developer grants in the moment. It may reduce accidental file access or require approval before risky commands, but it still lives near that one developer's credentials, browser sessions, VPN routes, package caches, local databases, and personal configuration.
Stricter permissions in local sandboxes can also lead to developers gravitating towards YOLO mode. In a post about local coding-agent safety, Amol Kapoor from Nori describes the tension between autonomy, convenience, and local controls. Stronger local permissions help, but they also create approval fatigue. This leads developers to drift towards more permissive modes, and permissive modes bring the agent closer to everything on the developer's machine.
For an individual developer, local sandboxes can be a good default for lightweight tasks. For a company standardizing agent usage across a team, the harder questions apply to the whole organization:
- Can we define a default org-wide or project-wide network policy once, instead of relying on each laptop's settings?
- Can we share secrets only when a project needs them, instead of giving agents default access just because a developer has them?
- Can every implementation start from a clean environment, regardless of who launches it?
- Can the team review work logs, blocked network requests, diffs, and environment setup in one place?
- Can we monitor agent use and token costs across the org?
Remote sandboxes do not replace tool-level sandboxing. They add a team-controlled boundary around it. A coding agent can still have command approvals and filesystem controls inside the sandbox, but the sandbox itself is no longer the developer's laptop.
What remote sandboxes should include
A sandbox is only useful if it is actually constrained. At a minimum, companies should expect:
- A fresh, isolated workspace for each agent attempt.
- Project-level setup for runtimes, services, startup commands, and test commands.
- Secret injection that is explicit, scoped, and revocable.
- Network sandboxing with a restricted default and an approval path for new domains.
- Logs that show command execution, blocked access, environment setup, and agent reasoning.
- A review workflow that keeps humans in control before changes are merged or deployed.
- A usage dashboard for monitoring token spend, agent usage, and workspace activity across the company.
This is the model Superconductor is built around. Each agent gets a remote cloud environment with the project setup it needs, scoped credentials, network policy, work logs, live previews, and review context. Teams can also use network sandboxing and workspace usage visibility to control and review agent activity across the company.
As coding agents become a normal part of software teams, "where does the agent run?" becomes a security architecture question. For most companies, the answer should not be "wherever a developer happens to have a terminal open."