AWS 与 Keyfactor EJBCA 如何用 X.509 PKI 保障 AI 智能体身份安全

当 AI 智能体访问数据库、API 和敏感业务操作时，通过 X.509 公钥基础设施(PKI)建立加密身份成为一项关键需求。核心挑战在于证明请求由哪个智能体发起、防止智能体之间的伪造，并确认每个智能体仅代表已授权的用户执行操作。传统方法(如在组件之间共享 API 密钥或通过智能体链传递 OAuth 令牌)无法满足企业部署所要求的零信任需求。

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

在本文中，我们将向您展示如何结合使用 Keyfactor EJBCA 和 AWS 服务来弥补这一缺口。EJBCA 是一个 PKI 平台，支持高可用性部署、REST API 自动化和在线证书状态协议(OCSP)验证。该参考架构使用四种互补的安全机制。第一，签名请求信封为每次智能体调用提供加密式的持有证明。第二，用户签名的委托断言在不共享凭证的情况下对智能体进行授权。第三，符合 RFC 8693 的受众限定令牌限制了任何单个令牌泄露造成的暴露范围。第四，实时 OCSP 吊销检查可将凭证变更立即传播到所有智能体。

该解决方案通过 AWS Strands Agents SDK 使用 Amazon Bedrock 进行 LLM 推理。虽然此参考架构使用数据库作为受保护资源，但相同的身份验证模式适用于任何兼容 MCP 的工具服务器。所有示例的完整源代码都可在随附的 GitHub 存储库中获取。

关于 Keyfactor EJBCA

据 Keyfactor 称，Keyfactor 提供的机器身份管理平台已被全球 1,500 多家企业客户广泛采用。这些组织遍及金融服务、医疗保健、制造业和政府领域。Keyfactor 通过证书生命周期管理、PKI 运营和机器身份治理，帮助组织建立并维护加密信任。

EJBCA Enterprise 是 Keyfactor 的证书颁发机构(CA)和 PKI 平台，专为高可用性部署和 REST API 自动化而设计。EJBCA 作为企业级产品提供，可通过 Web 控制台和 REST API 提供 X.509 证书签发、OCSP 验证、证书吊销列表(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 服务构成了该参考架构的基础。

解决方案演练

以下步骤逐步讲解架构的各个组件，从初始用户登录到会话清理。每一步都在前一步的基础上构建，建立起一条将人类用户连接到最终工具执行的信任链。

先决条件

• 一个处于活动状态的 AWS 账户，可访问 Amazon Bedrock、Amazon RDS for MySQL、Amazon SES 和 AWS Secrets Manager。
• 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 提交证书签名请求（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 智能体或 Email 智能体）时，它并不是简单地出示自己的证书来表明身份，而是使用自己的私钥结合 RSA-PSS-SHA256，对整个请求负载进行签名，包括工具名称、参数、时间戳和一个密码学随机 nonce。生成的签名信封提供了持有证明。接收方智能体可以验证调用者确实持有与所出示证书对应的私钥。

接收方智能体在处理请求之前会对信封执行六项验证检查：

1. 签名验证：证明发送方持有私钥（持有证明）。
2. 时间戳新鲜度：信封的时间戳必须与当前时间相差在 ENVELOPE_MAX_AGE_SECONDS（默认 60 秒）以内。
3. Nonce 唯一性：ReplayCache 会拒绝任何之前出现过的 nonce，防止请求重放。
4. CA 链验证：发送方的证书必须能够链接到受信任的 CA（UserCA.pem）。
5. 角色授权：证书 CN 中的角色后缀必须在该智能体的 ALLOWED_CALLER_ROLES 中。
6. OCSP 吊销检查：对 EJBCA 进行实时检查，确认证书未被吊销。

如果编排智能体需要重新发送相同的提示（例如在瞬时故障之后），它必须使用全新的 nonce 创建一个新的信封。旧信封无法被重放，即使是合法的发送方也不行。

# 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. 令牌内省（Token introspection）：通过向 Keycloak 的 /token/introspect 端点发送 POST 请求，验证令牌处于活跃状态且其受众（audience）包含“mcp-server”。缺少正确受众的完整会话令牌将被拒绝。
2. 信封验证：对智能体的签名信封进行验证，包括签名正确性、时间戳新鲜度、nonce 唯一性、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：重放防护

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

时间戳验证是对 nonce 检查的补充。信封的时间戳必须与服务器当前时间相差在 ENVELOPE_MAX_AGE_SECONDS（默认 60 秒）以内。这些机制共同应对四种未授权访问场景：

• 录制重放：未授权用户捕获一个有效信封并在之后重新提交。该 nonce 已被记录过。
• 延迟送达：传输途中被拦截的信封在新鲜度窗口之后才到达。时间戳检查失败。
• 过期请求复用：被代理缓存的一个旧信封被重新提交。nonce 和时间戳检查均失败。
• 预计算伪造：未授权用户无法预测未来的 nonce 来预先签署信封。

步骤 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 服务器实例进行身份验证。

重放防护。每请求 nonce 与 60 秒新鲜度窗口的组合确保每个请求都是一次性的且有时间限制。ReplayCache 是线程安全且自动清理的。

默认拒绝设计。任何验证失败都会立即导致拒绝。OCSP 不可达：拒绝。签名无效：拒绝。时间戳过期：拒绝。nonce 重放：拒绝。受众错误：拒绝。安全检查不存在优雅降级。

吊销级联。吊销一个用户证书即可迅速失效所有委托、所有智能体权限和所有未完成的信封。这通过实时 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 或本地 HSM 使用由硬件安全模块（HSM）支撑的 EJBCA 签名密钥。OCSP 响应装订（stapling）可降低验证延迟，证书透明度（Certificate Transparency）日志提供已签发证书的完整审计轨迹。
• 对于多租户部署，你可以创建按租户的证书颁发机构或按租户的委托机构，以实现加密层面的租户隔离。结合按租户的 AWS 账户，这可以在租户之间提供强隔离。
• 你还可以将基于 PKI 的智能体身份与 AWS Identity and Access Management (IAM) 角色结合使用。使用 PKI 进行智能体之间的身份验证，使用 IAM 进行 AWS 服务授权。这两个系统独立工作，提供纵深防御。

清理

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

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

结论

在这篇文章中，我们演示了一种使用 X.509 PKI 与 Keyfactor EJBCA 及 AWS 服务来保护 AI 智能体通信的参考架构。该架构通过四个互补机制解决了多智能体 AI 系统中的根本性身份缺口：

• 签名的请求信封在每次智能体间调用时提供加密的持有证明，使未授权方伪造智能体身份或重放其请求的难度大大增加。
• 用户签名的委托断言将授权与凭证共享解耦。智能体可以证明自己有权代表用户执行操作，而无需持有用户的私钥或完整会话令牌。
• RFC 8693 受众范围限定的令牌将任何令牌泄露的暴露范围限制在单一服务边界内。
• 实时 OCSP 吊销检查可确认凭证吊销在整个系统中立即生效。吊销一个用户证书即可迅速终止所有下游智能体的权限。

此架构与框架无关。虽然我们使用 AWS Strands Agents SDK 和 FastMCP 进行了演示，但同样的 PKI 模式适用于 LangChain、CrewAI、AutoGen 或任何其他使用工具协议的多智能体框架。随着 AI 智能体的大量涌现并获得对日益敏感的操作的访问权限，智能体身份基础设施正从可选项变为必需品。

要开始使用此参考架构，请参阅配套的 GitHub 存储库。有关所用服务的更多信息，请参阅以下资源：

• Amazon Bedrock
• Amazon Bedrock 用户指南
• Keyfactor EJBCA Enterprise
• MCP 规范
• AWS Strands Agents SDK
• 推出开源 AI 智能体 SDK Strands Agents（AWS 开源博客文章）

关于作者