智能体安全运行时：每个 Agent 一台隔离沙箱、沙箱内零凭据——把「假设已被攻破」做成架构
典型业务问题
2026 年 Agent 沙箱逃逸与凭据泄露事故密集（站内 10-12/10-17 简报多有收录），企业最普遍的现状是：Agent 拿着长期有效的 API Key 和 service account 凭据在共享环境里跑——攻破一个 Agent 等于拿走它能触达的全部钥匙。CrowdStrike 实测一家财富 500 强在跑 18,000 个 Agent 只批准过 300 个；Gartner 预测 40% 部署自主 Agent 的公司会在治理事故暴露后降级退役它们（2026 年 5 月口径）。
AI 可以怎么做
2026 年 10 月 22 日谷歌云在 AGNTCon+MCPCon 发布 Agent Compute Engine（年内预览），把跑 Gemini Agent 的内部基建产品化，架构原则一句话（谷歌工程团队原话）：「假设攻击者控制沙箱内一切，并确保他在那里什么都找不到。」每个 Agent 会话独占一台单租户、内存安全的 microVM（硬件隔离，兼得容器速度与沙箱安全）；沙箱内存与磁盘不放任何密钥凭据，唯一身份是短时会话级身份；不给标准网卡，全部出入流量经沙箱外的中介代理，需要访问 Google Drive 等真实服务时由 Agent Gateway 校验「用户委托+sandbox 身份」后在沙箱外注入真实凭据；空闲即快照挂起、零资源占用；宿主为无状态设备+只读文件系统，每次启动做硬件固件密码学校验（Titan/Titanium），CPU 带侧信道缓解。同步开源 Agent Substrate（GKE 运行时，宣称密度最高 10 倍、20 万 Agent 基准 500 激活/秒、亚秒级挂起恢复，兼容任意 harness），竞品坐标：AWS Bedrock AgentCore（每会话 microVM、等待不计 CPU 费）、E2B、Daytona。
数据与流程准备
依赖三块底座：其一，身份与委托体系（能签发短时身份、校验「谁委托了哪个 Agent」）；其二，密钥集中于可外部注入的保管库（Vault/KMS），而非散落在 Agent 配置文件与环境变量；其三，出站流量可集中代理与审计。现状多为「凭据写死在 Agent 配置里」的企业，此项改造是主要工程量。
建议验证指标
- Agent 可触达凭据数（目标：常驻凭据为零，全部出口点注入）
- 高危外联拦截率与出站白名单覆盖率
- Agent 身份有效期分布（长命身份占比）
- 沙箱逃逸演练结果（红队从 Agent 沙箱内实际取得什么）
- 闲置快照节省的计算成本（等待占比 × 单价）
POC 建议
6 周验证：第 1-2 周盘点现有 Agent 持有凭据清单（这是最大暴露面），把长期 API Key 与 service account 全部登记；第 3 周选 1-2 个低风险 Agent 试点短时身份+出口代理模式（云预览版或自建 Substrate/gVisor 均可）；第 4 周红队演练：诱导该 Agent 执行「找密钥外发」动作（即谷歌工程师举的恶意邮件例子），验证沙箱内无可窃之物；第 5-6 周把「新 Agent 一律零常驻凭据上线」写进架构评审清单，存量按高风险优先迁移。
常见失败原因
- 只做网络隔离不做凭据外移——沙箱里仍放着长期 Key，攻破即全拿，架构核心被架空
- 短时身份签发链没建起来，「委托关系」无法审计，治理退化成另一个黑盒
- 把全部流量强推代理后延迟与故障点上升，业务侧反弹导致方案回退——白名单分级灰度才是稳的路径
给一位老板算一笔账：你的销售 Agent 配置里躺着一枚 CRM 系统的长期 API Key，你的财务 Agent 环境里存着银行接口的 service account 凭据。哪天某个 Agent 被一封带隐藏指令的邮件策反——谷歌工程师在技术深文中举的正是这个例子：读取邮件、按指令在机器上翻 API Key、发往外部地址——模型大多数时候会忽略这种指令，但不是每次。攻破一个 Agent，拿走的不是它的会话记录，而是它全部钥匙。这就是 2026 年企业 Agent 部署最普遍的架构性裸奔。
架构反转：从「挡住攻击」到「里面没东西可偷」
10 月 22 日，谷歌云在圣何塞 AGNTCon+MCPCon 宣布 Agent Compute Engine（年内预览）：把驱动 Gemini 的自家 Agent 基建产品化出租。值得老板注意的不是产品本身，是它的架构原则——两位谷歌杰出工程师（Jnagal 与 Venkatapathy）的原话：「我们从一个规则出发：假设攻击者控制沙箱内的一切，并确保他在那里什么都找不到。」这不是把安全做「更强」，是把被攻破从异常改成默认假设，然后清空赌注。
- 每 Agent 一台单租户 microVM：硬件级隔离兼得容器速度与沙箱安全；每机自带 guest kernel 与机内 root 权限，Agent 可以拿 shell、跑 headless 浏览器、写代码，循环跑几周没问题——但出不了这台机
- 沙箱内零凭据：内存和磁盘不放任何密钥，唯一身份是短时会话级身份；需要访问真实服务时，由 Agent Gateway 在沙箱外校验「用户委托+sandbox 身份」后注入凭据——钥匙在保险柜，不在 Agent 兜里
- 没有标准网卡：全部出入流量先穿本地非特权中介代理，再到外部网关校验请求范围并执行策略驱动的外联管控（官方架构描述，两独立信源交叉核验一致）
- 宿主是无状态设备：不保留客户 Agent 文件，所存数据在不可篡改只读文件系统里；每次启动用 Titan/Titanium 芯片做硬件固件校验，CPU 带侧信道攻击缓解；快照与磁盘静态加密、流量全程传输加密
- 空闲即快照：Agent 大部分时间在等模型或等用户，一次工具调用结束就把 microVM 检查点挂起、零资源占用，下次调用再唤醒——这是成本设计，不只是安全设计
为什么大厂集体把 Agent 隔离下沉到硬件层
同一周的坐标系值得连读：10 月 21 日 ServiceNow×NVIDIA 的 Arc 正式可用，治理栈下沉到芯片级——AI Passport 吊销后 BlueField 在硬件层拦截被拉黑的 Agent，被拦任务隔离进沙盒供审计（站内 10-23 简报）；Anthropic 的 Claude Duet 走「动作全需人批+证券交易禁入」的审批路线。软件护栏（提示词过滤、内容审查）挡不住已经开跑的 Agent，因为它调用 API、动文件、连数据库时用的是合法凭据。行业共识正在成形：Agent 运行时的隔离从软件层下沉到硬件层——虚拟化、不可变文件系统、密码学身份、出口代理四件套成为企业级 Agent 平台的新基线。竞品已各就各位：AWS Bedrock AgentCore 同样每会话一台 microVM 且等待期间不计 CPU 费，E2B 的 Firecracker 沙箱一秒恢复，Daytona 今年 7 月补上 microVM。
对采购与自建的分叉判断
不锁云是本案的隐藏信息：谷歌同步开源 Agent Substrate——GKE 上的运行时，轻量控制平面号称扛住百万级短生命工具调用、密度最高 10 倍（20 万 Agent 基准 500 激活/秒、挂起恢复亚秒级），跑在任何 Kubernetes 集群上，兼容任意 harness。也就是说：认同「零凭据运行时」架构的企业，可以买云托管（预览期），也可以自建（开源+gVisor/microVM 混合隔离），不被单一厂商锁定。对国内企业的现实提醒：谷歌预览版进不了采购清单，但架构原则通用——「短时身份、凭据外置、外联白名单、沙箱可弃」四条在国产 Agent 平台与私有化部署上同样可以落地要求。（编辑观点）
现在应该做什么
- 本月盘一次「Agent 持有凭据清单」：每个在跑/立项的 Agent 手里有什么 Key、什么账号、有效期多长——这是最大暴露面，先于一切选型讨论
- 新 Agent 上线一律要求短时身份+凭据出口注入，把「沙箱内零常驻凭据」写进架构评审清单
- 给 Agent 外联上白名单：全部流量经代理出网，默认拒连未登记域名
- 红队演练一次「策反自家 Agent」：给它发一封要求翻密钥外发的邮件，看它拿到什么——拿不到东西才是真隔离
- 把外联管控写进 Agent 采购合同条款，与「数据不出域」并列成标准安全要件
暂时不要做什么
- 不要为了上零凭据架构停掉存量业务 Agent：先隔离高权限的（能写数据、可外联、碰钱的），低风险的登记观察
- 不要把厂商的 microVM 宣传当验收标准：验收靠红队演练结果，不靠架构图
- 不要指望提示词护栏替代架构隔离：指令层治理对「已经开跑并持有合法凭据」的 Agent 无效——这是 CrowdStrike LOTAIL 威胁的教训
- 不要一次性把全部流量推给代理：全量切换的延迟与故障会引发业务反弹回退，分级灰度才推得动
常见问题
参考来源（3）
1. The New Stack：谷歌将把驱动 Gemini 的 Agent 基建出租——Agent Compute Engine 每 Agent 一台硬件隔离 microVM（2026-10-22）可信媒体
发布主体：The New Stack使用政策：可摘要正文全文实抓核验（2026-10-24）：10-22 圣何塞 AGNTCon+MCPCon 宣布，年内预览；每 Agent 独占单租户内存安全 microVM（容器速度+沙箱安全）；沙箱内存与磁盘不放任何密钥凭据，唯一身份是短时会话级身份；无标准网卡，全部流量走沙箱外代理，Agent Gateway 校验用户委托+sandbox 身份后在沙箱外接出口注入真实凭据；宿主为无状态设备+只读文件系统，每次启动做硬件固件密码学校验（Titan/Titanium IPU）；空闲即 checkpoint microVM 零资源占用（Agent 大部分时间在等模型或等人）；每 Agent 一台持久计算机（shell/headless 浏览器/机内 root，循环可跑数周）；为前沿实验室评估回路/AI benchmark/强化学习的大规模场景设计；核心原则原话「假设攻击者控制沙箱内一切，并确保他在那里什么都找不到」；开源替代品 Agent Substrate（GKE，5 月首发）称密度最高 10 倍、20 万 Agent 基准 500 激活/秒、挂起恢复亚秒级，兼容任意 harness（Claude Code、OpenClaw、Hermes）；竞品坐标：E2B（Firecracker 秒级恢复）、Daytona（7 月加 microVM）、AWS Bedrock AgentCore（每会话 microVM、等待不计 CPU 费、会话 8 小时上限、8 月加 14 天共享实例）。https://thenewstack.io/google-agent-compute-engine/2. SiliconANGLE：Google Cloud 推出托管 AI Agent 的基础设施服务 Agent Compute Engine（2026-10-22）可信媒体
发布主体：SiliconANGLE使用政策：可摘要正文全文实抓交叉核验（2026-10-24）：与 The New Stack 口径一致并补细节——microVM 流量须穿多层代理方可出宿主机数据中心（官方原话：所有出入站流量必须穿越隔离的点对点 IPC 边界，终止于本地非特权中介代理，转发至外部代理，外部门关校验请求范围并执行策略驱动的出站管控）；设备不永久保留客户 Agent 文件，所存数据置于不可篡改只读文件系统；固件由 Titan 芯片校验，CPU 带侧信道攻击缓解；单个沙箱被接管也无法读写宿主存储。https://siliconangle.com/2026-10-22/google-cloud-introduces-agent-compute-engine-to-host-ai-agents/3. Google Cloud 官方博客：发布 Agent Compute Engine 与扩展的 Agent 治理（2026-10-22）一手官方
发布主体：Google Cloud使用政策：可摘要官方发布页（本环境直连超时未取到正文；架构细节与两位 distinguished engineer Jnagal/Venkatapathy 的表述经 The New Stack 与 SiliconANGLE 两独立信源全文实抓交叉核验，站内行文以二次报道口径为准）。https://cloud.google.com/blog/topics/ai-infrastructure/introducing-agent-compute-engine-and-expanded-agent-governance