7 种生产环境 AI 代理沙箱隔离方案

在笔记本上直接运行一个自主编程或运维 Agent，最初几分钟感觉像获得了超能力。它会读取本地仓库、在终端运行 bash 命令，还会在你去倒水的时候修复一个失败的测试。

然后现实就来了。一个凭空编造的 shell 命令删掉了本地文件夹，一个依赖脚本让机器卡死，或者藏在 GitHub Issue 里的间接提示注入悄悄读取了你的 ~/.ssh 密钥和云凭证。而且简单地把 Agent 用标准的 docker run 容器包装起来并不能解决问题：标准容器共享宿主机的操作系统内核，继承你传入的 API 密钥，也无法阻止被欺骗的进程外泄数据。

如果你准备把自主 Agent 从笔记本搬到生产云环境，以下是 7 种加固 Agent 沙箱的实用方法：

1. 使用真正的内核隔离（gVisor 或 microVM），而非标准 Docker

标准 Docker 容器只是在表面隔离进程，但每个容器都共享底层宿主机的操作系统内核。如果 Agent 运行了不受信任的代码并触发内核漏洞，它就能突破到宿主机上。

在生产环境中，可以根据工作负载在两种更强的隔离方案中选择：

用户态内核沙箱（gVisor）：被 Cloud Run 和 GKE Sandbox 使用。gVisor 像一个安全检查站代理，运行在容器和宿主机操作系统之间，在任何文件和网络请求触及真实硬件之前对其进行审查。它在毫秒级启动，与普通容器镜像兼容，不过对于创建数千个小文件的任务（如 npm install 或大型 git checkout），运行会稍慢一些，因为代理需要检查每一个文件操作。

轻量级 microVM（Firecracker / KVM）：microVM 不通过代理审查请求，而是利用硬件虚拟化为每个 Agent 单独启动一个微型 Linux 内核，启动时间约 125 毫秒。当你的 Agent 需要完整的 sudo/root 权限或运行重型构建时，选择 microVM（或 Compute Engine Confidential VM）。如果你只是需要一个托管沙箱来运行模型生成的 Python 或 bash 脚本，且不想管理服务器，可以使用 Gemini Enterprise Code Execution Sandbox。

2. 将原始 API 密钥和密钥放在沙箱外部

一个常见错误是从密钥管理器获取一个临时的 10 分钟令牌，然后作为环境变量（process.env）传入 Agent 容器。对一个被提示注入的 Agent 来说，10 分钟就是永恒——一条 curl 命令可以在 200 毫秒内窃取并发送到外部服务器。永远不要把真实凭证放在容器内。将密钥安全存储在 Google Cloud Secret Manager 中，并通过 Apigee AI Gateway 之类的外部网关代理路由 Agent 的出站 API 调用。网关通过 IAM Workload Identity 对 Agent 进行认证，仅当 Agent 调用经批准的目标 URL 时才在出站时附加真实 API 密钥。

3. 在每个步骤都锁定出站网络访问

最近对云端编程 Agent 的安全审计发现了两个常见盲点：

安装脚本泄露：许多平台在 Agent 推理时会阻断互联网访问，但在初始的 npm install 或 pip install 安装步骤期间却保持互联网完全开放，允许仓库中的恶意包脚本在 Agent 开始工作之前就窃取数据。

仅限 bash 的陷阱：对 bash 终端工具进行沙箱化，却让文件读取工具、浏览器工具或 MCP 服务器在宿主机上无限制运行。在整个生命周期内默认阻断出站互联网访问（VPC Service Controls 和出口防火墙规则）。从私有的、预扫描过的缓存（Artifact Registry）拉取代码包，而不是从开放的互联网拉取，且只允许沙箱与明确批准的域名列表通信。

4. 跨轮次跟踪累积操作，而非仅关注单次工具调用

执行前钩子（如 Antigravity PreToolUse 钩子和 ADK 2.0 工具回调）对于逐条检查命令必不可少，比如阻止 rm -rf 或强制退款工具的 $50 限制。但单步规则没有记忆。正如 Google Cloud 工程团队最近演示的那样，一个被欺骗的 Agent 只需在循环中调用六次 issue_refund($20) 就能绕过 $50 限制，耗掉 $120。将单步参数检查与会话级预算和网关层面的异常检测（Model Armor）配对，这样你的系统就能跟踪整个对话过程中的总体影响，并在行为偏离时停止循环。

5. 在隔离的工作空间中运行文件编辑，并保护 CI/测试文件

如果编程 Agent 能够编辑自己的单元测试或 CI/CD 流水线文件（.github/workflows、cloudbuild.yaml、.git/hooks），它可能只是通过删除测试断言就让一个失败的测试「通过」，或者在构建配置中植入一条命令，在人工审核 Pull Request 时跑到沙箱外部运行。给 Agent 一个隔离的工作空间副本（如 Google Antigravity 中的隔离 git worktree），将测试套件和 CI 配置文件夹挂载为只读，并在 Agent 试图修改构建流水线或安全规则时自动阻断任何 Pull Request。

6. 避免在为 LLM 等待时为空闲算力付费

AI Agent 的算力使用模式与普通 Web 服务器截然不同。在一次 10 分钟的调试会话中，沙箱可能只在运行测试的 2 秒内使用 100% CPU，然后在 70% 到 85% 的时间内什么都不做，等着 LLM 逐 token 推流回来或等待人工批准（Upstash 2026 Sandbox Benchmark）。如果你在标准的 24/7 虚拟机上运行 Agent 沙箱，空闲 CPU 和内存会让你多付 5 倍费用。使用 Cloud Run 等支持按实际 CPU 占用计费的无服务器运行时——你只为命令实际运行的那几秒 CPU 付费，并在外部的 Gemini Enterprise Agent Platform Sessions 中保存会话进度，这样空闲的沙箱可以在轮次之间关闭。

7. 将审计日志实时发送到沙箱外部

如果你把执行日志存在 Agent 有终端访问权限的同一容器中，崩溃的容器或恶意命令可以在你看到日志之前就把它们擦掉。在 Agent 运行期间直接把遥测数据从外部宿主机流式传输到 Cloud Trace 和 Cloud Audit Logs。对于每一轮，记录四件简单的事情（放在同一个 run ID 下）：1）Agent 要求做什么，2）你的安全规则是放行还是阻止，3）实际访问了哪些文件或网络 URL，4）确认任务完成时临时容器及其权限已被清理干净。

我们不应该让概率性的 Agent 在我们的笔记本或共享内核的容器中不受隔离地运行。用 gVisor 或 microVM 隔离内核，把真实 API 密钥放在容器外，锁定安装脚本的互联网访问，并在整个多轮循环中强制执行预算限制。

你目前是如何在生产环境中隔离 AI Agent 的？gVisor、microVM，还是外部网关代理？欢迎在评论区讨论！