零信任 AI 智能体：通过意图判断而非语法校验

零信任智能体系列第 2 部分：运行时治理、意图门控与自适应异常修复

在第 1 部分中，我们为自主智能体建立了三种确定性控制手段：使用 Cloud KMS 进行签名数据库写入、使用 gVisor 进行用户空间内核隔离，以及由 CI 单元测试支撑的输入/输出网关。

这些控制手段有效，但它们有一个共同局限：它们只能捕获那些能够预先明确指定的情况。

SQL 解析器无法在语法有效的情况下区分出社会工程学操纵的退款与合法退款。正则表达式无法区分一根物理 USB 数据线与一个已开封的软件许可证。单轮测试套件无法捕获跨多轮耗尽整个智能体舰队的行为。

第 2 部分继续使用基于智能体开发套件（ADK）构建的同一客户支持与退货智能体，并将安全检查转移到平台层，在那里对意图进行推理并自适应调整行为。将检查转移到平台层也改变了责任归属。治理策略由平台或安全管理员定义和管理，独立于智能体开发者——因为平台在智能体代码之外强制执行这些策略。

在 Gemini 企业级智能体平台上部署，我们用托管运行时治理替代自托管容器基础设施和手动管理的正则表达式列表：Model Armor、语义治理策略，以及带闭环修复功能的智能体异常检测。

场景：同一退款智能体，现在运行在运行时

我们沿用了第 1 部分中的同一客户支持与退货智能体。它查询订单、计算补货费用，并从商户账本中支付退款。当客户发起退货请求时，智能体通过 verify_order 读取订单，并使用 calculate_restocking_fee 计算最终退款金额，该计算在 Agent Sandbox（平台为模型生成的代码提供的托管沙箱）中运行。如果退款通过校验，它调用 issue_refund 来提交支付，并使用智能体自己的 Cloud KMS 非对称密钥对请求签名，这与第 1 部分中的硬件支持身份相同。在生产环境中，智能体通常会通过模型上下文协议（MCP）或后端 API 暴露的工具来调用这些能力。为简化演示，我们将其直接实现为本地 Python 函数。

为使攻击场景具体可感，我们针对同一笔交易运行所有攻击：订单 #99281，总价 $149.00。包含两个行项目：一个 USB-C Pro 扩展坞和数据线（$29.00），以及一份年度 Workplace 用户许可证（$120.00）。这种实物与数字商品的拆分正是接下来两轮攻击的切入点。

下文所有代码、策略声明和交互式模拟器均可在开源配套演示中找到：zero-trust-agents-2。

从代码级检查转向托管运行时治理

零信任运行时假设每个独立请求都可能看起来有效但仍属于攻击的一部分。它不预先将每条规则硬编码，而是通过 Agent Gateway 强制执行三个托管控制手段——Agent Gateway 是运行时强制执行点，负责拦截并治理用户、智能体、其模型及其工具之间的交互。这些控制手段包括：

Model Armor：一个内联 AI 防火墙，在提示词注入、越狱攻击、恶意 URL 和敏感数据泄露方面对提示词和响应进行筛查。

语义治理策略：一个基于 LLM 的自然语言策略引擎，在工具调用运行之前，根据用户意图和业务规则评估每个拟议的工具调用。

智能体异常检测：由 LLM 驱动的智能体日志和遥测分析，标记跨会话的异常行为，例如跨多轮耗尽退款。

每个控制手段覆盖其他手段无法覆盖的范围。Model Armor 过滤载荷，策略引擎推理意图，异常检测则随时间观察行为。

1. 在边缘筛查每个提示词：Model Armor

在第 1 部分中，攻击者发送了一个暴力载荷：

我们通过正则表达式列表（JAILBREAK_SIGNALS = ["ignore previous instructions", ...]）捕获了它。在生产环境中，为每种混淆的越狱攻击维护正则表达式字典很快就会失效。

Model Armor 在智能体推理循环运行之前，在入口边界对载荷进行筛查，检测提示词注入、越狱攻击和恶意 URL。在平台上，Agent Gateway 直接在请求路径中应用你的 Model Armor 模板。以下是它包装的直接 API 调用：

from google.api_core.client_options import ClientOptions
from google.cloud import modelarmor_v1

# Model Armor 模板是区域性的，因此将客户端指向区域端点
client = modelarmor_v1.ModelArmorClient(
    transport="rest",
    client_options=ClientOptions(
        api_endpoint="modelarmor.us-central1.rep.googleapis.com"
    ),
)

def screen_ingress(user_prompt: str) -> dict:
    request = modelarmor_v1.SanitizeUserPromptRequest(
        name="projects/agent-security-fleet-prod/locations/us-central1/templates/enterprise-strict",
        user_prompt_data=modelarmor_v1.DataItem(text=user_prompt),
    )
    response = client.sanitize_user_prompt(request=request)
    result = response.sanitization_result
    if result.filter_match_state == modelarmor_v1.FilterMatchState.MATCH_FOUND:
        # 在智能体模型运行之前就在边界处丢弃
        return {"action": "BLOCK", "status": 403}
    return {"action": "ALLOW"}

需要明确的是，这是你不必编写的代码。Agent Gateway 为你强制执行此操作。当过滤器匹配时，请求在边缘处被丢弃并返回 403。智能体的模型永远不会被调用，因此不会消耗 token，上下文窗口保持干净。

在出口处，Model Armor 对传出响应运行敏感数据保护，在响应离开网关之前隐藏信用卡号、Stripe 密钥和员工 ID：

# 原始智能体输出：
#   "Refunded to card 4532-8921-3342-9901 with secret sk_live_981240912."
# Model Armor 出口筛查后：
#   "Refunded to card [REDACTED_CREDIT_CARD] with secret [REDACTED_STRIPE_KEY]."

2. 判断意图而非语法：语义治理策略

攻击者放弃注入，改用礼貌的、语法干净的社会工程学攻击：

每个确定性门控都通过了。Model Armor 看到干净的语言并放行。请求的 $120.00 在 $149.00 的订单总额以内。SQL 参数类型正确。没有越狱攻击的迹象。然而，公司政策规定，超过 $30 的数字软件许可证未经经理批准不可退款。我们可以尝试编写确定性策略或正则表达式列表来覆盖每一种软件许可证和产品 SKU，但在企业级目录中这是不可行的。因为提示词以及可能订单本身指的是"Google Workplace 用户许可证"而不是明确说"软件"，关键词匹配和正则过滤器都无法捕获它，而 SQL 解析器没有办法知道"Google Workplace 用户许可证"是数字软件——这就是我们依赖语义治理策略的原因。

语义治理策略在工具执行前放置一个自然语言策略引擎。当模型拟议一个工具调用时，引擎根据用户提示词、对话历史和你的策略评估该工具及拟议的参数，然后返回裁决。规则以纯文本约束的形式编写，因此业务负责人可以阅读和修改它们：

# policies/refund-policy-category.yaml
name: refund-policy-category
target_tools: [issue_refund]
constraints: |
  已开封的数字商品、软件许可证或超过 30 美元的清仓商品的退款必须拒绝，
  并转交给人工经理处理。
  最高 149 美元的实物硬件配件退款允许批准。
enforcement: BLOCK

当模型拟议调用 issue_refund(amount=120.00, item="Workplace User License") 时，引擎拒绝它。你可以在语义治理的 Cloud Logging 事件流中看到这一过程：

{
  "evaluations": [
    {
      "actionName": "issue_refund",
      "rationale": "该工具试图为'Workplace User License'退款 $120.00，这是一种数字软件产品。超过 $30 的数字软件退款需要经理授权。",
      "toolName": "order_processing",
      "verdict": "DENY"
    }
  ],
  "timestamp": "2026-09-03T15:52:21.447123Z",
  "token_usage": 2576,
  "token_usage_breakdown": {
    "input": 2526,
    "output": 50,
    "thinking": 0,
    "total": 2576
  },
  "verdict": "DENY"
}

工具执行在运行之前就被阻止了。Cloud KMS 永远不会被调用，账本毫发无损，智能体向用户解释结果："超过 $30 的数字软件许可证退货需要经理批准。"语义治理的应用与智能体访问工具的方式无关：无论是通过智能体内部的代码直接调用，还是通过 API 端点或 MCP Server 远程调用。

3. 捕获多轮漏洞利用：智能体异常检测

你可以将语义治理配置为不披露拒绝原因。但假设你没有这样做，或者该策略是公开的。攻击者会试探边界，并了解到两点：单笔订单总金额低于 $30.00 的退款无需经理审批即可进行。于是他们将攻击拆分成多轮对话，每笔请求都很小且单独来看都是合法的：

Turn 1:  refund $20  ->  policy: ALLOW (software, under $30)  ->  KMS sign  ->  ledger:  $20.00
Turn 2:  refund $20  ->  policy: ALLOW (software, under $30)  ->  KMS sign  ->  ledger:  $40.00
...
Turn 7:  refund $20  ->  policy: ALLOW (software, under $30)  ->  KMS sign  ->  ledger: $140.00
Turn 8:  refund $20  ->  policy: ALLOW (software, under $30)  ->  KMS sign  ->  ledger: $160.00

每一轮都通过了 Model Armor、通过单轮策略引擎，并获得了有效的 Cloud KMS 签名。每一笔 $20.00 退款单独来看都是允许的，因为它是软件且低于 $30.00 限制。只有在聚合层面问题才会显现：攻击者通过 $20.00 退款共提取了 $160.00，超过了其初始 $149.00 的订单金额。单轮护栏在隔离环境中评估每个请求，因此它们无法看到累积流失或多轮速率。

Agent Anomaly Detection 监控整个 fleet 的会话遥测数据，使用统计模型和 LLM 分析来标记异常行为。它与 Agent Threat Detection 协同工作，并在 Gemini Enterprise Agent Platform 的 Audit 标签页中的 Agent Anomaly Detection 体验以及由 Security Command Center 驱动的 Agent Security 仪表板中呈现结果。配套仓库提供了一个本地替代实现，以便你了解它所依赖的信号：工具调用速率、对同一实体的重复写入，以及累积参数值。

# demo/aad_engine.py  (Agent Anomaly Detection 的本地替代实现)
def evaluate_session_anomalies(session_history: list, order_baseline: float) -> list[dict]:
    findings = []
    refunds = [t for t in session_history
               if t["tool"] == "issue_refund" and t["status"] == "APPROVED"]
    cumulative = sum(t["args"]["amount"] for t in refunds)

# 高频相同工具调用
    if len(refunds) >= 3:
        findings.append({"detector": "repeated_tool_call", "confidence": 0.95})
    # 累积参数值超过订单基线
    if cumulative > order_baseline:
        findings.append({"detector": "cumulative_limit_exceeded", "confidence": 0.80})
    # 针对同一订单 id 的重复写入变更
    if len({t["args"]["order_id"] for t in refunds}) == 1 and len(refunds) >= 2:
        findings.append({"detector": "single_entity_write_velocity", "confidence": 0.80})

return findings

这些检测器针对整体模式触发：重复工具调用、对单一实体的写入速率，以及累计账本流失。异常会在 Agent Anomaly Detection 中被标记，同时也会作为 AI 威胁发现呈现到 Security Command Center：

{
  "vulnerabilityId": "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6",
  "findingClass": "THREAT",
  "findingType": "AGENT_SESSION_ANOMALY",
  "severity": "CRITICAL",
  "csccResourceName": "//aiplatform.googleapis.com/projects/../locations/us-central1/reasoningEngines/..",
  "agent": { "id": "3757043326738497536", "displayName": "support-refund-agent" },
  "agentSessions": [ { "sessionId": "session-abc" } ],
  "agentAnomaly": {
    "detectorReferences": [
      {
        "detectorId": "tool_misuse",
        "displayName": "ASI02: Tool Misuse",
        "severity": "CRITICAL",
        "recommendation": "Restrict the tool to a smaller allowlist and add a confirmation step before execution."
      }
    ]
  },
  "structuredProperties": {
    "contextUris": { "relatedFindingUri": { "displayName": "View agents anomaly session details" } }
  }
}

上述检测器名称、置信度值和发现结构均为示例说明。

仅靠检测仍然会让漏洞持续存在，直到攻击向量被消除。在传统架构中，关闭这个漏洞需要修改应用代码、重新构建镜像并重新部署 agent fleet。由于语义治理策略在运行时动态评估，你可以在不修改或重新部署 agent 代码的情况下关闭这个循环：管理员只需打开语义治理策略体验，审查被标记的追踪记录，并编写一个覆盖多轮模式的新自然语言约束。在自动化环境中，这也可以通过 API 以编程方式处理，如配套仓库中所示：

# demo/remediation_loop.py (将 Security Command Center 发现连接到新策略)
def remediate(finding: dict, sgp_client) -> None:
   # 匹配 SCC 发现负载中的 findingClass 和 findingType
   if finding.get("findingType") != "AGENT_SESSION_ANOMALY":
       return
   agent_id = finding.get("agent", {}).get("id", "support-refund-agent")
   constraint = (
       "Deny any issue_refund call when the conversation history already "
       "contains an approved refund for the same order_id in this session. "
       "Route the request to a human manager instead."
   )
   sgp_client.create_policy(
       name="refund-policy-single-order-limit",
       target_agent=agent_id,
       target_tools=["issue_refund"],
       constraint=constraint,
       enforcement="BLOCK",
   )
   # 新策略在下次工具调用时由 Agent Gateway 评估，
   # 无需 agent 重新部署或重启。

当攻击者尝试对同一订单进行后续退款时，策略引擎现在会拒绝该操作，如以下闭环修复工作流所示：

纵深防御：构建时 + 运行时

从构建时控制到运行时治理

运行时控制与第一部分中的构建时控制一一对应：

配套仓库可本地运行，无外部依赖，并包含一个交互式仪表板：

# Clone the repository
git clone https://github.com/GoogleCloudPlatform/generative-ai.git
cd generative-ai/agents/adk/zero-trust-agents-2/

# 1. Run the interactive four-act CLI demo
./demo/run_part2_demo.sh

# 2. Open the web dashboard
python3 -m http.server 8000

# 3. Run the deterministic unit test suite
python3 -m unittest demo/test_runtime_governance.py

运行时治理将安全边界移至意图和行为实际显现的地方。每一个提示在模型运行前都会在边缘被筛查，每一个提议的工具调用在任何状态变更前都会根据意图和业务规则被评判，每一次写入仍使用硬件支持的 Cloud KMS 密钥签名，而单轮检查无法看到的多轮攻击会被 fleet 遥测捕获，并在运行时生效的策略下被关闭。

探索参考实现：

阅读第一部分：使用 Google 的 Agent Development Kit 构建零信任 AI 智能体。

克隆仓库：在 GitHub 上检出开源的 zero-trust-agents-2 代码库。

运行 CLI 演示：执行 ./demo/run_part2_demo.sh 以在本地逐步完成四种攻击。

探索仪表板：运行 python3 -m http.server 8000 与浏览器仪表板交互。

在 Gemini Enterprise Agent Platform 上部署：查阅 Agent Platform 治理文档以启用 Model Armor、语义治理策略和 Agent Anomaly Detection。