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 什么是 KessaKessa 是一个面向 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 / WindowsWSL2 编程语言Python 3.9 或 Node.js 18 加密库 - Python: cryptography / PyJWT / python-jose - Node.js: jsonwebtoken / jose 密钥格式PEM / JWK 数据存储SQLite本地实验、PostgreSQL生产推荐2.2 核心模块划分一个完整的可验证委托与证明系统从模块上可以拆分为以下几块模块职责关键能力身份签发中心Issuer为 Agent 签发委托凭证生成密钥对、签发委托证书、记录证书状态Agent 客户端Holder持有并使用委托凭证存储私钥、签名请求、生成操作证明验证方Verifier验证委托证书与证明验签、校对有效期、检查撤销状态证明服务Attestation Service生成可审计的操作证明结构化日志、哈希链、时间戳、签名策略引擎Policy Engine判断委托是否允许某个具体操作权限匹配、条件判断、风险控制2.3 技术选型思考在实现这类系统时有几个技术选型需要提前想清楚密钥管理。Agent 的私钥不能明文放在代码里更不能提交到 Git。生产环境建议使用 KMS如 AWS KMS、Azure Key Vault、HashiCorp Vault托管密钥Agent 运行时只通过 API 调用签名操作。本地实验可以用配置文件但必须放在环境变量或独立的密钥文件中。凭证格式。目前业界常用的可验证凭证格式包括 JWT-VC、JSON-LD VC、CWTCBOR 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 基于委托证书执行一个操作后系统会生成一个证明对象内容包括操作 IDOperation IDAgent 身份标识委托证书 ID操作类型与入参摘要执行时间与时间戳执行结果摘要系统签名这听起来像日志但实际上比普通日志多了几层保障签名保障证明对象由 Agent 私钥签名无法伪造。关联保障证明对象引用了委托证书 ID审计时可以回溯授权来源。完整性保障操作入参和执行结果摘要做哈希处理防止事后篡改。可验证性第三方拿到证明对象后可以独立验证其真实性不需要信任 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] } }字段含义说明字段含义iss签发者标识通常是用户或授权平台sub委托对象标识即 Agent 的身份 IDaud允许调用的目标服务列表iat / exp签发时间和过期时间jti证书唯一 ID用于撤销管理和审计scope授权的操作范围类似 OAuth2 的 scopedelegation_chain委托链记录授权路径constraints额外约束条件如金额上限、时间段、IP 白名单在实际项目中证书字段需要根据业务场景做扩展。比如金融场景会增加“单笔限额”“日累计限额”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.py4.2 环境准备与依赖创建requirements.txtcryptography41.0.0 PyJWT2.8.0 pyyaml6.0安装依赖pip install -r requirements.txt注意cryptography库用于生成密钥对和签名操作PyJWT库用于生成和解析 JWT 格式的委托证书。4.3 密钥管理模块文件路径kessa/key_manager.pyfrom 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_okTrue) 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( encodingserialization.Encoding.PEM, formatserialization.PrivateFormat.PKCS8, encryption_algorithmserialization.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( encodingserialization.Encoding.PEM, formatserialization.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(), passwordNone) 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.pyimport 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: fkessa://issuer/{self.issuer_id}, sub: fkessa://agent/{agent_id}, aud: audience, iat: now, exp: now ttl_seconds, jti: fdelegation-{uuid.uuid4()}, scope: .join(scope), delegation_chain: [ { from: fkessa://issuer/{self.issuer_id}, to: fkessa://agent/{agent_id}, delegated_at: now } ], constraints: constraints or {} } token jwt.encode(payload, private_key, algorithmES256, headersheader) # 记录证书状态实际项目建议写入数据库 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, encodingutf-8) as f: f.write(state)签发证书时有两个细节值得注意一是aud字段。这个字段指定了证书可以调用的目标服务列表。验签时验证方必须检查aud是否包含自己否则即使是合法签发的证书也不能接受。二是jti字段。jti是证书的唯一 ID。撤销管理和审计追溯都需要依赖这个字段所以签发时必须生成并持久化。4.5 Agent 客户端模块文件路径kessa/agent_client.pyimport 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: fBearer {self.certificate}, X-Agent-ID: self.agent_id, X-Operation: operation } response requests.post( service_url, jsonpayload, headersheaders, timeout30 ) return response def generate_attestation(self, operation: str, result: dict) - str: 生成操作证明Attestation 使用 Agent 私钥对操作信息签名 private_key self.key_manager.load_private_key(fagent_{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, algorithmES256) 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_keysTrue).encode(utf-8) return hashlib.sha256(content).hexdigest()Agent 客户端的核心是双重使用私钥。第一重是“调用服务时携带委托证书”证书本质上是用户私钥签名的授权证明。第二重是“生成操作证明时使用 Agent 自己的私钥签名”这一步将操作行为和 Agent 身份绑定。为什么要双重签名因为实际项目中Agent 可能需要代表多个不同的用户执行操作。如果只用 Agent 私钥签名无法区分是哪个用户授权的如果只用用户的私钥签名又需要 Agent 持有用户私钥安全风险太大。所以正确的做法是用户签发委托证书给 AgentAgent 用私钥生成操作证明两者相互关联、相互印证。4.6 验证方模块文件路径kessa/verifier.pyimport 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[fkessa://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, encodingutf-8) as f: revoked_list f.read().splitlines() return jti in revoked_list except FileNotFoundError: return False验证方的设计要点在于“独立验证”。第三方服务不需要相信 Agent 平台也不需要每次请求都回调用户的授权服务器。只要能拿到签发中心的公钥就可以独立完成证书验证。这大大降低了对中心化认证服务的依赖。4.7 撤销管理模块任何授权系统都必须支持撤销。Kessa 的委托证书撤销通常有两种策略策略一撤销列表Revocation Listclass 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, encodingutf-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, encodingutf-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.pyimport 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_iduser-123) certificate issuer.issue_certificate( agent_idagent-456, audience[kessa://service/order-api], scope[order.create, order.query], ttl_seconds3600, constraints{max_amount: 10000} ) print( 委托证书签发成功 ) print(certificate[:120] ...\n) # Agent 使用证书调用服务 agent AgentClient(agent-456, certificate, km) # 模拟调用订单服务 print( Agent 调用订单服务 ) try: verifier Verifier(km, service_idorder-api) payload verifier.verify_certificate(certificate, required_scopeorder.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( operationorder.create, result{order_id: ORD-2025-00001, amount: 8888} ) print(fAttestation 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 时间戳: 17356896005. 常见问题与排查思路在实现和部署可验证委托与证明系统时容易遇到以下几类问题。5.1 证书验签失败问题现象常见原因解决思路JWT Decode 报 InvalidSignature验证方使用了错误的公钥检查kid字段确认加载的是签发中心当前使用的公钥公钥不匹配签发中心和验证方的密钥对不一致重新分发公钥建议通过公钥服务动态获取算法不匹配签发时用 RS256验证时指定 ES256统一算法建议全链路使用 ES256排查步骤建议按这个顺序来确认签发方和验证方使用的是同一个issuer密钥对。对比两个 PEM 文件的指纹openssl pkey -in issuer.pub.pem -pubout | openssl pkey -pubin -outform DER | openssl dgst -sha256。检查alg参数是否在整个链路中保持一致。查看密钥是否过期或被轮换。5.2 证书已过期但 Agent 还在调用这是分布式系统中常见的时钟偏移问题。Agent 所在机器的时钟和验证方所在机器的时钟不一致导致同一个证书在一个节点上是有效的在另一个节点上是过期的。解决方案确保所有节点使用 NTP 时间同步。验签时预留时间偏移容忍度推荐允许 30 秒到 5 分钟的偏差。生产环境建议增加nbfNot Before字段防止 Agent 提前使用证书。5.3 Audience 校验失败很多团队在最初集成时会忽略aud字段的校验。如果外部服务在验证时没有把自己的服务 ID 加入aud说明证书压根不是签发给当前服务的应直接拒绝。这里的排查重点是确认aud的匹配规则# 正确写法验证方必须精确匹配自己的服务 ID payload jwt.decode(token, public_key, audiencekessa://service/order-api) # 错误写法忽略 audience 校验 payload jwt.decode(token, public_key)强烈建议生产环境显式声明aud不要怕麻烦。5.4 Agent 私钥泄露这是最严重的安全事件。一旦 Agent 私钥泄露攻击者可以冒充 Agent 生成任何操作证明甚至可以冒用委托证书调用服务。应对措施第一时间吊销相关的委托证书。重新生成 Agent 密钥对并替换所有验签端的公钥。排查泄露时间窗口内的所有操作证明审计是否有异常操作。检查私钥存储方式生产环境强制使用 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 网关、权限中心集成。推荐集成路径先在外部 API 网关层接验证逻辑对调用 Agent 的外部请求做统一验证。再逐步把内部服务接入通过 SDK 或 Sidecar 完成验签。最后集成审计平台将操作证明推送到统一日志中心或 SIEM。接入监控告警对验签失败率、证书撤销率、证明生成失败率设置告警阈值。6.5 性能优化建议验证委托证书涉及非对称签名验证在高频调用场景下需要考虑性能优化。常用优化手段公钥缓存验证方的公钥可以缓存在内存中避免每次请求都读文件。批量验签对于同一批请求可以合并验签过程。降低 JWT 体积删除不必要的字段减少网络传输。异步撤销检查签名验证走同步撤销检查可以异步化降低延迟。结果缓存对于无状态、幂等的操作可以缓存验证结果减少重复计算。6.6 安全边界事项使用 Kessa 或类似系统时有几个安全边界问题必须提前想清楚委托不等于无条件信任即使 Agent 持有了有效委托证书也要在业务逻辑里二次校验操作的合法性。证书说“允许调用”业务逻辑说“是否允许这笔具体操作”两者独立。证明不等于免责操作证明只能证明“Agent 执行了操作”不能证明“操作结果对人类是正确且无害的”。对高影响操作建议引入人工审批或多 Agent 交叉验证。用户撤销权优先任何时候用户都应能立即撤销对 Agent 的委托授权且撤销操作不能依赖 Agent 自身、不能依赖 Agent 所在平台。建议提供独立的撤销入口。最小权限原则委托证书的scope和constraints要尽量收紧。比如授权“查询订单”就不要给“创建订单”的权限允许访问生产环境就不要额外授权测试环境。7. 从 Kessa 到 AI Agent 安全体系7.1 Kessa 的定位与优势回到项目本身Kessa 的“Show HN”发布之所以引起关注在于它切中了一个真实存在且不断放大的需求AI Agent 需要一种可验证、可追溯、可撤销的授权与证明机制。相比传统 API Key 或 OAuth2 TokenKessa 提供了几个关键升级可验证证书携带结构化信息第三方可以独立验证不需回源查询。可委托支持用户 - 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 给开发者的学习建议如果你刚接触这个方向建议按这样的路径循序渐进先掌握非对称加密、数字签名的基本原理理解私钥签名、公钥验签的关系。熟悉 JWT 的标准结构Header、Payload、Signature以及常见算法ES256、RS256、EdDSA。阅读 W3C 关于可验证凭证VC和去中心化标识符DID的规范理解行业通用模型。动手实现一个简化版委托与证明系统把本文的核心流程跑通。在真实项目中接入策略引擎尝试用 OPAOpen Policy Agent或类似工具做动态权限判断。关注 AI Agent 安全的最新实践包括提示词注入防护、工具调用审计、权限隔离等方向。在这个基础上无论是直接用 Kessa 还是自研同类系统你都会有一个清晰的技术地图。8. 总结AI Agent 的能力越强对它进行约束的需求就越强。Kessa 提供了一套可验证委托与证明系统的参考实现核心思路可以概括为“用户签名授权、Agent 持证调用、服务独立验证、操作签名留痕”。本文从概念、原理到工程实现完整拆解了这套系统的关键环节委托证书的签发解决“ Agent 凭什么可以操作”的问题。第三方独立验证解决“外部服务凭什么相信 Agent”的问题。操作证明的生成解决“Agent 做过什么、如何追溯”的问题。撤销与约束机制解决“授权过期或被收回后如何生效”的问题。这套方案并不是银弹。它不替代业务逻辑层的权限判断不替代对 Agent 行为的持续监控也不替代组织层面的安全治理规范。它提供的是一条可以验证、可以追溯的信任链路。如果你想在真实项目里落地 AI Agent 的授权与审计能力不妨先按本文的思路搭建一个最小可运行的验证系统跑通证书签发、调用验证、操作证明、撤销管理这几个核心流程。等把信任链路的基本功练扎实了再去处理复杂的业务策略和多级委托就会从容很多。