把 Agent 的权限交接变成可验证证据：用 Kessa 审计多层委派
让一个编码 Agent 调用部署、数据库或支付工具时，真正棘手的并不只是“要不要弹确认框”。现实中的任务会继续拆分：人把工作交给主 Agent，主 Agent 再委派给测试、检索或执行子 Agent。若每一跳都沿用最初的高权限令牌，最终拿到生产权限的进程可能只是在做一项很小的只读检查；出了问题后，普通日志又很难回答：当时究竟允许了什么、谁把权限交给了谁、记录有没有被改过？
Kessa 是一个面向这类链式委派的开源项目（AGPL-3.0，Go）。它不判断提示词内容是否安全，也不是通用的内容过滤器；它关注的是权限的传递、执行时的约束和事后的独立复核。项目的关键约束很直接：每次委派都签发一份新的、更窄的凭证，不能由下游自行扩大权限。
问题不在“有没有权限”，而在权限能否随任务缩小
把服务账号的完整密钥交给 Agent 很方便，却会把“能做什么”与“这次要做什么”混为一谈。例如，主 Agent 只需让子 Agent 检查一份发布报告，但若子 Agent 获得的是同一把可写生产库的密钥，权限边界事实上已经消失。
Kessa 将委派链、策略、批准与行动证据放在同一条可校验链路中。上游给下游的不是权限副本，而是带限制的新凭证；如果某一跳试图扩大自身可授予的范围，项目的说明称它会在签发阶段被拒绝。执行端产生的审计导出还带有哈希链与签名，签名覆盖日志长度和末端，因此事后修改、重排或悄悄缩短记录都会破坏验证结果。
这带来一个重要的分工：执行端负责实施策略，但验证端不应只相信执行端写下的“allow”。Kessa 的独立验证器会根据随行动携带的证据重新推导结论。也就是说，审计对象不是一句“系统说它允许了”，而是一组可以离线重新检查的文件。
先跑完整演示，再看验证器输出
项目要求 Go 1.26 或更新版本，以及 make 和 bash。仓库没有第三方 Go 依赖；官方示例把七个确定性场景打包进一个离线可运行的演示：
make demo
这适合先确认团队是否接受它的信任模型。若要拆开看流程，可先构建二进制、签发一条链，再对审计导出做离线验证：
make build ./bin/kessa-issuer publish \ --spec examples/issuer/spec.json \ --keystore examples/issuer/keystore.json \ --root ./public \ --out ./private/chain.json ./bin/kessa verify \ --export testdata/audit_export_v2.golden.json \ --dids ./public \ --status "https://localhost/orgs/acme/status.json=./public/localhost/orgs/acme/status.json"
这里的 --dids 指向验证器所使用的公钥材料；示例中的状态 URL 被映射到本地文件，所以验证过程不需要启动服务或联网。官方文档规定：退出码 0 表示所有条目依据携带证据通过验证，1 表示发现失败或不完整性降级，2 是使用或 I/O 错误。默认情况下验证器只读取文件；只有显式使用 --fetch-dids 才会通过 HTTPS 获取 did:web 文档。
对工程团队而言，这个例子的价值在于可以把它放入变更审批后的工件归档：保留导出、策略和独立取得的公钥材料，在事故复盘或合规抽查时，用不同机器上的验证器重新运行。它不替代密钥管理、网络隔离或业务侧授权，却能补上“委派过程是否仍符合当时声明的权限”的证据层。
生产接入前，先把边界写进威胁模型
Kessa 当前明确标注为仍在积极开发、尚未达到生产加固状态。其安全审查是项目自行运行的 AI 红队轮次，不是第三方审计；这一点不应被宣传材料掩盖。密钥后端方面，文档列出软件 keystore 与 macOS Secure Enclave 两条路径；前者适合演示、CI 或评估，但私钥会以明文存在于文件中。项目也明确说目前没有 Linux TPM 或 Windows 后端。
更容易被误读的是“离线验证”的结论。一次 PASS 证明的是导出与你提供的 DID 文档及其公钥一致，而不是自动证明这些公钥来自真实、可信的主体。若导出和 DID 文档都来自同一方，验证者只能确认那一方内部自洽；公钥信任根必须经独立渠道取得。此外，日志完整性也有边界：签名能防止已有导出被事后截短，却不能证明执行端把每一次本应记录的决定都写进了日志。
因此，较稳妥的采用方式是先把 Kessa 放到高风险动作的窄场景：例如发布 Agent 只能把“读取部署状态”的权限委给诊断子 Agent，而“重启服务”仍需另一条带人工批准的委派链。再将验证导出与 CI 工件、变更单和独立的密钥分发流程连接起来。这样既能获得可复核的权限轨迹，也不会误把一个仍在演进的项目当成完整安全控制面的替代品。
把验证纳入交付流程，而不是只留在事故后
在真实工程里，最有价值的接入点往往不是给每一次文件读取都增加凭证，而是识别“后果开始不可逆”的边界。例如：生成候选 SQL、收集部署日志可以由普通的低权限子 Agent 执行；提交迁移、修改访问策略、触发生产发布则需要一条明确的委派链，并把批准、策略版本、凭证状态和执行结果一起归档。这样，审批系统不必理解所有 Agent 的内部推理，只需要求每个会造成外部后果的执行端携带可验证的授权证据。
可将验证安排为两道独立检查。第一道在流水线中运行：部署完成后保存审计导出，并执行 kessa verify；非零退出码使交付进入人工复核。第二道由不控制执行环境的审计方重跑：从独立渠道取得 DID 文档，把导出放在隔离目录中验证。两道检查的目标不同：前者防止明显的证据损坏，后者降低“执行者自己证明自己”的风险。
也要把撤销设计为工作流的一部分。项目说明中，状态列表参与每一跳的检查；但没有状态列表引用的凭证将无法撤销。因而在发放高风险委派前，团队应约定谁维护状态列表、其发布频率、凭证有效期与紧急冻结程序。否则，即使验证器能忠实报告一条链有效，也无法弥补权限材料本身没有可操作的失效机制。
最后，避免把“验证通过”误读成“业务安全”。Kessa 可重新推导某次允许是否与携带策略一致，却不能判断策略是否把删除生产数据错误地设为允许，也不检查获准动作处理的数据是否合规。策略评审、服务端身份认证、网络隔离、密钥轮换和业务审批仍然各自必要。它提供的是这些控制之间缺失的一层：让多 Agent 的授权过程从难以解释的运行时状态，变成可交接、可验证的证据。
何时值得使用
如果系统只有一个 Agent、一个短生命周期令牌，简单的最小权限与审计日志通常更直接。Kessa 更适合权限会跨人、组织、主 Agent 与子 Agent 连续传递，并且需要在事后向另一方证明“权限没有在途中变宽”的工作流。它的设计重点不是让 Agent 更自主，而是让自主执行留下可验证、可撤销、可质疑的权限证据。
相关链接