如果你的 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:aliceexample.com, subject: agent:order-botexample.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 验证逻辑按固定顺序走不要跳跃在接入验证逻辑时我建议按这样一个顺序排查先验证签名签名无效直接拒绝不做后续操作。再验证有效期当前时间是否在valid_from和valid_until之间。再查撤销状态这个委托是否已经被吊销。最后匹配约束请求的具体动作和参数是否落在scope和conditions内。这个顺序看起来简单实际容易踩坑。如果先查撤销状态签名无效的委托也会触发一次外部网络请求容易被恶意伪造请求打满撤销服务。如果先匹配约束可能在签名无效时也消耗大量计算资源。一段示意伪代码可以更长这样def verify_delegation(delegation, request_context): if not verify_signature(delegation): return VerificationResult(statusrejected, reasonsignature_invalid) if not is_within_validity_window(delegation, request_context.now): return VerificationResult(statusrejected, reasondelegation_expired) if revocation_service.is_revoked(delegation.revocation_id): return VerificationResult(statusrejected, reasondelegation_revoked) if not match_conditions(delegation.conditions, request_context): return VerificationResult(statusrejected, reasoncondition_not_satisfied) return VerificationResult(statusapproved)这个顺序的优势在于每一步都能给出明确的失败原因方便排查。它不依赖模型判断也不依赖日志分析是一套稳定的机械校验流程。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 对开发者和团队来说现在该做什么我在评估这类系统时一般会建议团队走这样一条路径先梳理现有 AI 代理会触达哪些资源和操作。把每个操作按风险分级从低风险到高风险排序。给高风险操作设计最小权限委托不要一把 Key 打通全部。接入可验证委托系统后先做严格人工复核阶段。积累一段时间日志再看哪些代理行为是稳定可控的逐步放宽自动执行范围。这个过程不依赖某个具体项目Kessa 只是其中一种可选项。重要的是团队要先形成“代理执行必须有可验证凭证”的意识而不是等出错之后再来补。6.3 保持最小信任、最短链条、最大审计最后我想把这个主题收束成一个更底层的经验AI 代理越是能干越需要在授权上做减法。最小信任是指默认不给代理任何超出任务所需的权限最短链条是指委托链路不要绕太远能一次签名解决就不要套多层最大审计是指所有关键动作都尽量留下可独立验证的证据。Kessa 这类可验证委托与认证系统真正改变的不是“代理能不能调用某个接口”而是代理在组织内部从“不可解释的执行黑盒”变成了“有授权边界、有验证记录、有追溯路径的可信参与者”。如果你正在做 AI 代理项目我建议你尽快把“可验证委托”放进架构设计里哪怕现在不接 Kessa也应该用同样的思路保护自己的系统。