很多 Agent 系统现在已经能改数据库 改CRM 发退款 写工单 更新配置但真正落到生产以后一个很难回答的问题是数据库里这一行 到底是谁改的如果所有 Agent 都通过同一个连接池、同一个 Service Account 写入日志里最多只能看到applicationagent-platform看不到哪个Agent 哪个Run 代表谁 为什么写 写入时参数是什么Google 最近公开的 ADK 零信任示例里把“每次状态变更都由具体 Agent 签名”作为第一层硬边界生产环境可以给 Agent 分配独立 Workload Identity并通过 Cloud KMS / HSM 保存非对称私钥Agent 对写入 Payload 做确定性序列化和摘要再请求 KMS 签名数据库入口验证通过后才允许提交。真正值得借鉴的不是某个 Cloud 产品而是状态变更要从“有权限就能写”升级成“身份、内容和授权都能被证明”。第一层先定义“被签名的是什么”危险做法只签 amount149这不够。真正应该把完整业务动作纳入 Signature{agent_id:refund-agent,run_id:run-918,subject_id:user-82,purpose:customer-refund,order_id:order-17,amount:149.00,currency:USD,idempotency_key:refund-order-17-v1,expires_at:2026-08-27T03:10:00Z}如果只签金额不签订单号签名可能被重放到另一个订单如果不签expires_at旧签名可能长期有效如果不签idempotency_key重复执行更难识别Payload必须CanonicalizeJSON{a:1,b:2}和{b:2,a:1}逻辑相同但字节不同。如果签名前没有统一序列化验证端很容易失败。可以定义publicinterfaceCanonicalPayloadEncoder{byte[]encode(Objectpayload);}规则至少包括字段排序 数字格式统一 时间统一UTC Unicode Normalize 禁止浮点隐式精度变化金额最好不要直接签149.0 149.00而是转成minor units 14900我会签Minor UnitspublicrecordRefundAction(StringagentId,StringrunId,StringorderId,longamountMinor,Stringcurrency,StringidempotencyKey,InstantexpiresAt){}这样149.00 USD稳定表示成14900不会出现浮点序列化问题。第二层Agent不能持有私钥最差实现AGENT_PRIVATE_KEY放在.env Kubernetes Secret Container File模型如果获得文件读取或环境变量访问能力私钥就可能泄漏。更好的Agent只有Sign权限 没有Export权限私钥永远留在KMS / HSMRuntime 只提交摘要。签名请求也需要授权不能让任何 Workload 都能调用refund-agent-keyKMS Policy只有 refund-agent Workload Identity 允许 sign也就是说Agent Identity → Dedicated Signing Key而不是所有 Agent 共用一把 Key。为什么每个Agent独立Key有价值如果research-agent拿不到refund-agent-key即使它设法调用数据库接口也无法生成合法退款签名。这形成Capability Separation比 Prompt 里写“研究Agent禁止退款”强很多。第三层验证必须发生在真正的写边界签名检查放在 Agent Tool 内部还不够。例如Agent → refund_tool → verify → DB如果另一个服务可以直接连 DB绕过所以真正验证位置应该尽量靠近State Mutation Boundary例如Database Ingress Service Write API Stored Procedure Event Consumer一个Write GatewayAgent ↓ Signed Action ↓ Write Gateway ├─ Signature Verify ├─ Expiry ├─ Idempotency ├─ Policy ├─ Resource Ownership └─ Audit ↓ Database数据库不直接暴露给 Agent。第四层签名不能替代业务Policy合法签名只能证明这个Agent确实发了这个请求不能证明这个请求业务上合理例如 Refund Agent 合法签了$10,000仍然应该被 Policy 拒绝。if(action.amountMinor()order.refundableAmountMinor()){returnDecision.DENY;}所以签名是Identity Integrity不是Business Authorization第五层签名必须绑定Authorization Decision可以在 Action 里继续加入grant_id approval_id policy_version例如{grant_id:grant-77,approval_id:approval-19,policy_version:refund-policy-v12}Gateway 验证签名有效 Grant有效 Approval有效 Policy仍允许才提交。第六层签名要防Replay攻击者拿到一份完整合法请求重复发10次签名每次都有效。所以一定需要idempotency_keyGateway 保存createtablewrite_idempotency(idempotency_keyvarchar(256)primarykey,action_hashvarchar(64)notnull,statusvarchar(32)notnull,result_refvarchar(512),created_at timestamptznotnull);第一次执行后面同 Key返回原结果如果 Key 相同但 Action Hash 不同SECURITY ERROR第七层Expiry要短一个签名动作最好只活30秒 2分钟 5分钟而不是一天。验证if(Instant.now().isAfter(action.expiresAt())){thrownewExpiredActionException();}长期审批可以存在更久。真正执行签名应该短。第八层数据库行要保存Signature Evidence不要验证完就丢。例如createtablerefund_ledger(refund_idvarchar(128)primarykey,order_idvarchar(128)notnull,amount_minorbigintnotnull,agent_idvarchar(128)notnull,run_idvarchar(128)notnull,action_hashvarchar(64)notnull,signature_refvarchar(512)notnull,key_versionvarchar(64)notnull,created_at timestamptznotnull);以后可以独立做Integrity Audit后台Audit怎么工作每天抽样或全量读取Ledger ↓ 重新Canonicalize ↓ 计算Hash ↓ 验证历史Signature如果某行被 SQL 直接改过Hash对不上立即报警。这就是签名真正的价值之一数据库本身被修改 也能发现Key Rotation必须保存Key Version如果 Key 每90天轮换旧记录仍然需要验证。所以签名记录不能只存key_id要存key_version历史 Public Key 继续保留用于 Verify。Key Rotation流程Create new key version ↓ New writes use v2 ↓ Old v1 disable signing ↓ Keep v1 public verify ↓ After retention ends archive不要直接删除旧 Key。Agent-to-Agent写操作更要签名Supervisor让 refund-agent 执行退款最终签名者应该是refund-agent同时保留parent_run delegation_id这样能还原谁提出 谁授权 谁真正写不要让 Supervisor 用自己的 Key 替所有 Sub-Agent 签。一个Delegated ActionpublicrecordDelegatedWriteAction(StringagentId,StringparentAgentId,StringdelegationId,StringrunId,Stringcapability,StringresourceId,StringactionHash){}Write Signature最适合哪些动作非常适合退款 预算修改 权限修改 数据库关键状态 部署状态 合同审批状态不一定需要给每条Debug日志都签。优先覆盖高价值、不可逆、合规要求高的写操作。最少测试这10种情况1. Payload字段顺序变化 2. 金额被篡改 3. Order ID被篡改 4. 签名过期 5. 相同Idempotency重复提交 6. 同Key不同Payload 7. Agent使用错误Key 8. Grant撤销后执行 9. Key Rotation后验证旧记录 10. 直接SQL修改Ledger后Audit报警签名解决不了什么它解决不了模型为什么做出错误决定也解决不了业务Policy写错它能提供的是确定是谁 确定签了什么 确定内容没被改 确定历史可验证这已经是生产 Agent 非常重要的一层。Agent 有写权限以后真正成熟的系统不能只依赖数据库账号有权限而应该继续建立Workload Identity Action Signature Policy Approval Idempotency Immutable Audit这样即使模型被诱导、服务被误配或数据库记录被直接修改系统仍然有硬边界和证据。Prompt 可以告诉 Agent“不要乱写。”签名和 Gateway 则能证明这次到底是谁写的、写了什么、是否经过授权。这两个层次完全不是一回事。