多 Agent 的 X.509 身份链：证明谁调用、代表谁、能调用什么
2026 年 10 月 20 日，AWS 与 Keyfactor 发布多 Agent X.509 PKI 参考架构。它组合四个机制：每次 Agent 调用使用签名请求信封提供持钥证明；用户签署委托声明而不共享登录凭证；通过 RFC 8693 换取 audience-scoped token；每次关键调用查询 OCSP 以实时传播撤销。
MCP 本身是传输无关协议，没有内建统一认证。只在网关放一个 API key，无法证明是哪一个子 Agent 发起请求，也无法证明它是否仍代表当前用户。多 Agent 链越长，共享 bearer token 的重放和权限扩散风险越大。
身份链要同时回答工作负载身份、用户委托、目标受众与凭证是否仍有效。
签名信封绑定每一次调用
信封包含调用方证书指纹、目标 audience、请求体摘要、nonce、时间戳和运行 ID，再用 Agent 私钥签名：
envelope = {
"iss": agent_id,
"aud": "mcp://finance/read-ledger",
"run_id": run_id,
"body_sha256": sha256(body).hexdigest(),
"nonce": secrets.token_urlsafe(24),
"iat": int(time.time()),
"exp": int(time.time()) + 60,
}
signature = private_key.sign(canonical_json(envelope), padding.PSS(...), hashes.SHA256())
服务端验证证书链、签名、audience、时间窗、body hash，并原子记录 nonce 防重放。Canonical JSON 的字段顺序和编码必须固定，否则不同语言实现会产生不可验证签名。
用户委托不能等于转发用户 token
用户登录后签发 delegation assertion，声明“用户 U 允许 Agent A 在任务 R 中调用范围 S，有效 5 分钟”。子 Agent B 需要新的委托或受限的 delegation chain，不能直接拿到用户 OAuth token。
{
"sub": "user:42",
"delegate": "agent:invoice-checker",
"run": "run-91a",
"scope": ["invoice:read"],
"max_chain_depth": 2,
"exp": 1792477800
}
链深限制可以防止代理无限再委托。最终 MCP Server 同时验证用户、Agent 与资源策略，并把三者写入审计事件。
RFC 8693 将 token 限定给一个目标
Agent 向身份服务提交 delegation 与自己的持钥证明，交换只面向特定 MCP Server 的短期 token。即使 token 泄漏，也不能用于另一个工具；同时通过 cnf 或 mTLS 将 token 绑定到证书，降低纯 bearer 重放。
subject_token = user_delegation
actor_token = agent_certificate_assertion
audience = mcp://finance/read-ledger
scope = invoice:read
Token TTL 应短于任务检查点间隔。长任务恢复后重新交换，并再次验证用户与 Agent 是否仍有效。
OCSP 解决等待期撤销
Agent 会暂停数小时等待审批。只看证书到期时间，已失陷或已下线 Agent 仍可能继续调用。OCSP 在关键调用时查询证书状态；网关对正常响应做短缓存，对 revoked 立即阻断。必须明确 OCSP 不可用时 fail-open 还是 fail-closed，高风险写操作通常应 fail-closed。
证书私钥保存在 Secrets Manager、HSM 或工作负载受保护存储中，不进入 Prompt、日志或 Agent 文件系统。自动签发与轮换要保留 overlap 窗口，但同一身份同时有效的证书数量受限。
企业落地先做威胁测试
测试截获信封重放、修改 body、替换 audience、复制父 Agent token 给子 Agent、撤销证书后继续调用、时钟偏差和 OCSP 故障。验证日志能拼出用户 → 父 Agent → 子 Agent → MCP 工具的完整链，并能对任一节点单独撤销。
PKI 不能决定业务动作是否合理，它解决的是“谁在说话且凭证仍有效”。结合策略引擎、沙箱与评测后，多 Agent 平台才同时具备密码学身份和业务授权。