Google ADK 零信任代理怎么落地：签名写入、gVisor 沙箱与语义网关的边界

把 Google ADK 代理接到订单库、内部 API 或动态脚本后，风险就不再只是“回答错了一句话”。它可能写入退款记录、读取不该暴露的数据，甚至把运行时环境当成工具输出。Google Developers Blog 最近给出的零信任思路很实用：把代理产生的状态变化当成一条数据流，分别在身份、运行时和业务语义三个位置设硬门槛。

提示词只能表达意图，不能替代权限系统。真正的生产边界应落在写入签名、隔离运行时和确定性校验上，并且每一层都要能单独验收。

先按数据流拆开代理的真实风险

一个客服退款代理通常会经历四步：读取用户请求，查询订单，计算扣款或退款金额，最后把结果写入账本。模型可以负责规划工具调用，但“退款金额是否超过订单上限”“这次写入由哪个代理发起”都不应只靠上下文里的规则。

最容易漏掉的是共享连接池。多个代理使用同一组数据库凭据时，日志只能说明“这个账号写过一行”，却不能证明是哪一个代理、哪一份输入促成了变更。出现争议或密钥泄露后，追责链就断了。

第一层：让每次写入都有可核对的代理身份

写入签名的目标不是给模型“加密”，而是给状态变化补一条可以复查的证据。每个代理使用独立服务账号，请求提交前对规范化后的业务载荷签名，数据库侧或写入服务验证签名后才落库。

载荷至少要包含订单编号、动作类型、金额、请求标识和策略版本。字段顺序和编码必须稳定，否则同一业务内容在签名端与验签端会得到不同摘要。生产环境不要把私钥放在容器文件系统里，可使用 Cloud KMS 一类的硬件保护密钥服务完成签名。

payload = {
    "order_id": "ord_2026_0817",
    "action": "refund",
    "amount": "149.00",
    "policy_version": "refund-v3"
}

# 伪代码：签名服务返回签名，写入服务负责验签
signature = signer.sign(canonical_json(payload))
ledger.commit(payload, signature, agent_id)

验收时不要只看接口返回 200。应在账本里抽查签名、代理 ID、策略版本和原始请求 ID，并故意改动金额后重放一次，确认验签或业务校验拒绝这笔写入。

第二层：把动态计算放进 gVisor 隔离边界

代理为了计算折扣、解析文件或整理日志，可能生成短脚本。即使脚本来自“看起来正常”的请求，也不能默认它只会读临时目录。标准容器仍与宿主机共享 Linux 内核，错误的能力配置或内核漏洞可能扩大影响面。

gVisor 通过用户态内核提供额外隔离层。落地时把任务目录挂成只读或临时目录，明确禁止外网访问，设置 CPU、内存和执行时长上限，并让任务以低权限身份运行。隔离层不是万能的：宿主机、镜像供应链和调度权限仍要按常规方式加固。

验证可以从三条失败路径开始：尝试访问宿主机文件，尝试连接外部地址，尝试超过资源上限。三者都应得到明确拒绝或受控终止，并且在审计日志中留下任务 ID、代理 ID、策略版本和结束原因。

第三层：用确定性语义网关拦住越权工具调用

退款上限、个人信息脱敏和工具参数范围属于业务规则，适合放在模型前后都能执行的语义网关里。网关不判断模型“想表达什么”，而是检查结构化字段和可观察的工具调用：金额是否超过订单总额，目标表是否在允许集合，输出是否包含密钥格式或银行卡号。

输入侧可以拒绝明显的越权请求，工具侧检查动作、资源和参数，输出侧做敏感信息过滤。规则要有版本号，并进入自动化回归：同一组攻击样本在模型升级、提示词调整和工具新增后都重新执行。

decision = gateway.check({
    "agent_id": agent_id,
    "tool": "refund_ledger",
    "order_total": "149.00",
    "requested_amount": "10000.00"
})

if decision.action != "ALLOW":
    return {"status": "blocked", "reason": decision.reason}

这里的关键是“确定性”。如果网关本身又把判断交给另一个模型，边界就重新变成软约束。模型可以提出方案，但最终放行应由可测试的代码、策略和权限完成。

三层防线怎样组合，才不会留下空档

签名、沙箱和语义网关保护的是三个不同问题。签名不能阻止已获授权的代理写入错误金额；沙箱不能判断退款是否符合业务政策；语义网关也不能证明一次写入确实来自指定代理。建议按下面的顺序联调：

1. 先用固定样例验证网关拒绝越权参数和敏感输出。
2. 再把动态计算切到 gVisor，验证文件、网络和资源限制。
3. 最后打开写入签名，核对正常写入、篡改载荷和重放请求三类结果。

如果只能先做一件事，优先保护真实状态变化：先收紧数据库写入权限并记录代理身份，再逐步把动态计算和语义校验补齐。不要因为有了签名就给代理更大的数据库权限，也不要因为用了沙箱就允许工具直接提交账本。

常见问题

系统提示词写了退款上限，还需要语义网关吗？

需要。提示词可能被输入诱导，也可能随着模型和工具变化而失效；金额上限、字段范围和敏感信息检查应由模型外的确定性规则执行。

gVisor 能替代容器安全和主机加固吗？

不能。它增加了运行时隔离层，但镜像来源、宿主机补丁、调度权限、密钥管理和日志审计仍要单独治理。

为什么每个代理都要有独立身份？

共享账号只能证明“某个连接写过数据”，无法把一次变更绑定到具体代理。独立身份配合签名，才能支持追责、撤销和按代理收紧权限。

如何判断这套架构已经可以上线？

至少要有三组可重复的验收记录：篡改写入被拒、隔离任务越界被阻断、超出业务规则的工具调用被拦截；同时保留代理 ID、请求 ID、策略版本和失败原因。

最后的落地清单

Google ADK 的零信任实践并不是给代理再加一个“安全提示词”，而是把权限和证据搬到基础设施层。先画清从用户请求到数据库提交的数据流，再逐层确定身份、运行时和业务规则，最后用攻击样例做反向验收。这样即使模型判断出错，错误也会在真正改变状态之前被限制住。