AI代理的可验证委托与认证：构建可审计的授权链

如果你的 AI 代理明天能自动帮你在客户系统里提交订单，你能回答一个看起来很简单的问题吗：它到底是依据哪一条授权，在什么时间、以谁的名义、带着哪个约束条件去执行了这个动作？如果它执行错了，你拿什么证据证明是委托链路设计出了问题，还是代理本身判断错误？

这不是一个纯理论问题。随着 AI 代理从“只会聊天”走向“实际操作工具和系统”，它已经从一段代码变成了业务链条里的一个参与者。Kessa 想解决的，正是围绕这个参与者建立一条可验证的委托与认证链。项目标题里的 verifiable delegation and attestation system，翻译过来就是：面向 AI 代理的可验证委托与认证系统。

这里的关键词有三个：委托、认证、可验证。前两个解决的是“权限从谁到谁、行为由谁背书”的问题；第三个解决的是“你可以把证据交给验证方，让对方自己确认”，而不是只能听其中一方提供日志。Kessa 这个名字在 HN 上出现时，第一眼看上去像一个身份与权限工具，但它真正值得关注的地方，是把“AI 代理替你做事”这件事从主观信任变成了可审计事实。

我没有拿到 Kessa 的源码级细节，下面所有工程经验都是基于“可验证委托与认证”这个方向展开的通用判断。如果你要把它接入自己的系统，还是需要回到对应仓库的 README、源码和版本记录里确认接口。这篇文章的价值，是帮你先建立一套判断这类系统的思维框架。

1. AI 代理真正缺的不是更多能力，而是一条可验证的授权链

1.1 当代理开始替你做事，信任问题就变了

过去我们使用 AI，主要是“问它问题”，模型输出一段文字、一段代码、一份摘要，责任最终还是落在使用者身上。你复制代码，你自己检查；你参考建议，你自己判断。这个阶段里，AI 不是一个行动者，它只是一个信息提供者。

但 AI 代理不是这样。代理会调用工具、访问数据库、读取邮件、创建工单、修改配置、提交订单。它不再只是“建议你这么做”，而是“它真的去做了”。这时候系统要回答的核心问题已经变了：不是“它说得对不对”，而是“它做了这件事之后，谁来对这件事负责”。

传统做法是给它配一个服务账号、一把 API Key，再把所需权限都绑到账号上。这种方式在微服务之间还能运行，因为服务是确定性的，行为边界可以通过代码评审控制。但代理不一样，代理的决策路径是不确定性的，同一个请求在不同模型版本、不同上下文、不同工具返回结果下，可能做出不同动作。

所以，当代理真正开始执行动作时，我们需要的不是“账号权限大而全”，而是“代理的每一个动作，都能被追溯到某一条明确授权上”。Kessa 这样的系统，本质上是在为“代理代我执行”这件事建立一层可验证的证据链。

1.2 为什么 API Key 加对话日志还不够

有一个很常见的误解：只要后台记录了 API 调用日志，出了问题翻日志就是了。但在 AI 代理场景里，日志能提供的东西非常有限。

第一，普通日志回答不了“代理这次调用的权限依据是什么”。日志通常只记录“谁调用了什么接口”，但不会记录“这个调用是否符合一条委托规则”。如果代理拿着一个权限过大的 Key，日志只能告诉你它有权限，不能告诉你它为什么有权限，也不能告诉你授权者当初是不是只允许它做这次范围内的事。

第二，日志是自证式的。系统自己被攻破，或者内部人员在日志上做手脚，审计的人很难从日志本身发现异常。可验证的方案会把关键凭证做签名处理，验证方可以不依赖系统管理员的“口头保证”，而是通过密码学验证来确认委托是否真实、是否过期、是否被撤销。

第三，API Key 没有上下文约束。一个 Key 可能是“可以读订单”和“可以删订单”放在同一个权限模型里的，但 AI 代理的一次具体调用应该只允许“读取订单”，不允许“删除订单”。这需要比 Key 更细粒度的委托信息。

所以，Kessa 这类项目提出的问题非常实在：你如何让一个外部环境也能验证“这个代理确实被授权做这件事”，而不是“这个代理恰好有一个能用的 token”。

2. Kessa 要解决的，是三层问题：身份、委托、验证

2.1 委托不是授权一个账号，而是授权一个可追踪的行为

委托（delegation）这个词，很多人会理解成“给代理授予权限”。这个概念本身没错，但不够准确。传统的授权是“给账号加权限”；委托更像“给你一张有限的、有条件的授权书”。

举个例子：你让同事帮你取快递，不是把你的门禁卡、身份证、银行卡全部给他，而是告诉他“去 3 号楼前台，报我的名字，取一个写着 XXX 的快递”。这份委托有时间范围，有明确对象，有具体任务边界，而且如果你中途改主意，可以通知前台撤销这次授权。

AI 代理的委托也应该这样。一个普通用户可能希望授权给某个代理：“在 3 月内，帮我查询订单状态，但不能修改订单；单次金额不超过 5000 元的订单可以自动确认。”可以看到，这条授权里包含了很多约束，代理能做什么、不能做什么、什么时候有效、超出范围怎么处理。

Kessa 的关注点显然不只是“给代理发一个 token”，而是要定义一种可以被机器验证的委托结构：谁发的、发给谁、能做什么、有效期多久、在什么条件下生效、是否可以撤销。

2.2 认证到底是认证什么

attestation 这个词在不同场景里译法不一样，可以叫“认证”，也可以叫“证明”。核心意思是：向验证方提供一个可信的证据，证明某个声明是真的。

这里最关键的判断是：Kessa 想要证明的是“代理的身份”，还是“代理执行动作的合法性”？从项目标题看，它不是单纯的“身份认证”，而是“委托与认证的结合”。也就是说，验证方不只是确认“这个代理确实是那个代理”，还要确认“这个代理的行为的确是经过委托的”。

这个区别很重要。假设攻击者拿到了代理的私钥，未来他把代理身份伪造成合法身份，签名校验会通过，但这不代表他的行为应该被允许。可验证委托系统要做的是把身份和授权绑定在一起：代理可以证明“我是 agent-X”，同时必须附带“我持有用户 U 签发的委托，允许我在某个时间窗口内访问订单接口”。

所以，认证的对象应该是一个“请求上下文”，而不只是一个静态主体。验证方要问的问题是：当前这个动作，是否在一条有效委托的覆盖范围内。

2.3 把一层可验证的链条放到代理执行之前

如果只让代理内部自己判断“我有没有权限”，本质上还是自证。Kessa 这类系统的做法，是把验证动作放到代理和资源之间：代理发请求时，需要携带一个委托凭证；资源端或网关先验证凭证，再决定是否放行。

这样一来，代理就不能只依赖自己的“意识”去判断权限，而是每一次实际操作都需要经过外部验证。这个设计和你平时使用 OAuth 或 JWT 很像，但代理场景更复杂，因为代理不是人，它可能同时面对多个工具、多个用户、多个上下文。

一个可验证委托链通常包含这样的步骤：

• 用户或管理员创建一个委托，声明“允许谁、在什么时候、做什么、有什么限制”。
• 把委托编码成结构化数据，用签发者的私钥签名。
• 代理发起请求时，把委托凭证附在请求里。
• 验证方检查签名、有效期、撤销状态、约束条件。
• 验证通过后，资源系统才允许执行动作，同时记录验证证据。

这是一条非常关键的链路。Kessa 的价值不在于让 AI 代理“更聪明”，而在于让整个执行过程是“可检查的”。

2.4 结果认证与执行认证，不要混为一谈

很多人听到“attestation”会想到远程证明，比如 TPM 证明、可信执行环境，把执行环境完整性报告给验证方。Kessa 可能也会涉及类似的证明，但我们要区分两件事：

• 执行认证：证明“这次动作是按照委托执行的”。
• 结果认证：证明“代理输出的结果是正确的、可信的”。

后者在 AI 场景里非常难，因为模型输出是概率性的，同一个 prompt 可能得到不同结果。可验证委托系统可以证明“代理在执行前得到了合法授权”，但不能保证“代理理解任务没有偏差、输出答案完全正确”。这是模型能力问题，不是授权链问题。

如果 Kessa 能够做到前者，就已经很有价值了；如果它还尝试做后者，那它可能走得更远，但验证难度也更大。落地时，不要把两者的边界模糊掉。

3. 从工程角度，我会按这张图拆解 Kessa 类系统

3.1 角色划分：委托签发者、代理、验证方、审计方

任何可验证系统第一步都是把角色拆清楚。我建议至少拆成四类角色：

• 委托签发者：通常是用户、管理员或更高层级的代理，负责声明“接下来允许谁干什么”。
• 代理：实际发起请求、执行动作的 AI 程序。它持有委托凭证或凭证引用。
• 验证方：通常是资源服务器、API 网关或工具适配层，负责检查凭证是否有效。
• 审计方：不直接参与请求链路，但需要事后核查完整证据链。

如果只有一个统一的系统，可能边界不清晰，但工程实现时必须把“签发”和“验证”分开。否则，签发方也是验证方，会出现“既当运动员又当裁判员”的信任问题。Kessa 这类项目如果做得好，验证逻辑应该是一个独立模块，甚至可以让第三方实现。

3.2 委托信息里应该包含什么

这里是一个通用的委托结构示例，不代表 Kessa 的实际 API 字段，但可以帮助你理解需要关注哪些信息：

{ "delegation_id": "dlg_8f3a7c", "issuer": "user:alice@example.com", "subject": "agent:order-bot@example.com", "scope": [ "order:read", "order:create" ], "conditions": { "max_amount": 5000, "time_window": "2025-06-01T00:00:00Z/2025-06-30T23:59:59Z", "allowed_resources": ["orders.example.com"] }, "enable_revocation": true, "revocation_id": "rev_1024", "valid_from": "2025-06-01T00:00:00Z", "valid_until": "2025-06-30T23:59:59Z" }

注意几个容易被忽略的点：

• scope不能太粗，最好细到“读还是写”“哪个资源”“是否允许删除”，而不是“订单模块”。
• conditions里要写清楚时间、金额、资源路径等可验证约束。
• revocation_id是未来撤销凭证的关键索引。没有它，撤销只能靠过期，很不灵活。
• 委托本身还要有签名信息。上面这个 JSON 示例只是展示概念，真正实现时通常会把签名放在 header 或者独立签名段，并采用标准格式保护字段完整性。

3.3 验证逻辑按固定顺序走，不要跳跃

在接入验证逻辑时，我建议按这样一个顺序排查：

1. 先验证签名：签名无效直接拒绝，不做后续操作。
2. 再验证有效期：当前时间是否在valid_from和valid_until之间。
3. 再查撤销状态：这个委托是否已经被吊销。
4. 最后匹配约束：请求的具体动作和参数是否落在scope和conditions内。

这个顺序看起来简单，实际容易踩坑。如果先查撤销状态，签名无效的委托也会触发一次外部网络请求，容易被恶意伪造请求打满撤销服务。如果先匹配约束，可能在签名无效时也消耗大量计算资源。

一段示意伪代码可以更长这样：

def verify_delegation(delegation, request_context): if not verify_signature(delegation): return VerificationResult(status="rejected", reason="signature_invalid") if not is_within_validity_window(delegation, request_context.now): return VerificationResult(status="rejected", reason="delegation_expired") if revocation_service.is_revoked(delegation.revocation_id): return VerificationResult(status="rejected", reason="delegation_revoked") if not match_conditions(delegation.conditions, request_context): return VerificationResult(status="rejected", reason="condition_not_satisfied") return VerificationResult(status="approved")

这个顺序的优势在于：每一步都能给出明确的失败原因，方便排查。它不依赖模型判断，也不依赖日志分析，是一套稳定的机械校验流程。

3.4 时间戳、撤销列表和环境差异会在什么时候咬你

分布式系统里，最容易出现的问题不是核心逻辑，而是边缘细节。

时间戳是第一个陷阱。签发方和验证方的服务器可能不在同一时区，甚至存在时钟偏移。建议统一使用 UTC 时间，并在验证时对时间窗口做小范围宽容处理，但宽容度不能太大，否则过期委托可能被重放。

撤销列表是第二个陷阱。如果 Kessa 的撤销机制依赖中心化服务，验证方每次都要请求撤销服务，那么这层服务本身就是高可用瓶颈。如果撤销列表本地缓存，就存在缓存窗口期内继续放行的问题。落地前要明确：业务上能接受多长的撤销延迟。

环境差异是第三个陷阱。代理运行环境可能是一个容器、一台虚拟机，也可能是一个 SaaS 服务。如果验证逻辑依赖环境标识，那环境标识本身要能被安全获取，否则就容易被伪造。不要假设所有运行环境都能提供可信度量值。

4. 评估 Kessa，我会先跑这五个验证点

4.1 验证点一：最小闭环能否跑通

拿到 Kessa 或任何同类项目，第一件事不是看宣传文案，而是搭一个最小闭环。我建议这样操作：

• 创建两个身份：一个是用户或管理员，一个是代理。
• 用用户身份签发一条最小委托，只允许代理访问一个测试资源。
• 让代理携带这个委托去调用测试资源。
• 验证方检查委托并放行。
• 最后看一下审计端能否看到完整记录。

如果这一条链路能跑通，说明核心机制是有的。如果连最小闭环都跑不通，大概率是文档版本、依赖版本或环境问题，先不要在生产环境里使用。

4.2 验证点二：凭证撤销是否真有效

很多系统的签发做得很好，但撤销很敷衍。你可以在测试环境里签发一张长期委托，然后主动撤销，再让代理用同一张委托请求资源。

这时候你应该观察：

• 撤销之后，验证方是否立刻拒绝。
• 撤销服务本身是否可用。
• 如果验证方有缓存，撤销生效时间是多少。
• 撤销之后，审计日志有没有记录这次拒绝。

撤销不是附加功能，它是委托系统能否长期使用的关键。一个无法撤销的委托，等于给未来埋了一颗定时炸弹。代理的访问策略需要随时调整，不可能坚持到有效期结束。

4.3 验证点三：审计日志是否可独立复核

很多系统的日志只是“不可变更”，但“可验证”要求更高。

你不需要立刻深入密码学细节，但可以问一个问题：如果我把一条审计记录导出来，交给一个没有系统管理员权限的第三方，他能不能根据委托凭证和验证规则，自己确认这个调用是否合规？

如果答案是不能，那这个日志可能只是操作流水，不是可验证证据。Kessa 这类项目如果想做到“可验证 attestation”，至少要让审计记录和委托签名对得上。也就是说，审计记录里应该包含足以验证委托有效性的信息，而不仅仅是一句“success”。

4.4 验证点四：异常场景有没有明确出错信息

AI 代理在实际运行中会遇到很多异常：委托过期、权限不足、撤销列表超时、签名格式不对、约束条件不满足。

我建议专门做一轮异常测试：拿着过期委托请求、拿着伪造签名请求、拿着超出金额限制的请求、在没有撤销服务时请求。这时候好的系统会返回明确错误码，方便代理侧判断是“换一个委托继续”还是“停下来找人工”。如果所有错误都返回同一个“403”，代理无法区分原因，只能盲目重试，或更糟，尝试绕开验证。

异常语义也是工程接缝的一部分。评估早期就把它纳入测试范围，后面能省很多事。

4.5 验证点五：密钥管理与生命周期是否清晰

可验证委托系统的安全基石在私钥，而不是模型。签发者的私钥一旦泄漏，攻击者可以伪造任意委托。所以你需要确认：

• 私钥放在哪里，是普通服务器环境变量，还是 HSM / KMS / 安全存储。
• 密钥轮换策略是什么，轮换时旧凭证如何处理。
• 是否支持多签发者，不同用户是否有不同密钥。
• 如果代理端也需要持有私钥，这个私钥如何保护。

如果 Kessa 只是简单把私钥存在配置文件里，那它适合学习和 demo，不适合直接接入真实业务。如果它有完善的密钥管理接口，才值得往生产环境考虑。

5. 落地前要接受的四个边界

5.1 可验证委托不能保证“结果正确”

即使每一条授权都被严格验证，AI 代理仍然可能做出错误决策。举例来说，代理获得了“可以查询订单、可以发送通知”的委托，它可能正确调用了接口，却因为理解偏差，把原本应该发给客户的“订单已发货”短信发成了“订单已取消”。

验证链只能证明“调用行为是合规的”，不能证明“这个动作对业务是正确的”。所以 Kessa 这类系统更适合被当作控制层，而不是决策层。业务上还是需要围绕代理的输出设计核对、人工审批、回滚机制。

5.2 它解决的是授权与审计，不是提示词安全

很多人会以为只要做了委托验证，代理就不会被提示词注入攻击。这是两码事。提示词注入可能诱导代理执行一个本来不应该执行的动作，但如果代理执行时携带了合法委托，验证系统依然会放行，因为从委托的角度看，这个动作确实在授权范围内。

所以，可验证委托系统可以缩小权限边界，但不能替代模型鲁棒性测试。不能让一个被在线提示词干扰的代理直接接触所有可执行操作。你仍然需要通过更细粒度的委托限制、敏感操作二次确认等方式降低风险。

5.3 它需要配套的身份与密钥基础设施

委托系统不是安装一个库就能跑的。它需要至少具备：

• 稳定的身份体系：用户、代理、组织如何唯一标识。
• 可靠的密钥管理：签发密钥不能放进普通代码仓库。
• 可用的时间服务：系统统一使用 UTC 时间。
• 可维护的撤销列表：撤销记录不能因为服务重启就丢失。

如果你的项目还没有这些基础设施，Kessa 的接入成本会比想象中高。它不是帮你从零建立身份系统，而是帮你在一套已有身份系统之上建立可验证授权链。

5.4 撤销永远比签发更难

签发一张委托很容易：填字段、签名、分发。但撤销一张委托，需要考虑更多问题：撤销信息如何传播、验证方多久能看到、在途请求怎么处理、已经执行完的动作是否还能补救。

一个合理的策略是：委托有效期尽量短，不要签发“永久委托”。短期委托即使撤销不及时，也只会影响一个相对短的时间窗口。另一个策略是高危操作单独签发一次性委托，执行完立刻过期，这样撤销压力会小很多。

6. 为什么这条链值得长期关注

6.1 从“对话式助手”到“交易型代理”的关键门槛

AI 代理要进入真实业务，最难的往往不是模型能力，而是组织愿意给代理多大的执行权。给权限，担心失控；不给权限，代理只是个聊天框。

可验证委托系统提供了一条折中路：不是一次性给代理一个万能钥匙，而是让每一次执行都绑定到一条可审计的授权链上。组织可以从低风险操作开始，逐步扩大代理权限。这种渐进式放权，对团队建立信任非常重要。

Kessa 这个项目出现的时间点很有意思。它刚好踩在 AI 代理从 demo 走向生产的节点上。现在很多开发者已经知道要防 prompt injection、要做 trace 和 eval，但真正能解决“代理替谁执行、依据什么执行、谁能验证执行过程”的方案还比较稀缺。

6.2 对开发者和团队来说，现在该做什么

我在评估这类系统时，一般会建议团队走这样一条路径：

1. 先梳理现有 AI 代理会触达哪些资源和操作。
2. 把每个操作按风险分级，从低风险到高风险排序。
3. 给高风险操作设计最小权限委托，不要一把 Key 打通全部。
4. 接入可验证委托系统后，先做严格人工复核阶段。
5. 积累一段时间日志，再看哪些代理行为是稳定可控的，逐步放宽自动执行范围。

这个过程不依赖某个具体项目，Kessa 只是其中一种可选项。重要的是，团队要先形成“代理执行必须有可验证凭证”的意识，而不是等出错之后再来补。

6.3 保持最小信任、最短链条、最大审计

最后我想把这个主题收束成一个更底层的经验：AI 代理越是能干，越需要在授权上做减法。最小信任是指默认不给代理任何超出任务所需的权限；最短链条是指委托链路不要绕太远，能一次签名解决就不要套多层；最大审计是指所有关键动作都尽量留下可独立验证的证据。

Kessa 这类可验证委托与认证系统，真正改变的不是“代理能不能调用某个接口”，而是代理在组织内部从“不可解释的执行黑盒”变成了“有授权边界、有验证记录、有追溯路径的可信参与者”。如果你正在做 AI 代理项目，我建议你尽快把“可验证委托”放进架构设计里，哪怕现在不接 Kessa，也应该用同样的思路保护自己的系统。