AWS published a tutorial on October 20, 2026, describing an X.509-based reference design for AI-agent identity. It combines agent certificates, signed requests, user delegation, audience-restricted tokens and certificate-revocation checks. The Model Context Protocol (MCP) separately defines optional OAuth-based authorization for HTTP transports, which addresses a different layer of access control.
What X.509 identity adds
An X.509 certificate binds an agent identity to a public key, which can be used to verify that the agent signed a request. In AWS's example, that identity sits within three trust boundaries: user to system, agent to agent, and agent to MCP server.
MCP's optional authorization mechanism covers HTTP transports. It does not provide the example's certificate-backed agent identity, signed agent-to-agent requests or user delegation. The MCP authorization specification advises STDIO implementations to obtain credentials from the environment rather than use that HTTP authorization mechanism.
| Mechanism | Scope | What it controls | Transport or boundary |
| MCP OAuth authorization | Optional authorization for HTTP-based MCP transports | Access to an MCP resource using OAuth-based authorization | HTTP transport |
| AWS's X.509 example | Agent identity and requests across the reference design | Certificates, signed requests, user delegation and certificate-status checks | User-to-system, agent-to-agent and agent-to-server boundaries |
How the example checks an agent request
The example starts with a user's OAuth 2.0 sign-in through Keycloak. An RFC 8693 token exchange then narrows the token's audience to the MCP server; agents do not receive the full-session token.
The application generates an RSA key pair locally, with a key size of 2048 bits or larger, and sends a certificate signing request to EJBCA Enterprise. The private key stays within the application boundary and is not sent to EJBCA or shared among agents. The example stores the resulting certificate and key together as PKCS#12 material in AWS Secrets Manager.
The user signs a delegation assertion that identifies the agent certificates by their SHA-256 fingerprints and records the user's identity, issuance time and expiry. When an agent sends a request to another agent, it signs the payload, tool name, arguments, timestamp and nonce using RSA-PSS-SHA256.
At the MCP server, the example checks the token's audience and status, the signed request envelope, the delegation assertion and the user certificate. It also checks that the username in the token, the delegation subject and the agent certificate name agree. Envelope validation includes the signature, timestamp freshness, nonce uniqueness, certificate-authority chain and role permissions.
Replay protection and certificate revocation
Each signed envelope includes a random 128-bit nonce and a timestamp. The default maximum envelope age is 60 seconds, and the in-memory replay cache retains a nonce for twice that configured limit, or 120 seconds with the default. A retry needs a new envelope and nonce. The example certificate profile has a seven-day validity period.
AWS's design checks certificate status through the Online Certificate Status Protocol (OCSP) on each request and fails closed if the responder cannot be reached. Its described logout sequence revokes the user and agent certificates, deletes their Secrets Manager secrets without a recovery window, and ends the Keycloak session.
AWS identifies a distributed replay cache backed by Amazon ElastiCache, a highly available OCSP responder, hardware security modules for signing keys, OCSP stapling and tenant-specific certificate authorities as possible extensions. The tutorial also separates agent-to-agent authentication through PKI from authorization to AWS services through IAM roles.
Requirements and the sample's scope
The example requires Keycloak 26.2 or later for standard RFC 8693 token exchange, Python 3.9 or later, and EJBCA Enterprise with REST API V1 and an OCSP responder. It also calls for AWS access to Amazon Bedrock, Amazon RDS for MySQL, Amazon SES and AWS Secrets Manager, plus an EJBCA API administrator certificate. The architecture uses Amazon Bedrock with the AWS Strands Agents SDK, Keycloak, EJBCA Enterprise, FastMCP and Amazon RDS for MySQL.
The AWS Samples repository describes the project as a learning and development demonstration that needs additional security hardening and review before production use. Its scripted setup runs Keycloak and EJBCA locally in Docker and provisions AWS resources, including an RDS database. The README also notes that SES sandbox mode can send email only to verified recipients.
