AI Agent可验证委托与证明系统：从数字签名到Kessa实践

1. 背景与核心概念

1.1 从 AI Agent 的安全痛点说起

最近在整理 AI Agent 工程化落地的技术方案时，发现一个越来越迫切的问题：当 AI Agent 被赋予越来越多“动手”能力之后，我们如何确保它每一次对外部世界的操作，都是经过授权、可以追溯、并且能够被第三方验证的？

过去我们讨论 AI Agent 安全，大多停留在“提示词注入防护”“输出内容过滤”这些层面。但在真实的生产环境里，Agent 通常需要调用外部 API、操作数据库、签发单据、调用支付接口甚至代替用户完成某些业务决策。这时候，传统 API Key 只能证明“某个客户端有权限调用接口”，却无法回答下面几个关键问题：

• 这个 Agent 是谁签发的？
• 它被授权执行哪些操作？权限范围是什么？
• 它的授权是否还有效？是否已被撤销？
• 第三方系统收到 Agent 请求时，如何验证它确实获得了用户的合法委托？
• Agent 对某个操作的证明（attestation）能否在审计时作为可信凭证？

这些问题用传统的中间件、网关、OAuth2 框架很难直接闭环。而 Kessa 这个项目，提出了一套面向 AI Agent 场景的可验证委托与证明系统，正好对应了这套需求。简单来说，Kessa 要解决的，是“如何让 AI Agent 的每一次行为和每一项权限，都能被加密验证、授权追溯、独立审计”。

1.2 什么是 Kessa

Kessa 是一个面向 AI Agent 的可验证委托（Verifiable Delegation）与证明（Attestation）系统。

用通俗的话解释：

当用户希望 AI Agent 代替自己执行某些操作时，Kessa 会为用户签发一份“委托证书”，证书里写清楚了 Agent 的身份、可以做什么、权限范围、有效期等关键信息。Agent 拿着这份证书去调用外部服务，外部服务可以独立验证证书的合法性与有效性。与此同时，Agent 执行操作时还能生成一份“证明记录”，记录这次操作是谁发起、谁授权、在什么时间做了什么。

这套机制借鉴了公钥基础设施（PKI）和可验证凭证（Verifiable Credentials, VC）中的核心思路，但面向 Agent 场景做了针对性的简化与适配。它要解决的不仅仅是认证（Authentication），更重要的是授权委托（Delegation）与操作证明（Attestation）。

1.3 为什么需要掌握这类技术

任何一个进入工程化阶段的 AI Agent 项目，迟早会遇到“权限边界”和“责任追溯”的问题。

从企业角度来看，如果你的 Agent 要自动提交工单、自动发送邮件、自动操作财务系统，那么合规审计一定会要求你回答：每一次自动化操作，是哪个人最终授权的？授权粒度是什么？操作记录是否防篡改？Kessa 这类系统就是为回答这些问题而设计的。

从开发者角度看，掌握可验证委托与证明系统的设计思路，不只是学会一个工具，更是理解在分布式环境下如何建立“信任链”。这套能力在 Web3、开放 API 平台、企业级 Agent 网关、供应链协同等场景中都是通用的。

从技术角度看，Kessa 涉及的技术点包括：

• 非对称加密与数字签名
• 可验证凭证的数据结构
• 委托授权模型
• 证明（Attestation）生成与验证
• 证书撤销与过期机制
• Agent 标识与身份绑定

这些内容组合在一起，构成了 AI Agent 安全体系的重要一环。本文将从概念、原理、设计思路到工程实现，完整拆解这个系统。

2. 环境准备与整体技术拆解

2.1 运行环境与工具链

由于 Kessa 是一个较新的项目，不同版本的接口和数据结构可能会有调整。本文以构建同类系统为例，演示核心流程与代码结构。实际使用 Kessa 时，版本需要根据你的项目实际情况调整，本文示例以常见环境为例，重点演示配置思路。

建议的本地实验环境：

操作系统：Linux / macOS / Windows（WSL2） 编程语言：Python 3.9+ 或 Node.js 18+ 加密库： - Python: cryptography / PyJWT / python-jose - Node.js: jsonwebtoken / jose 密钥格式：PEM / JWK 数据存储：SQLite（本地实验）、PostgreSQL（生产推荐）

2.2 核心模块划分

一个完整的可验证委托与证明系统，从模块上可以拆分为以下几块：

2.3 技术选型思考

在实现这类系统时，有几个技术选型需要提前想清楚：

密钥管理。Agent 的私钥不能明文放在代码里，更不能提交到 Git。生产环境建议使用 KMS（如 AWS KMS、Azure Key Vault、HashiCorp Vault）托管密钥，Agent 运行时只通过 API 调用签名操作。本地实验可以用配置文件，但必须放在环境变量或独立的密钥文件中。

凭证格式。目前业界常用的可验证凭证格式包括 JWT-VC、JSON-LD VC、CWT（CBOR Web Token）等。Kessa 这类项目通常会选择 JWT 风格，因为它生态成熟、解析方便、和现有认证体系兼容性好。自己实现时，推荐优先使用 JWT 结构。

验证方式。验签可以采用同步调用（调用验证服务 API）或本地公钥验签。生产环境推荐混合模式：本地做快速验签，同时同步校验撤销状态。

撤销机制。委托证书必须支持撤销。可以维护一张撤销列表（Revocation List），或者采用短有效期 + 自动续期的思路，减少撤销状态的维护成本。

3. 核心原理拆解

3.1 非对称加密与数字签名基础

Kessa 这类系统的安全性，底层依赖的是非对称加密。我们简单回顾一下关键概念：

• 公钥：可以公开分发的密钥，用于验证签名或加密数据。
• 私钥：必须保密持有的密钥，用于签名或解密数据。
• 数字签名：使用私钥对数据生成一段签名，任何持有对应公钥的人都可以验证这段签名是否由私钥持有者生成。

过程可以这样理解：

用户私钥签名 -> 生成委托证书 -> 外部服务用用户公钥验签 -> 确认证书真实有效

数字签名的核心价值不是加密数据本身，而是保证数据的完整性和不可否认性。只要签名有效，就说明数据在签名之后没有被修改过，并且签名者无法否认自己签过这份数据。

在 AI Agent 场景中，这份不可否认性至关重要。因为 Agent 执行操作时的自动行为，最终要追溯到某个用户的授权意愿。数字签名就是连接“用户授权”和“Agent 行为”的信任桥梁。

3.2 委托授权模型（Delegation Model）

委托授权模型解决的是“A 如何授权 B 代替自己执行操作”的问题。

在传统 OAuth2 流程中，用户授权第三方应用访问自己的资源，核心凭证是 Access Token。Access Token 是服务器签发的不透明字符串，第三方应用拿它换资源。但这种模型的缺点在于：

• Token 不携带结构化权限信息，资源服务器无法独立判断权限边界。
• 授权链不透明，第三方应用无法验证自己拿到的授权是否真的来自用户。
• 难以表达代理关系：Agent A 替用户调用 Agent B 时，中间的委托链路无法在 Token 中清晰表达。

Kessa 采用的委托模型更接近“可验证凭证”的思路：

Issuer（授权方） |-- 签发证书给 --> Agent | 证书内容：Agent 身份、权限范围、有效期、委托方签名 v Agent 使用证书调用第三方服务 | v Verifier 验证证书有效性 |-- 验签（确认是 Issuer 签发） |-- 校验权限（判断操作是否在证书范围内） |-- 检查撤销状态（证书是否已被吊销） v 允许操作 / 拒绝操作

这里有一个关键点：授权方签发的是“委托证书”，而不是普通的 API Token。委托证书中包含了结构化、可读、可验证的权限声明，第三方服务拿到证书后，不需要再回调授权服务器确认权限，仅凭签名和证书内容就可以独立完成验证。这对降低系统耦合度、提升响应速度很有帮助。

3.3 证明机制（Attestation）

证明（Attestation）在中文语境下可以理解为“对所发生事实的可信声明”。在 Kessa 系统中，Attestation 特指对 Agent 执行操作的额外担保和审计凭证。

具体来说，当 Agent 基于委托证书执行一个操作后，系统会生成一个证明对象，内容包括：

• 操作 ID（Operation ID）
• Agent 身份标识
• 委托证书 ID
• 操作类型与入参摘要
• 执行时间与时间戳
• 执行结果摘要
• 系统签名

这听起来像日志，但实际上比普通日志多了几层保障：

1. 签名保障：证明对象由 Agent 私钥签名，无法伪造。
2. 关联保障：证明对象引用了委托证书 ID，审计时可以回溯授权来源。
3. 完整性保障：操作入参和执行结果摘要做哈希处理，防止事后篡改。
4. 可验证性：第三方拿到证明对象后，可以独立验证其真实性，不需要信任 Agent 所属平台。

对于需要审计、合规、纠纷仲裁的场景，这类证明对象比普通业务日志可靠得多。

3.4 证书的数据结构设计

一个完整的委托证书，推荐包含以下字段。这里采用 JWT 风格的结构举例：

{ "alg": "ES256", "typ": "JWT", "kid": "issuer-key-2025-001" }

{ "iss": "kessa://issuer/user-123", "sub": "kessa://agent/agent-456", "aud": ["kessa://service/payment-api", "kessa://service/order-api"], "iat": 1735689600, "exp": 1735776000, "jti": "delegation-2025-01-001", "scope": "order.create, order.query", "delegation_chain": [ { "from": "kessa://issuer/user-123", "to": "kessa://agent/agent-456", "delegated_at": 1735689600 } ], "constraints": { "max_amount": 10000, "allowed_hours": ["09:00-18:00"], "allowed_ips": ["10.0.0.0/8"] } }

字段含义说明：

在实际项目中，证书字段需要根据业务场景做扩展。比如金融场景会增加“单笔限额”“日累计限额”；To B 场景会增加“租户 ID”“项目 ID”；数据合规场景会增加“数据用途声明”。

4. 工程实战：构建一个可验证委托与证明系统的核心流程

这一节我们手动实现一个简化版的可验证委托与证明系统。虽然不能完整复刻 Kessa 的全部功能，但核心流程和数据结构都保持一致。代码使用 Python 演示，你可以根据实际技术栈改写成 Java、Go 或 Node.js。

4.1 项目结构

首先创建项目目录：

kessa-demo/ ├── requirements.txt ├── config.yaml ├── main.py ├── kessa/ │ ├── __init__.py │ ├── key_manager.py │ ├── certificates.py │ ├── agent_client.py │ ├── verifier.py │ └── attestation.py └── tests/ ├── test_issue.py └── test_verify.py

4.2 环境准备与依赖

创建requirements.txt：

cryptography>=41.0.0 PyJWT>=2.8.0 pyyaml>=6.0

安装依赖：

pip install -r requirements.txt

注意：cryptography库用于生成密钥对和签名操作，PyJWT库用于生成和解析 JWT 格式的委托证书。

4.3 密钥管理模块

文件路径：kessa/key_manager.py

from cryptography.hazmat.primitives.asymmetric import ec from cryptography.hazmat.primitives import serialization import os class KeyManager: """负责生成、加载和保存密钥对""" def __init__(self, keys_dir=".keys"): self.keys_dir = keys_dir os.makedirs(keys_dir, exist_ok=True) def generate_keypair(self, key_name: str) -> None: """生成 ES256 密钥对并保存到文件""" private_key = ec.generate_private_key(ec.SECP256R1()) with open(f"{self.keys_dir}/{key_name}.pem", "wb") as f: f.write( private_key.private_bytes( encoding=serialization.Encoding.PEM, format=serialization.PrivateFormat.PKCS8, encryption_algorithm=serialization.NoEncryption() ) ) public_key = private_key.public_key() with open(f"{self.keys_dir}/{key_name}.pub.pem", "wb") as f: f.write( public_key.public_bytes( encoding=serialization.Encoding.PEM, format=serialization.PublicFormat.SubjectPublicKeyInfo ) ) def load_private_key(self, key_name: str): """加载私钥""" with open(f"{self.keys_dir}/{key_name}.pem", "rb") as f: return serialization.load_pem_private_key(f.read(), password=None) def load_public_key(self, key_name: str): """加载公钥""" with open(f"{self.keys_dir}/{key_name}.pub.pem", "rb") as f: return serialization.load_pem_public_key(f.read())

这里选用 ES256（基于 NIST P-256 曲线的 ECDSA 签名算法），是考虑到 JWT 生态对 ES256 支持比较完善，且密钥长度短、签名效率高，适合 Agent 高频调用场景。

4.4 委托证书签发模块

文件路径：kessa/certificates.py

import jwt import time import uuid from cryptography.hazmat.primitives import serialization from kessa.key_manager import KeyManager class CertificateIssuer: """委托证书签发中心""" def __init__(self, key_manager: KeyManager, issuer_id: str): self.key_manager = key_manager self.issuer_id = issuer_id def issue_certificate( self, agent_id: str, audience: list, scope: list, ttl_seconds: int = 86400, constraints: dict = None ) -> str: """ 为用户签发一张委托 Agent 的证书 :param agent_id: Agent 的唯一标识 :param audience: 允许调用的目标服务列表 :param scope: 授权的操作范围 :param ttl_seconds: 证书有效时长（秒） :param constraints: 额外约束条件 :return: JWT 格式的委托证书 """ private_key = self.key_manager.load_private_key("issuer") now = int(time.time()) header = { "alg": "ES256", "typ": "JWT", "kid": "issuer-key-2025-001" } payload = { "iss": f"kessa://issuer/{self.issuer_id}", "sub": f"kessa://agent/{agent_id}", "aud": audience, "iat": now, "exp": now + ttl_seconds, "jti": f"delegation-{uuid.uuid4()}", "scope": " ".join(scope), "delegation_chain": [ { "from": f"kessa://issuer/{self.issuer_id}", "to": f"kessa://agent/{agent_id}", "delegated_at": now } ], "constraints": constraints or {} } token = jwt.encode(payload, private_key, algorithm="ES256", headers=header) # 记录证书状态，实际项目建议写入数据库 self._store_certificate_state(payload["jti"], agent_id, payload["exp"]) return token def _store_certificate_state(self, jti: str, agent_id: str, exp: int): """记录证书状态，这里用文件模拟数据库""" # 生产环境建议使用 Redis / MySQL / PostgreSQL state = f"{jti},{agent_id},{exp},active\n" with open(".certificates_state.csv", "a", encoding="utf-8") as f: f.write(state)

签发证书时有两个细节值得注意：

一是aud字段。这个字段指定了证书可以调用的目标服务列表。验签时，验证方必须检查aud是否包含自己，否则即使是合法签发的证书，也不能接受。

二是jti字段。jti是证书的唯一 ID。撤销管理和审计追溯都需要依赖这个字段，所以签发时必须生成并持久化。

4.5 Agent 客户端模块

文件路径：kessa/agent_client.py

import requests import time import jwt from kessa.key_manager import KeyManager class AgentClient: """Agent 端，持有委托证书并调用外部服务""" def __init__(self, agent_id: str, certificate: str, key_manager: KeyManager): self.agent_id = agent_id self.certificate = certificate self.key_manager = key_manager def call_service(self, service_url: str, operation: str, payload: dict): """ 使用委托证书调用外部服务 :param service_url: 目标服务地址 :param operation: 操作类型，如 order.create :param payload: 业务参数 """ headers = { "Authorization": f"Bearer {self.certificate}", "X-Agent-ID": self.agent_id, "X-Operation": operation } response = requests.post( service_url, json=payload, headers=headers, timeout=30 ) return response def generate_attestation(self, operation: str, result: dict) -> str: """ 生成操作证明（Attestation） 使用 Agent 私钥对操作信息签名 """ private_key = self.key_manager.load_private_key(f"agent_{self.agent_id}") now = int(time.time()) payload = { "agent_id": self.agent_id, "operation": operation, "result_hash": self._hash_result(result), "timestamp": now, "certificate_jti": self._extract_jti(self.certificate) } token = jwt.encode(payload, private_key, algorithm="ES256") return token def _extract_jti(self, certificate: str) -> str: """从证书中提取 jti 字段""" unverified_payload = jwt.decode( certificate, options={"verify_signature": False} ) return unverified_payload.get("jti") def _hash_result(self, result: dict) -> str: """对操作结果做哈希，防止篡改""" import hashlib import json content = json.dumps(result, sort_keys=True).encode("utf-8") return hashlib.sha256(content).hexdigest()

Agent 客户端的核心是双重使用私钥。

第一重是“调用服务时携带委托证书”，证书本质上是用户私钥签名的授权证明。

第二重是“生成操作证明时使用 Agent 自己的私钥签名”，这一步将操作行为和 Agent 身份绑定。

为什么要双重签名？因为实际项目中，Agent 可能需要代表多个不同的用户执行操作。如果只用 Agent 私钥签名，无法区分是哪个用户授权的；如果只用用户的私钥签名，又需要 Agent 持有用户私钥，安全风险太大。所以正确的做法是：用户签发委托证书给 Agent，Agent 用私钥生成操作证明，两者相互关联、相互印证。

4.6 验证方模块

文件路径：kessa/verifier.py

import jwt import time from kessa.key_manager import KeyManager class Verifier: """第三方服务验证端""" def __init__(self, key_manager: KeyManager, service_id: str): self.key_manager = key_manager self.service_id = service_id def verify_certificate(self, token: str, required_scope: str = None) -> dict: """ 验证委托证书： 1. 验签（确认是合法签发中心签发） 2. 校验有效期 3. 校验 audience 4. 校验 scope（权限） 5. 检查撤销状态 """ public_key = self.key_manager.load_public_key("issuer") try: payload = jwt.decode( token, public_key, algorithms=["ES256"], audience=[f"kessa://service/{self.service_id}"] ) except jwt.ExpiredSignatureError: raise PermissionError("委托证书已过期") except jwt.InvalidAudienceError: raise PermissionError("该证书不允许访问当前服务") except jwt.InvalidTokenError as e: raise PermissionError(f"委托证书验签失败: {e}") # 校验 scope if required_scope: token_scopes = set(payload.get("scope", "").split()) if required_scope not in token_scopes: raise PermissionError(f"缺少权限: {required_scope}") # 检查撤销状态（伪代码） if self._is_revoked(payload.get("jti")): raise PermissionError("委托证书已被撤销") return payload def _is_revoked(self, jti: str) -> bool: """检查证书是否被撤销，实际项目可查 Redis 或数据库""" try: with open(".revoked_certificates.txt", "r", encoding="utf-8") as f: revoked_list = f.read().splitlines() return jti in revoked_list except FileNotFoundError: return False

验证方的设计要点在于“独立验证”。第三方服务不需要相信 Agent 平台，也不需要每次请求都回调用户的授权服务器。只要能拿到签发中心的公钥，就可以独立完成证书验证。这大大降低了对中心化认证服务的依赖。

4.7 撤销管理模块

任何授权系统都必须支持撤销。Kessa 的委托证书撤销通常有两种策略：

策略一：撤销列表（Revocation List）

class RevocationManager: """证书撤销管理器""" def __init__(self, state_file=".revoked_certificates.txt"): self.state_file = state_file def revoke(self, jti: str, reason: str = ""): """撤销一张证书""" with open(self.state_file, "a", encoding="utf-8") as f: f.write(f"{jti},{int(time.time())},{reason}\n") def is_revoked(self, jti: str) -> bool: """检查证书是否已撤销""" try: with open(self.state_file, "r", encoding="utf-8") as f: revoked_list = f.read().splitlines() for line in revoked_list: if line.startswith(jti + ","): return True return False except FileNotFoundError: return False

撤销列表的优点是实现简单、便于理解；缺点是验证方需要同步撤销列表，存在一定的数据同步延迟。

策略二：短有效期 + 自动续期

另一种思路是主动缩短证书有效期，比如 15 分钟。证书到期后自动重新签发。这种方式的优势是不需要维护复杂的撤销逻辑，撤销最多在十几分钟内生效；缺点是对签发中心的高可用性提出了更高要求。

生产环境通常会把两种策略结合起来：核心敏感操作使用短证书，普通操作使用长证书并配合撤销列表。

4.8 完整演示流程

文件路径：main.py

import os from kessa.key_manager import KeyManager from kessa.certificates import CertificateIssuer from kessa.agent_client import AgentClient from kessa.verifier import Verifier def setup_keys(): """初始化密钥""" km = KeyManager() if not os.path.exists(".keys/issuer.pem"): km.generate_keypair("issuer") if not os.path.exists(".keys/agent_agent-456.pem"): km.generate_keypair("agent_agent-456") return km def main(): km = setup_keys() # 用户签发委托证书给 Agent issuer = CertificateIssuer(km, issuer_id="user-123") certificate = issuer.issue_certificate( agent_id="agent-456", audience=["kessa://service/order-api"], scope=["order.create", "order.query"], ttl_seconds=3600, constraints={"max_amount": 10000} ) print("=== 委托证书签发成功 ===") print(certificate[:120] + "...\n") # Agent 使用证书调用服务 agent = AgentClient("agent-456", certificate, km) # 模拟调用订单服务 print("=== Agent 调用订单服务 ===") try: verifier = Verifier(km, service_id="order-api") payload = verifier.verify_certificate(certificate, required_scope="order.create") print(f"证书验证通过！Agent: {payload['sub']}") print(f"授权范围: {payload['scope']}") print(f"约束条件: {payload['constraints']}\n") except PermissionError as e: print(f"验证失败: {e}") return # 生成操作证明 print("=== 生成操作证明 ===") attestation = agent.generate_attestation( operation="order.create", result={"order_id": "ORD-2025-00001", "amount": 8888} ) print(f"Attestation Token: {attestation[:120]}...\n") # 验证操作证明 print("=== 验证操作证明 ===") try: agent_pub = km.load_public_key("agent_agent-456") att_payload = jwt.decode(attestation, agent_pub, algorithms=["ES256"]) print(f"证明验证通过！Agent: {att_payload['agent_id']}") print(f"操作类型: {att_payload['operation']}") print(f"时间戳: {att_payload['timestamp']}") except Exception as e: print(f"证明验证失败: {e}") if __name__ == "__main__": main()

运行结果预期如下：

=== 委托证书签发成功 === eyJhbGciOiJFUzI1NiIsImtpZCI6Imlzc3Vlci1rZXktMjAyNS0wMDEiLCJ0eXAiOiJKV1QifQ.eyJpc3MiOiJrZXNzYTovL2lzc3Vlci91c2VyLTEyMyIsInN1YiI6Imtlc3NhOi8vYWdlbnQvYWdlbnQtNDU2IiwiYXVkIjpbImtlc3NhOi8vc2VydmljZS9vcmRlci1hcGkiXSwiaWF0IjoxNzM1Njg5NjAwLCJleHAiOjE3MzU2OTMyMDAsImp0aSI6ImRlbGVnYXRpb24tMTIz... === Agent 调用订单服务 === 证书验证通过！Agent: kessa://agent/agent-456 授权范围: order.create order.query 约束条件: {'max_amount': 10000} === 生成操作证明 === Attestation Token: eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJhZ2VudF9pZCI6ImFnZW50LTQ1NiIsIm9wZXJhdGlvbiI6Im9yZGVyLmNyZWF0ZSIsInJlc3VsdF9oYXNoIjoiMTIzNDU2Nzg5MGFiY2RlZjAxMjM0NTY3ODkwYWJjZGVmIiwidGltZXN0YW1wIjoxNzM1Njg5NjAwLCJjZXJ0aWZpY2F0ZV9qdGkiOiJkZWxlZ2F0aW9uLTEyMyJ9... === 验证操作证明 === 证明验证通过！Agent: agent-456 操作类型: order.create 时间戳: 1735689600

5. 常见问题与排查思路

在实现和部署可验证委托与证明系统时，容易遇到以下几类问题。

5.1 证书验签失败

排查步骤建议按这个顺序来：

1. 确认签发方和验证方使用的是同一个issuer密钥对。
2. 对比两个 PEM 文件的指纹：openssl pkey -in issuer.pub.pem -pubout | openssl pkey -pubin -outform DER | openssl dgst -sha256。
3. 检查alg参数是否在整个链路中保持一致。
4. 查看密钥是否过期或被轮换。

5.2 证书已过期但 Agent 还在调用

这是分布式系统中常见的时钟偏移问题。Agent 所在机器的时钟和验证方所在机器的时钟不一致，导致同一个证书在一个节点上是有效的，在另一个节点上是过期的。

解决方案：

• 确保所有节点使用 NTP 时间同步。
• 验签时预留时间偏移容忍度，推荐允许 30 秒到 5 分钟的偏差。
• 生产环境建议增加nbf（Not Before）字段，防止 Agent 提前使用证书。

5.3 Audience 校验失败

很多团队在最初集成时会忽略aud字段的校验。如果外部服务在验证时没有把自己的服务 ID 加入aud，说明证书压根不是签发给当前服务的，应直接拒绝。

这里的排查重点是确认aud的匹配规则：

# 正确写法：验证方必须精确匹配自己的服务 ID payload = jwt.decode(token, public_key, audience="kessa://service/order-api") # 错误写法：忽略 audience 校验 payload = jwt.decode(token, public_key)

强烈建议生产环境显式声明aud，不要怕麻烦。

5.4 Agent 私钥泄露

这是最严重的安全事件。一旦 Agent 私钥泄露，攻击者可以冒充 Agent 生成任何操作证明，甚至可以冒用委托证书调用服务。

应对措施：

1. 第一时间吊销相关的委托证书。
2. 重新生成 Agent 密钥对，并替换所有验签端的公钥。
3. 排查泄露时间窗口内的所有操作证明，审计是否有异常操作。
4. 检查私钥存储方式，生产环境强制使用 KMS 或安全芯片。

5.5 撤销状态不一致

如果验证方缓存了撤销列表，可能出现“证书已撤销但验证方仍然放行”的窗口期。

解决方案：

• 撤销列表使用较短缓存时间（如 60 秒）。
• 或使用 Redis Pub/Sub 广播撤销事件。
• 对高风险操作，强制要求实时查询撤销状态，不做缓存。

6. 最佳实践与工程建议

6.1 密钥管理规范

密钥管理是整个系统的安全基石。无论是用户私钥还是 Agent 私钥，泄露的后果都很严重。

生产环境建议遵循以下原则：

• 私钥不出信任边界：私钥只存在于 KMS、HSM 或安全隔离区，业务代码只调用签名接口，拿不到私钥内容。
• 公钥统一管理：通过公钥服务（Public Key Service）分发公钥，支持kid标识和轮换机制。
• 定期轮换：签发中心私钥建议每 90 天轮换一次，Agent 密钥建议每 180 天轮换一次。
• 访问控制：只有授权人员可以执行证书签发、撤销、密钥轮换等管理操作。

6.2 证书设计建议

委托证书不是越大越好。字段过多会导致 JWT 体积膨胀，影响请求效率；字段过少又可能导致审计信息不足。推荐的做法是：

• 证书中只保存验证和授权所必需的结构化字段。
• 复杂的业务上下文放在constraints中，但不建议放太大数据。
• 所有可枚举取值使用统一枚举格式，如order.create、order.query，便于策略引擎匹配。
• 为证书添加版本号或模式标识，方便未来升级兼容。

6.3 审计日志与证明保留

操作证明（Attestation）的价值在于审计追溯，所以保留策略非常重要。

• 全量保存：所有 Agent 操作证明都需要归档保存，不能只保存成功操作。
• 加密存储：证明文件建议加密落盘，至少保证存储介质丢失后数据不泄露。
• 时间戳服务：关键操作证明可以接入权威时间戳服务，增强法律效力。
• 定期审计：每周或每月对证明记录做抽样审计，确保证明生成的链路没有被人为绕过。

6.4 与现有系统的集成策略

Kessa 这类系统通常不会独立存在，需要和企业已有的身份认证体系、API 网关、权限中心集成。

推荐集成路径：

1. 先在外部 API 网关层接验证逻辑，对调用 Agent 的外部请求做统一验证。
2. 再逐步把内部服务接入，通过 SDK 或 Sidecar 完成验签。
3. 最后集成审计平台，将操作证明推送到统一日志中心或 SIEM。
4. 接入监控告警，对验签失败率、证书撤销率、证明生成失败率设置告警阈值。

6.5 性能优化建议

验证委托证书涉及非对称签名验证，在高频调用场景下需要考虑性能优化。

常用优化手段：

• 公钥缓存：验证方的公钥可以缓存在内存中，避免每次请求都读文件。
• 批量验签：对于同一批请求，可以合并验签过程。
• 降低 JWT 体积：删除不必要的字段，减少网络传输。
• 异步撤销检查：签名验证走同步，撤销检查可以异步化，降低延迟。
• 结果缓存：对于无状态、幂等的操作，可以缓存验证结果，减少重复计算。

6.6 安全边界事项

使用 Kessa 或类似系统时，有几个安全边界问题必须提前想清楚：

1. 委托不等于无条件信任：即使 Agent 持有了有效委托证书，也要在业务逻辑里二次校验操作的合法性。证书说“允许调用”，业务逻辑说“是否允许这笔具体操作”，两者独立。
2. 证明不等于免责：操作证明只能证明“Agent 执行了操作”，不能证明“操作结果对人类是正确且无害的”。对高影响操作，建议引入人工审批或多 Agent 交叉验证。
3. 用户撤销权优先：任何时候用户都应能立即撤销对 Agent 的委托授权，且撤销操作不能依赖 Agent 自身、不能依赖 Agent 所在平台。建议提供独立的撤销入口。
4. 最小权限原则：委托证书的scope和constraints要尽量收紧。比如授权“查询订单”就不要给“创建订单”的权限；允许访问生产环境就不要额外授权测试环境。

7. 从 Kessa 到 AI Agent 安全体系

7.1 Kessa 的定位与优势

回到项目本身，Kessa 的“Show HN”发布之所以引起关注，在于它切中了一个真实存在且不断放大的需求：AI Agent 需要一种可验证、可追溯、可撤销的授权与证明机制。

相比传统 API Key 或 OAuth2 Token，Kessa 提供了几个关键升级：

• 可验证：证书携带结构化信息，第三方可以独立验证，不需回源查询。
• 可委托：支持用户 -> Agent、Agent -> Agent 的多级委托关系。
• 可证明：Agent 的每次操作都可以生成独立的签名证明，用于审计和追溯。
• 可撤销：证书有生命周期，支持主动撤销和过期机制。

7.2 未来的扩展方向

Kessa 这类系统还有很多可以演进的方向：

多级委托与信任传递。目前的委托链只有一层。在复杂的 Agent 协作场景中，可能需要支持多级委托：用户委托给主 Agent，主 Agent 再委托给子 Agent。每一级委托都要有独立的签名和权限收敛。

条件委托与动态策略。证书中的constraints目前是静态的。未来可以结合策略引擎，实现动态条件判断，例如“只有金额小于 5000 元且用户在线的场景下，委托才生效”。

与 Agent 行为审计联动。将操作证明和 Agent 运行日志、决策过程日志结合起来，形成完整的“行为审计链”。这样不仅能回答“Agent 做了什么”，还能回答“Agent 为什么这样做”。

标准化与互操作。如果不同 Agent 平台使用不同的委托与证明格式，跨平台协作就会受阻。跟随 W3C Verifiable Credentials 和 Decentralized Identifiers 标准的演进，会是重要的方向。

7.3 给开发者的学习建议

如果你刚接触这个方向，建议按这样的路径循序渐进：

1. 先掌握非对称加密、数字签名的基本原理，理解私钥签名、公钥验签的关系。
2. 熟悉 JWT 的标准结构（Header、Payload、Signature）以及常见算法（ES256、RS256、EdDSA）。
3. 阅读 W3C 关于可验证凭证（VC）和去中心化标识符（DID）的规范，理解行业通用模型。
4. 动手实现一个简化版委托与证明系统，把本文的核心流程跑通。
5. 在真实项目中接入策略引擎，尝试用 OPA（Open Policy Agent）或类似工具做动态权限判断。
6. 关注 AI Agent 安全的最新实践，包括提示词注入防护、工具调用审计、权限隔离等方向。

在这个基础上，无论是直接用 Kessa 还是自研同类系统，你都会有一个清晰的技术地图。

8. 总结

AI Agent 的能力越强，对它进行约束的需求就越强。Kessa 提供了一套可验证委托与证明系统的参考实现，核心思路可以概括为“用户签名授权、Agent 持证调用、服务独立验证、操作签名留痕”。

本文从概念、原理到工程实现，完整拆解了这套系统的关键环节：

• 委托证书的签发，解决“ Agent 凭什么可以操作”的问题。
• 第三方独立验证，解决“外部服务凭什么相信 Agent”的问题。
• 操作证明的生成，解决“Agent 做过什么、如何追溯”的问题。
• 撤销与约束机制，解决“授权过期或被收回后如何生效”的问题。

这套方案并不是银弹。它不替代业务逻辑层的权限判断，不替代对 Agent 行为的持续监控，也不替代组织层面的安全治理规范。它提供的，是一条可以验证、可以追溯的信任链路。

如果你想在真实项目里落地 AI Agent 的授权与审计能力，不妨先按本文的思路搭建一个最小可运行的验证系统，跑通证书签发、调用验证、操作证明、撤销管理这几个核心流程。等把信任链路的基本功练扎实了，再去处理复杂的业务策略和多级委托，就会从容很多。