Lit Protocol v3：让签名权限跟着经过审核的代码走

公司希望一把付款密钥，只在服务核验发票已经批准后签名。把密钥放在 Agent 之外很有帮助，但还剩一个问题：Agent 能否要求签名服务换一段代码运行？Lit 当前的架构把“允许运行的程序”也纳入了授权模型。

资料边界： 本文于 2026 年 11 月 1 日核对 Lit v3 官方文档，没有创建付费账户、验证在线 attestation，也没有执行 Lit Action。发票签名例子是建议设计。

先使用当前 Chipotle 模型

快速入门将 Chipotle 定义为 Lit Protocol v3，介绍 JavaScript 编写的 Lit Actions、供程序使用的 PKP 钱包，以及分开的管理凭证与执行凭证。早期网络教程不应未经迁移核对，就与当前模型混用。

对 Agent 应用，Lit Action 可以成为一段专门、受限的签名程序。应用让审核过的代码评估拟议操作，而不是给模型一个通用签名接口。不过，前提是代码真正检查了收款人、资产、金额及它依赖的任务证据。

这里存在两道权限问题

权限组关联允许的动作标识与 PKP 钱包；调用者的 usage key 还需要拥有相关执行范围。所以“能运行任意代码”与“这段代码能用某个钱包”是两回事。文档中的通配执行设置，并不会自动开放所有 PKP。

权限边界概念示意，非可信执行证明或签名实测。广播交易与付款对账不在此简图内。

在发票方案中，调用者拿到仅能访问付款组的凭证，组里包含预期代码与钱包。模型不应同时持有能够注册替代代码、或把其他钱包加入组的管理凭证。否则，负责遵守限制的进程也可能有权删除限制。

代码哈希解决了一类问题，不是全部问题

Lit 的架构说明介绍了按内容标识的动作、链上权限状态和 TEE 执行。代码修改后，标识也会变化。官方同时明确区分：证明运行了哪段代码，不等于证明代码没有漏洞。

我们更关心审核代码接受什么输入。如果动作直接相信 Agent 传入的“发票已批准”标记，它就算忠实执行，也只是在检查一个没有约束力的条件。更可靠的方案应从明确的授权来源核验证据，把证据绑定到具体付款，并处理过期和重复使用。

还应审核外部 API 失效时的行为。审批来源不可用时，是拒绝、等待，还是回退？答案应体现在代码和运行流程中。通过可信执行证明的程序，同样可能准确执行一个不合适的回退策略。

把管理员与工作进程分开

API Key 文档区分账户管理密钥与受范围限制的 usage keys。管理权限可以改变资源和授权，使用密钥面向日常执行，也可以单独撤销。账户管理密钥本身不是执行动作所用的凭证。

产品团队应记录哪个进程持有什么凭证、能访问哪个组、如何叫停。不能因为开发演示跑通，就把方便的通配权限直接带到生产。还要检查同一个 PKP 是否出现在其他组：一条路径受限，不代表另一路径没有更宽的权限。

决定谁能修改规则

API 模式与 ChainSecured 模式的区别，在于管理所有权和管理写入如何签名。ChainSecured 模式由运营方控制的钱包直接在 Base 授权这些变更；文档说明，从 API 模式转换过去是单向操作，管理交易也需要 Base Gas。

因此，账户模式是治理选择，不只是注册体验。要确定谁批准新代码版本、谁轮换运行凭证，以及管理员如何恢复访问。成本中也要包括动作执行与管理操作，不能认为转移管理所有权就免除了服务使用费。

审核范围	对付款方案应提出的具体问题
代码	收款人或资产变化后是否拒绝？
证据	谁证明发票已批准，证据何时失效？
范围	工作进程能否用同一钱包执行其他动作？
变更	谁能登记新代码或修改权限组？
故障	执行额度或外部依赖不可用时怎么办？

我们的判断

如果产品希望把签名行为绑定到可检查的代码，而不是一个权限宽泛的后台签名器，Lit 值得研究。代价是代码、权限关系、管理所有权和运行依赖，都进入了钱包审核范围。本文没有宣称 AgentWallets 独立审计过其硬件或部署系统。

相关资料见 Lit Protocol 目录页与 Agent 额度设计。一个合格原型应能把预期拒绝解释得与成功签名一样清楚。