AWS与Keyfactor发布基于X.509 PKI的AI智能体身份认证参考架构
该参考架构面向多智能体与MCP工具调用场景，用签名信封、用户签名委托声明、RFC 8693限定受众令牌和实时OCSP吊销检查四类机制，验证调用方身份、请求新鲜度和授权链；方案由AWS与Keyfactor工程团队合作开发。
AI解读：AWS Machine Learning博客发布了一套与Keyfactor合作开发的参考架构，用X.509公钥基础设施为AI智能体建立密码学身份，解决“哪个智能体发起了请求、能否防止智能体之间伪造、智能体是否只代表已授权用户行事”三个问题。
架构针对MCP（Model Context Protocol）没有内置认证标准这一缺口。方案用四类机制覆盖三层信任边界：签名信封提供持有证明，用户签名的委托声明让智能体无需持有用户凭据即可获得授权，RFC 8693受众限定令牌限制单个令牌泄露的影响范围，OCSP实时吊销检查让凭据变更立即传播。
实现依赖Keyfactor EJBCA企业版签发X.509证书并提供OCSP响应，配合Amazon Bedrock（经Strands Agents SDK调用模型）、Amazon RDS for MySQL、Amazon SES、AWS Secrets Manager和托管Keycloak与EJBCA的Amazon EC2。来源称完整示例代码已放在GitHub仓库。
来源列出使用前提：需Keycloak 26.2或更高版本（RFC 8693标准令牌交换所需）、配置REST API V1和OCSP响应器的EJBCA Enterprise、用于REST认证的EJBCA API管理员证书，以及Python 3.9+环境。
来源称私钥在客户端本地生成，只把CSR提交给EJBCA签发，私钥不发送给EJBCA也不在智能体之间共享；登出时按顺序吊销用户证书、吊销三个智能体证书、强制删除Secrets Manager中的密钥并终止Keycloak会话。
来源未提供该架构在生产环境的效果数据或性能指标，所述安全性质均为该参考架构的设计目标。
AWS Machine Learning博客发布了一套由AWS与Keyfactor工程团队合作开发的参考架构，用X.509公钥基础设施（PKI）为AI智能体建立密码学身份。方案针对多智能体框架通过MCP（Model Context Protocol）连接外部工具时缺少内置认证标准的问题，组合使用签名请求信封、用户签名委托声明、RFC 8693受众限定令牌和实时OCSP吊销检查。
来源将问题描述为三点：证明是哪个智能体发起了请求、防止智能体之间伪造、确认每个智能体只代表已授权用户行事。来源认为在组件间共享API密钥或沿智能体链传递OAuth令牌，无法满足企业部署所需的零信任要求。
四类机制如何分工
来源把认证分为三层信任边界，四类机制分布其中。第一层是用户到系统：用户通过Keycloak完成OAuth 2.0登录，随后用RFC 8693令牌交换获得一个受众限定为MCP服务器的降权令牌，该令牌才交给智能体。
第二层是智能体到智能体：编排智能体把工具名、参数、时间戳和随机nonce一起用RSA-PSS-SHA256签名，接收方校验签名、时间戳新鲜度（默认60秒内）、nonce唯一性、CA链、角色和OCSP吊销状态共六项。
第三层是智能体到MCP工具服务器：服务器对每次工具调用做四项检查，包括令牌内省确认受众包含“mcp-server”、验证签名信封、校验用户委托声明，以及交叉核对令牌用户名、委托主体和智能体证书CN前缀是否一致。
- 签名信封：每次调用都附带持有证明，失败即拒绝
- 委托声明：JSON文档列出三个智能体证书的SHA-256指纹及用户主体名、签发时间和过期时间，由用户私钥签名
- 受众限定令牌：只被MCP服务器接受，即使泄露也不能访问其他服务
- OCSP实时检查：每次请求都查询吊销状态，来源称吊销一张用户证书即可使下游全部智能体授权失效
密钥管理与吊销流程
来源强调私钥在应用本地生成：应用生成RSA 2048位以上密钥对，构造只含公钥和主体信息的CSR，通过EJBCA的pkcs10enroll REST接口签发证书，证书有效期设为7天，随后把证书与本地私钥打包为PKCS12存入AWS Secrets Manager。来源称EJBCA不接触也不存储私钥。
登出会触发吊销级联：先在EJBCA吊销用户证书，使所有未到期的委托声明失效；再吊销三个智能体证书，使所有签名信封失效；然后用ForceDeleteWithoutRecovery立即删除Secrets Manager中的密钥；最后终止Keycloak会话，使降权令牌失效。
- 用户私钥只在登录流程中用于签署委托声明，不交给智能体
- 每个智能体的私钥只由该智能体自己使用
- 来源称所有校验失败均直接拒绝，OCSP不可达时同样拒绝
使用前提与适用范围
来源列出复现该架构的条件：需要Keycloak 26.2或更高版本（更早版本使用不兼容的旧版令牌交换）、配置REST API V1和OCSP响应器的Keyfactor EJBCA Enterprise、用于REST API认证的EJBCA API管理员证书，以及Python 3.9+开发环境；使用者需熟悉X.509证书、OCSP、OAuth 2.0、RSA数字签名和PKCS#12密钥库。
AWS侧涉及Amazon Bedrock（经Strands Agents SDK做模型推理）、Amazon RDS for MySQL（被MCP工具访问的应用数据库）、Amazon SES（邮件智能体发信）、AWS Secrets Manager和托管Keycloak与EJBCA的Amazon EC2。来源说明参考架构以数据库作为受保护资源，同一认证模式适用于任何兼容MCP的工具服务器。
来源称Keyfactor的平台被全球超过1500家企业客户使用，该数字由Keyfactor提供。
- 参考架构由AWS与Keyfactor工程团队联合开发
- 完整示例源代码在配套GitHub仓库中
- 来源未公布该架构在生产环境的运行效果或性能数据