用 X.509 PKI 在 AWS 上确立 AI 智能体身份

#用 X.509 PKI 在 AWS 上确立 AI 智能体身份

当 AI 智能体访问数据库、API 和敏感业务操作时，通过 X.509 公钥基础设施（public key infrastructure，PKI）建立密码学身份成为一项关键要求。核心挑战是证明哪一个智能体发出了请求、防止智能体之间伪造，并确认每个智能体只代表已授权用户行事。在组件之间共享 API 密钥，或沿着智能体链路传递 OAuth 令牌，都达不到企业部署所要求的零信任（zero-trust）。

多智能体 AI 框架越来越多地使用模型上下文协议（Model Context Protocol，MCP），把智能体连接到外部工具和数据源。MCP 定义大语言模型（large language model，LLM）驱动的智能体如何调用数据库查询或邮件操作等工具。然而，MCP 没有内置的认证标准。它在设计上与传输无关。这造成一个关键缺口：如果没有适当的身份机制，任何组件都可能冒充智能体、重放截获的凭据，或在未经授权时调用工具。

本文说明如何用 Keyfactor EJBCA 结合 AWS 服务来弥补这一缺口。EJBCA 是一套 PKI 平台，支持高可用部署、REST API 自动化，以及在线证书状态协议（Online Certificate Status Protocol，OCSP）校验。该参考架构使用四种互补的安全机制。第一，签名请求信封在每一次智能体调用上提供密码学持有证明（proof-of-possession）。第二，由用户签名的委托断言在不共享凭据的情况下授权智能体。第三，RFC 8693 受众受限令牌把单次令牌泄露的影响范围限制住。第四，实时 OCSP 吊销检查把凭据变更立即传播到所有智能体。

该方案通过 AWS Strands Agents SDK 使用 Amazon Bedrock 做 LLM 推理。虽然这一参考架构把数据库作为受保护资源，同一套认证模式适用于任何兼容 MCP 的工具服务器。全部示例的完整源代码见随附的 GitHub 仓库。

关于 Keyfactor EJBCA

Keyfactor 提供一套被广泛采用的机器身份管理平台。据 Keyfactor 称，全球有 1,500 多家企业客户在使用。这些组织覆盖金融服务、医疗、制造和政府。Keyfactor 帮助组织通过证书生命周期管理、PKI 运营和机器身份治理来建立并维持密码学信任。

EJBCA Enterprise 是 Keyfactor 的证书颁发机构（Certificate Authority，CA）和 PKI 平台，面向高可用部署和 REST API 自动化而设计。作为企业产品，EJBCA 通过 Web 控制台和 REST API 提供 X.509 证书签发、OCSP 校验、证书吊销列表（certificate revocation list，CRL）分发，以及完整的证书生命周期管理。EJBCA 支持在本地、容器中，或在 Amazon Elastic Compute Cloud（Amazon EC2）上部署。

AWS 与 Keyfactor 的合作把 AWS 托管服务（Amazon Bedrock、AWS Secrets Manager、Amazon Relational Database Service（Amazon RDS））与支持证书生命周期管理、自动注册和实时吊销的 PKI 基础设施结合起来。这一组合针对的是 AI 智能体生态中的一处缺口。AWS 提供计算、存储和 AI 推理层，Keyfactor 提供密码学身份层，把智能体绑定到可验证、可吊销、短寿命的凭据上。这一由 AWS 与 Keyfactor 工程团队协作开发的联合参考架构，演示如何集成这些技术。你可以把这里展示的模式改用到自己的多智能体部署中。

方案概览

该架构实现三层认证，每一层对应智能体通信链路中的一条不同信任边界。这三层使用前面介绍的四种安全机制：用于持有证明的签名信封、用于无凭据授权的委托断言、用于限制暴露面的受众受限令牌，以及用于实时吊销的 OCSP。各机制如何跨层组合如下表所示。

图 1 展示三层认证，以及凭据如何在用户、智能体和 MCP 工具服务器之间流动。该图说明用户凭据（留在登录流程中）、智能体凭据（按智能体限定范围）以及把它们连接起来的委托链之间的分离。

图 1：AWS 上 AI 智能体系统的三层 PKI 认证架构

图 2 展示一次典型用户会话中的详细流量。它给出从登录到证书签发、智能体委托、工具调用和会话清理的认证步骤顺序。

图 2：从用户登录到智能体委托、工具调用和会话清理的认证流量

使用的 AWS 服务

下列 AWS 服务构成该参考架构的基础。

方案演练

下列步骤走完架构的每个组件，从最初的用户登录一直到会话清理。每一步都建立在上一步之上，形成一条把人类用户连接到最终工具执行的信任链。

前提条件

• 一个可使用 Amazon Bedrock、Amazon RDS for MySQL、Amazon SES 和 AWS Secrets Manager 的有效 AWS 账户。
• Keycloak 26.2 或更高版本（RFC 8693 标准令牌交换所必需。更早版本使用不兼容的旧式交换）。
• 已配置 REST API V1 和 OCSP 响应器的 Keyfactor EJBCA Enterprise。
• 用于 REST API 认证的 EJBCA API 管理员证书（api-admin.p12）。
• Python 3.9+ 开发环境。
• 熟悉 X.509 证书、OCSP、OAuth 2.0、RSA 数字签名和 PKCS#12 密钥库。

步骤 1：用户登录、证书签发与委托铸造

登录流程通过三种机制确立用户身份，然后在不共享用户凭据的情况下把权限委托给 AI 智能体。这种分离很关键：智能体收到授权证明，但从不持有用户的私钥或完整会话 OAuth 令牌。

首先，应用使用 OAuth 2.0 密码授权模式对照 Keycloak 认证用户，收到完整会话访问令牌和刷新令牌。紧接着，应用执行 RFC 8693 令牌交换，取得一个缩小范围的令牌。该令牌的受众被限制为 MCP 服务器。只有这个受限令牌会交给智能体。即使它被意外暴露，也不能访问组织中的任何其他服务。

其次，应用在本地生成 RSA 2048 位及以上的密钥对，并通过 pkcs10enroll REST API 端点向 EJBCA 提交证书签名请求（Certificate Signing Request，CSR）。EJBCA 签署该 CSR 并返回证书。应用把证书和私钥打包进 PKCS12 容器，并存入 AWS Secrets Manager。私钥从不离开应用边界。它不会发给 EJBCA，不会与智能体共享，也不会存放在文件系统上。三个智能体证书使用同一套基于 CSR 的流程签发，每个智能体角色一张。

第三，用户的私钥签署一份委托断言。这是一份 JSON 文档，列出全部三张智能体证书的 SHA-256 指纹，以及用户的主体名、签发时间和到期时间。这份委托证明用户授权这些特定智能体代表自己行事。智能体携带的是这份委托，而不是用户证书。

# RFC 8693 Token Exchange - downscope to MCP audience
downscoped_token = keycloak.token_exchange(
    original_token, audience="mysql-mcp-server", scope="database:write"
)
# Client-side key generation (user key never leaves this flow)
private_key = rsa.generate_private_key(public_exponent=65537, key_size=2048)
csr = build_csr(private_key, f"CN={username},E={username}@org.com")
user_cert = ejbca.pkcs10enroll(csr, ca_name="UserCA")
# User signs delegation over agent cert fingerprints
delegation = mint_delegation(
    username=username,
    user_cert_pem=user_cert,
    user_key_pem=private_key_pem,
    agent_cert_pems=[orch_cert, mysql_cert, email_cert]
)
# Result: {sub, agent_fingerprints[], iat, exp, user_cert_pem, signature_b64}

步骤 2：智能体之间的签名信封

当编排智能体把请求路由到子智能体（例如 MySQL 智能体或邮件智能体）时，它并不只是把自己的证书传过去作标识。相反，它使用私钥，以 RSA-PSS-SHA256 对整个请求载荷签名，载荷包括工具名、参数、时间戳和密码学随机数（nonce）。得到的签名信封提供持有证明。接收方智能体可以验证调用方确实持有与所出示证书对应的私钥。

接收方智能体在处理请求之前，对信封做六项校验：

1. 签名验证：证明发送方持有私钥（持有证明）。
2. 时间戳新鲜度：信封必须落在当前时间的 ENVELOPE_MAX_AGE_SECONDS（默认 60 秒）之内。
3. 随机数唯一性：ReplayCache 拒绝任何曾经见过的随机数，从而防止请求重放。
4. CA 链校验：发送方证书必须链接到受信任 CA（UserCA.pem）。
5. 角色授权：证书 CN 的角色后缀必须位于该智能体的 ALLOWED_CALLER_ROLES 之中。
6. OCSP 吊销检查：对照 EJBCA 做实时检查，确认证书尚未被吊销。

如果编排智能体需要重新发送同一条提示（例如在短暂失败之后），它必须用新的随机数创建新信封。旧信封不能被重放，即使重放者是合法发送方也不行。

# Orchestrator signs request to sub-agent
envelope = sign_envelope(
    payload={"tool": "query_database", "args": {"sql": "SELECT ..."}},
    cert_pem=orchestrator_cert_pem,
    private_key_pem=orchestrator_key_pem
)
# envelope: {payload_b64, cert_pem, timestamp, nonce, signature_b64, alg}
# Sub-agent verifies (six checks)
verified_payload = verify_envelope(
    envelope,
    allowed_role="orchestrator-agent",
    ca_cert_pem=ca_pem,
    replay_cache=cache
)

步骤 3：MCP 服务器认证

MCP 服务器（FastMCP）是任何数据库操作运行之前的最后一道信任边界。它对每一次工具调用执行四项校验，实现纵深防御。即使一份凭据遭到未授权访问，其余检查仍能阻止未授权操作。

认证顺序如下：

1. 令牌内省：向 Keycloak 的 /token/introspect 端点发送 POST，验证令牌处于活动状态，且其受众包含 “mcp-server”。没有正确受众的完整会话令牌会被拒绝。
2. 信封验证：校验智能体签名信封的签名正确性、时间戳新鲜度、随机数唯一性、CA 链信任、角色匹配（mysql-agent）以及 OCSP 未吊销。
3. 委托验证：校验用户的委托断言。签名证明持有用户密钥的人授权了这份委托，调用方智能体的证书指纹出现在授权列表中，并且通过 OCSP 检查用户证书。
4. 身份交叉核对：令牌用户名、委托主体和智能体证书 CN 前缀必须全部一致。这确认从用户一直到工具执行是一条单一、一致的身份链。

# MCP Server - Four validation checks
# 1. Token: must be active with correct audience
info = introspect(token)
assert info["active"] and "mcp-server" in info["aud"]
# 2. Envelope: proof-of-possession + freshness + replay + CA + role + OCSP
payload = verify_envelope(envelope, "mysql-agent", ca_pem, replay_cache)
# 3. Delegation: user authorized this agent + user cert not revoked
claims = verify_delegation(delegation, agent_cert_pem, ca_pem)
# 4. Cross-check: consistent identity chain
assert token_username == claims["sub"] == agent_cn.rsplit("_", 1)[0]
# All checks passed - execute tool
result = execute_sql(payload["args"]["sql"])

步骤 4：重放防护

每个签名信封携带一个唯一随机数，即用 Python secrets 模块生成的 128 位密码学随机十六进制字符串。ReplayCache 是一个线程安全的内存存储，记住每一个随机数，直到其新鲜度窗口过期（ENVELOPE_MAX_AGE_SECONDS 的 2 倍）。如果同一个随机数出现在第二次请求中，信封会立即被拒绝，即使签名有效且时间戳仍然新鲜。

时间戳校验与随机数检查互补。信封的时间戳必须落在服务器当前时间的 ENVELOPE_MAX_AGE_SECONDS（默认 60 秒）之内。二者合在一起应对四种未授权访问情形：

• 录制重放：未授权用户捕获一份有效信封并稍后重新提交。该随机数已经被见过。
• 延迟送达：在传输中被截获的信封在新鲜度窗口之后才到达。时间戳检查失败。
• 陈旧请求复用：被代理缓存的旧信封被重新提交。随机数和时间戳检查都会失败。
• 预计算伪造：未授权用户无法预测未来的随机数，因而不能预先签署信封。

步骤 5：客户端密钥生成

该架构的一项关键安全属性是：私钥在本地生成，并且从不传输到任何外部系统。应用使用 Python cryptography 库生成 RSA 2048 位及以上的密钥对。它构造一份只含公钥和主体信息的 CSR，并且只把 CSR 通过 pkcs10enroll 端点发给 EJBCA。

EJBCA 校验 CSR，套用证书配置文件（7 天有效期、密钥用法约束），用 CA 密钥签名，并返回已签发的证书。应用随后把本地持有的私钥与返回的证书打包进 PKCS12 容器，并存入 AWS Secrets Manager。

这一设计提供若干安全属性：

• 用户私钥只在登录时用于签署委托断言。它从不与智能体共享。
• 每个智能体的私钥只由该智能体用来签署信封。它从不在智能体之间共享。
• EJBCA 从不看到或存储私钥。它纯粹作为证书颁发机构运作。
• 如果 Secrets Manager 遭到未授权访问，单独存放的 PKCS12 密码再增加一层防护。
• 密钥材料可以在下次登录时用新的 CSR 重新注册，从而独立轮换。

步骤 6：完整登出与凭据吊销

登出触发一次吊销级联，立即使所有尚未失效的凭据失效。该顺序完成后，不再留下任何有效凭据：

1. 在 EJBCA 中吊销用户证书：这会立即使所有尚未失效的委托失效，因为委托验证会通过 OCSP 实时检查用户证书。
2. 吊销全部三张智能体证书：这会使所有尚未失效的签名信封失效，因为信封验证包含 OCSP。
3. 从 AWS Secrets Manager 删除全部密钥：使用 ForceDeleteWithoutRecovery，立即删除且没有恢复窗口。
4. 终止 Keycloak 会话：通过会话终止端点使缩小范围的令牌失效。

吊销级联是关键安全属性。在 PKI 层吊销一张用户证书，就会及时撤销全部下游智能体权限，而不需要逐个吊销令牌、删除会话或联系每一个智能体。OCSP 提供传播机制；因为每一次请求都检查 OCSP，效果是即时的。

安全考量

该架构中的设计选择针对的是生产级多智能体部署所重视的若干安全属性。

私钥隔离。用户私钥只在登录流程中存在，并且只用于签署委托。智能体密钥按智能体限定范围，并且从不共享。没有任何密钥材料跨越信任边界。

委托相对于凭据共享。智能体通过一条密码学链条（委托到智能体指纹再到信封签名）证明自己的权限，而从不持有用户凭据。如果某个智能体密钥暴露，被暴露的只是该智能体的密钥，而不是用户的密钥。

受众受限令牌。RFC 8693 令牌交换产生的令牌只被 MCP 服务器接受。意外泄露的缩小范围令牌不能用来认证 Keycloak 管理 API、其他服务，甚至另一个 MCP 服务器实例。

重放防护。逐请求随机数与 60 秒新鲜度窗口的组合确认每一条请求都是一次性且有时间界限的。ReplayCache 是线程安全且会自行清理的。

失败即关闭。每一次校验失败都会立即拒绝。OCSP 不可达：拒绝。签名无效：拒绝。时间戳过期：拒绝。随机数被重放：拒绝。受众错误：拒绝。安全检查没有优雅降级。

吊销级联。吊销一张用户证书会及时使全部委托、全部智能体权限和全部尚未失效的信封失效。这通过实时 OCSP 传播，不要求逐份凭据清理。

只向前的信任链。ALLOWED_CALLER_ROLES 映射强制只有 orchestrator-agent 可以调用 mysql-agent 和 email-agent。子智能体不能互相调用，不能向上调用编排智能体，也不能冒充用户。

AI 治理考量

该 PKI 架构为这一系统中的 AI 智能体提供内置的行为边界。生产部署应使用 Amazon Bedrock Guardrails，在本文所述基于 PKI 的访问控制之外，对智能体响应强制执行内容过滤、话题规避和依据检查。

• 工具边界：AI 智能体在严格的工具约束下运行。它只能调用预先定义的 MCP 工具（execute_sql、describe_table、list_tables）。智能体不能执行任意代码，也不能访问其证书范围之外的资源。
• 人工监督：所有智能体动作都被记录并可审计。AWS CloudTrail 捕获 AWS API 调用，MCP 服务器记录每一次已通过校验的工具调用，并带上完整身份链（用户、智能体、时间戳和操作）。
• 数据处理：用户查询和结果留在已认证的会话边界之内。受众受限令牌把数据访问限制在特定的 MCP 服务器实例上。
• 基于证书的行为边界：智能体只能调用自己持有有效证书的工具。没有 mysql-agent 证书的智能体不能访问数据库，无论 LLM 可能生成什么样的指令。

扩展该架构

你可以把该架构扩展到更多智能体类型、水平扩展和多租户隔离。下面几段说明最常见的扩展点。

• 要增加新的智能体类型，只需要在 ALLOWED_CALLER_ROLES 中增加一项。证书会在登录时自动签发，委托断言会动态包含新智能体的指纹。不需要改动基础设施。
• 对于水平扩展，可以把 EJBCA 的 OCSP 响应器以高可用模式部署在负载均衡器之后。AWS Secrets Manager 支持适合这一工作负载的高请求速率。ReplayCache 可以在分布式部署中改由 Amazon ElastiCache 支撑。
• 要把架构加固到生产环境，可以通过 AWS CloudHSM 或本地硬件安全模块（hardware security module，HSM）使用由 HSM 支撑的 EJBCA 签名密钥。OCSP 响应装订（stapling）降低校验延迟，证书透明度（Certificate Transparency）日志提供已签发证书的完整审计轨迹。
• 对于多租户部署，可以按租户创建证书颁发机构，或按租户创建委托机构，以实现密码学上的租户隔离。再结合按租户划分的 AWS 账户，就能在租户之间提供强隔离。
• 你也可以用 AWS Identity and Access Management（IAM）角色来补充基于 PKI 的智能体身份。用 PKI 做智能体之间的认证，用 IAM 做 AWS 服务授权。两套系统独立工作，从而提供纵深防御。

清理

为避免持续产生费用，删除本次演练中创建的资源：

• 删除 Amazon RDS for MySQL 实例（如果使用了脚本化搭建，则删除 AWS CloudFormation 堆栈）。
• 从 AWS Secrets Manager 删除全部密钥，包括 mcp/ 前缀下的用户证书和智能体证书。
• 从 Amazon SES 移除已验证的发件人电子邮件地址。
• 终止运行 Keycloak 和 EJBCA 的 Amazon EC2 实例（如果是为本次演示而部署的）。
• 使用 EJBCA 管理控制台或 REST API，吊销并删除 EJBCA 中的全部测试证书。
• 移除 Keycloak 领域（mcp-realm）及相关客户端。
• 如果使用了脚本化搭建，运行 ./scripts/cleanup.sh（Linux）或 ./scripts/cleanup.bat（Windows）来自动完成这些步骤。

结论

本文演示了一种参考架构：使用 Keyfactor EJBCA 与 AWS 服务，用 X.509 PKI 保护 AI 智能体通信。该架构通过四种互补机制，应对多智能体 AI 系统中的根本身份缺口：

• 签名请求信封在每一次智能体间调用上提供密码学持有证明，使未授权方更难伪造某个智能体的身份或重放其请求。
• 由用户签名的委托断言把授权与凭据共享解耦。智能体证明自己被授权代表用户行事，而不持有用户的私钥或完整会话令牌。
• RFC 8693 受众受限令牌把任何令牌泄露的影响范围限制在单一服务边界之内。
• 实时 OCSP 吊销检查确认凭据吊销会立即在整个系统中生效。吊销一张用户证书就会及时终止全部下游智能体权限。

该架构与框架无关。虽然本文用 AWS Strands Agents SDK 和 FastMCP 做了演示，同样的 PKI 模式适用于 LangChain、CrewAI、AutoGen，或任何使用工具协议的其他多智能体框架。随着 AI 智能体增多并获得对越来越敏感的操作的访问，智能体身份基础设施从可选项变成必需项。

要开始使用这一参考架构，请参见随附的 GitHub 仓库：https://github.com/aws-samples/sample-Securing-AI-agent-identity-with-X-509-PKI-on-AWS

PRIMARY_SOURCE: https://aws.amazon.com/blogs/machine-learning/securing-ai-agent-identity-with-x-509-pki-on-aws