AI Agent权限难题:可验证委托与证明系统如何重塑信任链
AI Agent 正在从“聊天机器人”变成真正能动手操作系统的自动化执行体。但一个很现实的问题也随之而来:当 AI 代理代替人类去做判断、下单、调用 API、修改配置时,服务端凭什么相信这个 Agent 真的有权限?
传统的 API Key 只能证明“你持有某个密钥”,但无法证明“你这把钥匙是被谁委托给你的、委托范围是什么、有效期多久、链路里哪一步出了问题”。一旦 Key 在被 Agent 内部工具调用中泄露,或者被上游 Prompt 注入劫持,整个权限链条就断了。更麻烦的是,多 Agent 协作时,A 派任务给 B,B 又派给 C,你根本没法追溯到底谁对最终操作负责。
这正是 Kessa——一个面向 AI agents 的可验证委托(Delegation)与证明(Attestation)系统 试图解决的问题。它来自 Hacker News 的 Show HN 项目,核心思路是:让 Agent 的每一次“代行权限”都带上可验证的凭证,凭证能说明委托者是谁、授权范围是什么、证明是如何签发的,并且第三方可以独立验证,而不用把所有信任都压在一个人或一把密钥上。
这篇文章我会从问题背景、核心概念、系统设计、可运行的最小示例、常见坑和工程建议几个维度展开。读完你能理解:这类系统解决的痛点和传统权限模型有什么本质差异,以及如果要在自己的 Agent 项目里实现“可验证委派”,一个最小可行方案应该是怎么样的。
1. AI Agent 的“权力危机”:为什么传统 API Key 不够了
1.1 AI Agent 正在成为真正的执行者
过去的自动化工具通常是“人写脚本,脚本调接口”。接口识别身份靠密钥,密钥只有一个人拿着,操作链路基本可控。
AI Agent 改变了这个局面。它的特征不再是“脚本写死逻辑”,而是在运行时自主做决策。一个 Agent 可能根据用户的一句话,自己去查找订单、调用支付接口、修改数据库字段、发送通知邮件。它的行为序列不是预先固定的,而是模型推理出来的。
这个变化带来一个本质问题:执行主体的不确定性。过去执行者是明确的人或固定脚本,现在执行者是模型推理出来的动态行为链。你给 Agent 一个 API Key,等于给了一个“无限通行证”,但 Agent 可能因为措辞、上下文、上游数据污染而做出超出预期的调用。
1.2 传统权限模型的三大失效场景
场景一:API Key 与执行上下文绑定不足。
API Key 只负责“证明你是谁”,不负责“证明你在干什么”。一个 Agent 在单次任务里可能要调用 5 个服务,每个服务都校验同一个 Key,但没有任何一个服务知道这个 Agent 当前被委托的任务边界是什么。
场景二:多 Agent 协作导致责任链断裂。
主 Agent 把子任务委托给子 Agent,子 Agent 拿着同一把钥匙访问系统。系统只看到“同一个 Key”,根本不知道这已经是一个两条甚至三条链路之外的调用。一旦出现问题,审计无从谈起。
场景三:密钥天然无法表达“短时授权”。
密钥要么有效要么无效,很难精确表达“只允许在今天 14:00 到 15:00 内、只允许访问用户 ID 为 1024 的订单数据”。为了实现这类限制,很多团队只能给 Agent 写大量自定义 i 中间层代码,最终又层层堆叠出一个难以维护的权限系统。
1.3 一个更准确的判断
Kessa 这类系统出现的背景,正是 AI 从“辅助生成”走向“自主执行”时,权限和信任机制没有同步升级。
从项目标题看,Kessa 抓的三个关键词非常精准:Delegation(委托)、Attestation(证明)、Verifiable(可验证)。它不想再做一个“密码管理器”,而是试图把“权限”本身变成一种可携带、可验证、可审计的证据链。
如果你正在开发 Agent 应用,或者正在为公司内部的自动化流程设计权限方案,那么这套思路值得认真研究。
2. Kessa 的三个核心概念:Delegation、Attestation、Verifiable
2.1 Delegation(委托)
委托的意思是:用户或系统把某个权限,明确地转交给另一个主体去行使。在 Kessa 的语境下,这个“另一个主体”就是 AI Agent。
现实中的类比是“授权书”。你不是把公章直接交给代理人,而是写一份授权书,注明代理人可以做什么、不可以做什么、有效期到哪天。代理人办事时,需要同时出示授权书和身份证明,对方核对无误后才放行。
在系统设计里,委托必须被形式化描述:
- 委托人(Delegator):谁发起的委托。
- 受托人(Delegatee):哪个 Agent 或哪个主体被授权。
- 权限范围(Scope):允许执行哪些操作、访问哪些资源。
- 有效期(Validity):从什么时候开始,到什么时候结束。
- 约束条件(Constraints):是否需要二次确认、是否限定 IP、是否限定数据范围。
2.2 Attestation(证明)
证明是委托的载体。它不是一个简单的“授权记录”,而是一个密码学上可验证的声明。
常见的证明形式是签名凭证。委托人生成一份委托内容,用私钥对内容签名,然后把签名和内容一起发给 Agent。第三方只需要用委托人的公钥验证签名,就能确认这份委托确实来自委托人,且内容没有被篡改。
这里有一个很重要的细节:证明不等于“登录态”。登录态证明“你已经认证过了”,而委托证明要表达的是“你被允许做什么”。Kessa 这类系统更像是在为每个 Agent 操作签发“数字授权票据”,而不是单纯的会话令牌。
2.3 Verifiable(可验证)
可验证的核心是:验证方不需要联系委托人,也能确认凭证的真实性。
这句话很关键。你不需要在每次 Agent 请求时都回源查询“Kessa,这个 Agent 真的有权限吗”,而是可以直接本地验证签名、有效时间和权限范围。这样