AWS gives AI agents X.509 PKI identities: a three-layer auth architecture

AWS ML Blog · rss · 2026-10-21

The problem: agents have no identity layer

When AI agents hit databases, APIs, and sensitive operations, you need cryptographic identity to prove which agent made a request, prevent inter-agent forgery, and confirm each agent acts for an authorized user. Shared API keys and pass-through OAuth tokens fail zero-trust requirements; MCP has no built-in authentication standard, exposing deployments to impersonation, replay, and unauthorized tool calls.

Solution: EJBCA PKI + AWS, four mechanisms in three layers

A joint AWS–Keyfactor reference architecture (EJBCA enterprise CA, 1,500+ enterprise customers) combines:

Signed request envelopes: cryptographic proof-of-possession (PoP + nonce + timestamp) on every agent call, preventing replay;
User-signed delegation assertions: authorize agents without sharing credentials;
RFC 8693 audience-scoped tokens: limits exposure from any single token disclosure;
Real-time OCSP revocation: credential changes propagate instantly across all agents.

Three auth layers map to three trust boundaries: user auth (OAuth + X.509 + delegation minting), agent-to-agent (signed envelopes), and MCP auth (scoped token + envelope + delegation + OCSP).

Key implementation details

After login, the app performs an RFC 8693 token exchange for a downscoped, MCP-audience-only token before handing it to agents. RSA 2048+ key pairs are generated locally; CSRs go to EJBCA, and the private key never leaves the application boundary, is never shared with agents, and is stored in Secrets Manager. Stack: Bedrock + Strands Agents SDK, RDS MySQL, SES, Keycloak 26.2+ (RFC 8693 token exchange required; older versions incompatible), EJBCA Enterprise. Full source is on GitHub; the pattern applies to any MCP-compatible tool server.

Original post →

AWS gives AI agents X.509 PKI identities: a three-layer auth architecture

More from coding & agent