Google Agent引擎发布背后：AI代理实时管控的50毫秒生死线

Google Cloud 本周发布 Agent Compute Engine 并扩展代理治理能力，官方博客强调了可验证的代理身份和运行时逐调用策略执行的必要性。但社区讨论中，一个更尖锐的问题浮出水面：当代理拥有合法的大范围权限时，实时管控究竟该如何落地？

被“埋没”的核心：运行时策略执行

Google 的公告中，最关键的细节并非算力引擎本身，而是明确指出了对可验证代理身份和运行时逐调用策略执行的需求。这并非 Google 独有的缺口。据安全公司 Wiz 此前的云服务账户泄露研究，以及 Anthropic 模型卡中关于工具调用放大效应的披露，同类问题已在多个平台反复出现。

Reddit 讨论中提及一个反复出现于事件复盘的数字：从异常代理的首次未授权动作到第二次动作，窗口期不足 50 毫秒。这就是“爆炸半径窗口”——当人工被呼叫时，代理已经完成了 3 到 12 次下游工具调用，每一次都继承了同一套被泄露的凭证或配置错误的权限范围。

可验证代理身份（Verifiable Agent Identity）指的是代理在与下游服务交互时，能够以密码学可验证的方式证明自身身份及其被授予的权限范围，而非仅依赖静态凭证（如服务账户密钥）。它与传统身份认证的关键区别在于：静态凭证一旦泄露即被全盘冒用，而可验证身份通常绑定短时令牌、工作负载证明（如 SPIFFE/SPIRE 的 SVID）或硬件根信任，使每次调用都能被追溯和约束。对于代理场景，这一概念尤为重要，因为代理往往代表用户或上游系统行动，其权限可能跨越多个服务和租户。没有可验证身份，运行时策略引擎就无法可靠区分“合法的代理调用”与“冒用凭证的恶意进程”，逐调用执行也就失去判断依据。

运行时逐调用策略执行（Runtime Per-Call Policy Enforcement）是指在代理每一次发起工具或 API 调用的瞬间，由独立于代理代码的策略引擎对该调用进行实时评估：检查调用者身份、目标资源、参数内容和上下文，并在毫秒级内做出放行或拦截决策。它不同于部署前的静态 IAM 策略，也不同于事后审计日志，而是将管控点嵌入调用路径本身。其技术挑战在于低延迟（需在数十毫秒内完成评估）、策略表达力（需覆盖参数级和上下文条件）以及标准化（目前缺乏跨平台的策略描述格式）。

身份供给不等于管控：错位的安全假设

多数团队仍将此类问题视为身份供给问题：给代理分配服务账户、严格限定范围、定期轮换。但事故持续发生，因为执行缺口不在供给阶段，而在调用阶段——当代理上线并做出静态策略无法预见的决策时。

据 Reddit 帖子中的观察，这种错位源于一个根本假设：静态策略可以覆盖代理的所有行为。而现实中，编排型代理或被委托用户权限的代理，其合法访问范围在设计上就是宽泛的。供给时收紧权限，往往与业务需求直接冲突。

服务账户是云平台中供非人类工作负载使用的身份实体，通常绑定一组 IAM 权限并长期有效。传统上团队通过为代理分配专用服务账户、按最小权限原则收紧范围并定期轮换密钥来管控风险。但这一模式在代理场景下存在结构性缺陷：代理的行为是动态生成的，其调用序列无法在供给阶段完全枚举；编排型代理还需要代表下游用户行事，天然需要较宽泛的权限。结果是供给阶段的“最小权限”要么与业务冲突而被放宽，要么在运行中被代理的合法决策突破。这正是“身份供给”与“调用管控”错位的根源——前者约束的是“谁拥有什么权限”，后者需要约束的是“此刻这次调用是否应当发生”。

实践者如何应对：基础设施层、SDK层还是别处？

帖子向实践者提出了一个关键问题：对于设计上就拥有合法宽泛访问权限的代理（如编排代理、被委托用户权限的代理），实时逐调用执行究竟该在何处落地？是基础设施层、SDK 层，还是其他位置？

讨论中浮现出几种方向。基础设施层（如服务网格、API 网关）可以在网络边界拦截调用，但对代理内部决策逻辑缺乏感知；SDK 层能在代码中嵌入策略检查，却依赖开发者自觉且难以覆盖第三方工具；还有观点指向运行时策略引擎，独立于代理代码之外，对每次工具调用进行实时评估和拦截。

据 Wiz 研究和 Anthropic 披露交叉验证，工具调用放大效应是共同挑战：一个被攻破的代理能在极短时间内通过合法工具链造成连锁影响。这让“事中拦截”比“事前供给”更具现实紧迫性。

服务网格（Service Mesh，如 Istio、Linkerd）通过在应用旁挂载边车代理（sidecar）拦截服务间网络流量，可在 L4/L7 层实施 mTLS 认证、访问控制和流量策略。API 网关则在南北向流量入口集中执行认证、限流和路由策略。二者作为基础设施层管控手段的共同优势是部署成熟、与语言无关、难以被应用代码绕过；局限在于它们看到的是网络请求，而非代理的决策意图——对于代理内部生成的工具调用，网关只能依据目标地址和请求内容做粗粒度判断，无法感知“这次调用是否在代理的合法任务范围内”。因此基础设施层适合做第一道粗筛，但难以单独承担逐调用的语义级策略执行。

工具调用放大效应（Tool-Call Amplification）指代理在一次决策中可连续调用多个下游工具或 API，每一次调用都可能继承相同的凭证和权限，从而在极短时间内将单点失误或凭证泄露放大为跨系统的连锁影响。与人类操作相比，代理的调用速度以毫秒计，且调用链可自动展开，使传统依赖人工审批或事后告警的安全流程完全失效。这一效应是运行时逐调用管控需求的核心动因：必须在放大发生之前、在每一次调用路径上实施拦截，而非在链条末端补救。

多源视角下的共识与分歧

综合 Reddit 讨论、Wiz 研究及 Anthropic 披露，多方共识在于：运行时逐调用策略执行是当前代理安全的核心缺口。分歧则在于实施路径——基础设施层方案成熟但粒度粗，SDK 层方案灵活但覆盖不全，独立策略引擎理念上理想但性能开销和标准化仍是障碍。

一个未被充分讨论的单一来源观点来自 Reddit 帖子：50 毫秒的爆炸半径窗口意味着任何依赖人工响应的安全流程都来不及介入，必须将策略执行嵌入调用路径本身。这一数字虽未在其他来源中得到独立验证，但与工具调用放大的披露逻辑一致。

当前值得关注的信号

Google 将代理身份和运行时策略执行写入公告，标志着主流云厂商开始正视这一缺口。但对实践者而言，问题已不再是“是否需要运行时管控”，而是“在哪个层面实施才能兼顾安全与代理的合法宽泛权限”。在标准化方案出现之前，混合分层策略——基础设施层做粗粒度拦截、SDK 层做细粒度校验、独立引擎做实时评估——可能是更现实的过渡路径。