Securing AI agent identity with X.509 PKI on AWS

When AI agents access databases, APIs, and sensitive business operations, establishing cryptographic identity through X.509 public key infrastructure (PKI) becomes a critical requirement. The core challenge is proving which agent made a request, preventing forgery between agents, and confirming that each agent acts only on behalf of an authorized user. Traditional approaches such as sharing API keys between components or passing OAuth tokens through agent chains fall short of the zero-trust requirements that enterprise deployments demand. Multi-agent AI frameworks increasingly use the Model Context Protocol (MCP) to connect agents to external tools and data sources. MCP defines how a large language model (LLM)-powered agent invokes tools such as database queries or email operations. However, MCP has no built-in authentication standard. It is transport-agnostic by design. This creates a critical gap: Without proper identity mechanisms, any component could impersonate an agent, replay intercepted credentials, or invoke tools without authorization. In this post, we show you how to address this gap using Keyfactor EJBCA combined with AWS services. EJBCA is a PKI platform that supports high-availability deployment, REST API automation, and Online Certificate Status Protocol (OCSP) validation. The reference architecture uses four complementary security mechanisms. First, signed request envelopes provide cryptographic proof-of-possession on every agent call. Second, user-signed delegation assertions authorize agents without sharing credentials. Third, RFC 8693 audience-scoped tokens limit the scope of exposure from any single token disclosure. Fourth, real-time OCSP revocation checking propagates credential changes immediately across all agents. The solution uses Amazon Bedrock for LLM inference through the AWS Strands Agents SDK . While this reference architecture uses a database as the protected resource, the same authentication pattern applies to any MCP-compatible tool server. Complete source code for all examples is available in the accompanying GitHub repository. About Keyfactor EJBCA Keyfactor provides a widely adopted machine identity management platform used by more than 1,500 enterprise customers worldwide, according to Keyfactor. These organizations span financial services, healthcare, manufacturing, and government. Keyfactor helps organizations establish and maintain cryptographic trust through certificate lifecycle management, PKI operations, and machine identity governance. EJBCA Enterprise is Keyfactor’s Certificate Authority (CA) and PKI platform, designed for high-availability deployment and REST API automation. Available as an enterprise product, EJBCA provides X.509 certificate issuance, OCSP validation, certificate revocation list (CRL) distribution, and full certificate lifecycle management through both a web console and REST API. EJBCA supports deployment on-premises, in containers, or on Amazon Elastic Compute Cloud (Amazon EC2). The partnership between AWS and Keyfactor brings together AWS managed services (Amazon Bedrock, AWS Secrets Manager, Amazon Relational Database Service (Amazon RDS)) with PKI infrastructure that supports certificate lifecycle management, automated enrollment, and real-time revocation. This combination addresses a gap in the AI agent ecosystem. While AWS provides the compute, storage, and AI inference layers, Keyfactor provides the cryptographic identity layer that binds agents to verifiable, revocable, short-lived credentials. This joint reference architecture, developed collaboratively by the AWS and Keyfactor engineering teams, demonstrates how to integrate these technologies. You can adapt the patterns shown here to your own multi-agent deployments. Solution overview The architecture implements three authentication layers, each addressing a different trust boundary in the agent communication chain. These three layers use the four security mechanisms introduced earlier: signed envelopes for proof-of-possession, delegation assertions for credential-free authorization, audience-scoped tokens for exposure limitation, and OCSP for real-time revocation. The mechanisms combine across layers as shown in the following table. Layer Trust boundary Mechanism Validates 1. User Auth User to System OAuth + X.509 cert + delegation minting User identity, credential binding 2. Agent-to-Agent Agent to Agent Signed envelopes (PoP + nonce + timestamp) Caller identity, request freshness, no replay 3. MCP Auth Agent to Tool Server Scoped token + envelope + delegation All identities, authorization chain, OCSP Figure 1 shows the three authentication layers and how credentials flow between the user, agents, and the MCP tool server. The diagram illustrates the separation between user credentials (which stay in the login flow), agent credentials (scoped per agent), and the delegation chain that connects them. Figure 1: Three-layer PKI authentication architecture for AI agent systems on AWS Figure 2 illustrates the detailed traffic flow during a typical user session. It shows the sequence of authentication steps from login through certificate issuance, agent delegation, tool invocation, and session cleanup. Figure 2: Authentication traffic flow from user login through agent delegation, tool invocation, and session cleanup AWS services used The following AWS services form the foundation of the reference architecture. Service Purpose Amazon Bedrock LLM inference through Strands Agents SDK Amazon RDS for MySQL Application database accessed through MCP tools Amazon Simple Email Service (Amazon SES) Email delivery for the Email Agent AWS Secrets Manager Secure storage for PKCS12 bundles, tokens, and metadata Amazon EC2 Hosts Keycloak IDP and EJBCA PKI server Solution walkthrough The following steps walk through each component of the architecture, from initial user login through to session cleanup. Each step builds on the previous one, establishing a chain of trust that connects the human user to the final tool execution. Prerequisites An active AWS account with access to Amazon Bedrock, Amazon RDS for MySQL, Amazon SES, and AWS Secrets Manager. Keycloak 26.2 or later (required for RFC 8693 standard token exchange. Previous versions use a legacy exchange that is incompatible). Keyfactor EJBCA Enterprise with REST API V1 and an OCSP responder configured. EJBCA API administrator certificate ( api-admin.p12 ) for REST API authentication. Python 3.9+ development environment. Familiarity with X.509 certificates, OCSP, OAuth 2.0, RSA digital signatures, and PKCS#12 key stores. Step 1: User login, certificate issuance, and delegation minting The login flow establishes the user’s identity through three mechanisms and then delegates authority to the AI agents without sharing the user’s credentials. This separation is critical: Agents receive proof of authorization without ever holding the user’s private key or full-session OAuth token. First, the application authenticates the user against Keycloak using an OAuth 2.0 password grant, receiving a full-session access token and refresh token. Immediately after, the application performs an RFC 8693 token exchange to obtain a downscoped token. This token’s audience is restricted to the MCP server. Only this limited token is handed to agents. If it’s inadvertently exposed, it can’t access any other service in the organization. Second, the application generates an RSA 2048+ key pair locally and submits a Certificate Signing Request (CSR) to EJBCA through the pkcs10enroll REST API endpoint. EJBCA signs the CSR and returns the certificate. The application bundles the certificate and private key into a PKCS12 container and stores it in AWS Secrets Manager. The private key never leaves the application boundary. It is not sent to EJBCA, not shared with agents, and not stored on the filesystem. Three agent certificates are issued using the same CSR-based flow, one per agent role. Third, the user’s private key si