Gemini Model Armor Agent Gateway 内容安全正式 GA：每个路由团队需要配置的事项

当 Google 于 2026 年 6 月将 Agent Gateway 升至 GA 时，同步正式发布了一项改变所有通过 Gemini Enterprise Agent Platform 路由流量团队安全态势的能力：Agent Gateway 上的 Model Armor 现已 GA。根据 6 月 24 日的发布说明，operator 可以在 gateway 层对所有 agent 提示词和响应执行内容安全策略——无需修改任何 agent 代码。

对于正在评估 Gemini Enterprise Agent Platform 作为企业 agent 运行底座的团队而言，这意味着内容合规边界的执行点从单个 agent 逻辑层上移到了基础设施层。以前需要在每个 agent 里手写的过滤逻辑，现在统一由 gateway 承接。

Gemini Model Armor Agent Gateway 内容安全的实际作用

Model Armor 是 Google Cloud 的内容扫描服务：它根据可配置的模板评估提示词和响应，标记或拦截提示注入、越狱尝试、PII 泄露、仇恨言论等有害内容类别。此次 GA 的变化在于，扫描现在在 Agent Gateway 层内联运行——而非在 agent 内部，也不是异步审计日志步骤。

在架构上，Model Armor 并非 Agent Gateway 的组成部分，而是一个独立的 Google Cloud 安全服务，通过 API 与 Agent Gateway 集成。Gateway 拦截流量，将 payload 发送给 Model Armor 扫描，再根据扫描结果决定放行、拦截或脱敏。这种分层设计意味着 Model Armor 的模板可以独立于 gateway 配置进行更新，也可以跨多个 gateway 复用。

该集成拦截两种不同的流量方向：

客户端到 Agent（入口流量）： 来自终端用户或调用应用的每个请求在到达 agent 之前都经过 Model Armor。如果模板发出 BLOCK 判决，客户端收到错误，请求永远不会到达 agent runtime。出口响应在到达客户端前同样会被拦截。

Agent 到任意目标（出口流量）： 当 agent 调用外部 LLM、MCP server、第三方 AI agent（通过 A2A）或任何遵循 OpenAI 格式的服务时，Model Armor 会拦截出口流量。BLOCK 判决会在数据离开 agent 边界前终止连接。

关键的架构要点：同一个模板可以同时管控两个方向，也可以对入口和出口分别应用不同的模板。如果组织的 PII 策略对用户侧响应和内部模型间调用有不同要求，这种灵活性至关重要。

为何对路由 Agent 工作负载的团队如此重要

在此次 GA 之前，operator 团队面临两难选择：在每个 agent 内部实现内容过滤（脆弱、跨 agent 重复、容易被 LLM 幻觉绕过），或依赖事后日志分析。这两种方式都无法规模化。

Agent Gateway 上的 Model Armor 通过集中式执行点解决了这一问题：无论每个 agent 如何构建，一组模板管控 gateway 背后所有 agent 的流量。具体来说：

• 无需修改 agent 代码。 唯一的配置步骤是向 roles/modelarmor.calloutUser 授予 IAM 权限，并在 gateway 配置中引用模板。
• 发现结果显示在 Security Command Center 中。 策略违规被记录并在 Model Armor 控制台可见，完整集成到 Security Command Center findings——意味着可以直接接入现有 SIEM 管道。
• 实时 streaming 支持。 Model Armor 通过 streamQuery 方法（用于 ADK 构建的 agent）支持 streaming 模式下的无限 token，解决了早期内容扫描方案在长对话中遇到的 token 上限问题。

部署方式：配置模式

配置遵循三步模式，任何 operator 都可以将其脚本化为 IaC：

1. 启用 Model Armor API，在将托管模板的项目中启用。
2. 创建模板，在与 Agent Gateway 相同的区域中，为每个安全类别（提示注入、PII、仇恨言论等）指定阈值。
3. 授予 IAM 角色，应用于 agent runtime 的服务账户：
   • 在 agent 项目中授予 roles/modelarmor.calloutUser
   • 在模板项目中授予 roles/modelarmor.user

区域对齐约束是严格的：Model Armor 和 Agent Gateway 必须在同一 Google Cloud 区域。不支持跨区域调用。如果全球部署，需要为每个区域规划一套模板。

对于希望在执行前先观察的团队，有仅记录模式：将模板配置为仅检查和记录违规，而不发出 BLOCK 判决。这与语义治理策略中的 Dry Run 模式配合使用效果很好——可以在执行前同时观察意图拦截层和内容扫描层的行为，降低误伤生产流量的风险。

两层治理栈

Model Armor GA 完成了 Gemini Enterprise Agent Platform 上的两层治理架构：

这两层互为补充，而非冗余。语义治理策略捕获语义上与用户请求不对齐的工具调用。Model Armor 无论语义意图如何，都能捕获内容策略违规。通过语义治理策略意图检查的提示词仍可能携带 Model Armor 应该捕获的 PII 泄露风险——反之亦然。

对于运营多 provider 路由方案的团队，这个架构在 gateway 层有对应逻辑：路由规则处理哪个 provider 处理请求；内容策略处理哪些内容可以在任一方向越过边界。生产级 operator 栈两者都需要。

需要提前规划的当前限制

理解这些限制对于规划部署架构至关重要。在大多数企业环境中，agent 的多样性和全球分布会让这些边界条件变得显著：

1. Streaming 扫描要求使用 Agent Development Kit（ADK）构建的 agent。非 ADK agent 的 streaming 工作负载目前无法使用内联 Model Armor 扫描。
2. 出口保护仅覆盖 MCP server、OpenAI 格式服务和 A2A 流量。对任意 HTTP 端点的出口不受保护。
3. 区域对齐是硬性要求。 Model Armor 模板必须与 gateway 在同一区域。多区域部署需要每区域独立管理模板。
4. 跨项目配额。 如果 Model Armor 模板与 Agent Gateway 不在同一项目中，两个项目都需要足够的 Model Armor API 配额。这会影响将安全工具集中在共享项目中的团队。

下一步值得关注的事项

随着 Agent Gateway 和 Model Armor 均已 GA，Gemini Enterprise Agent Platform 上的治理栈已具备生产就绪能力。剩余的 Preview 项目——语义治理策略——是下一个值得关注 GA 升级的功能。一旦落地，完整的三层栈（路由 + 内容扫描 + 意图拦截）将全部正式可用并受 SLA 保障，使 Gemini Enterprise Agent Platform 成为此前需要自建合规基础设施的企业工作负载的可行选择。

对于评估多 provider 路由策略的团队，现实问题变成了：哪些 provider 提供了可比的 gateway 层内容策略执行能力，以及需要什么样的运营复杂度？Model Armor 的无代码修改、模板驱动方式为"内置"企业 AI 治理应该是什么样子设定了高基线。对于混合使用多个 AI provider 的团队，这套架构的设计思路——集中模板管理、IAM 权限隔离、双向流量拦截、SIEM 集成——在 enterprise AI 基础设施中正变得越来越标准。