AWS publishes a blueprint for AI agents to prove identity before using tools

AWS published a reference architecture on October 20 that requires AI agents to prove both who they are and whose authority they carry before accessing connected tools. Developed with Keyfactor, the blueprint uses digital certificates and signed requests rather than simply passing a user’s credentials through an agent chain, with example source code available.

Delegating authority without handing over the keys

The design addresses three separate checkpoints: a person signing in, one agent calling another, and an agent invoking a tool. It combines AWS services with Keyfactor’s EJBCA certificate platform. X.509 public key infrastructure, or PKI, supplies digital certificates that connect an identity to a cryptographic key.

The distinction starts at login. The application authenticates the user through Keycloak, an identity service, and exchanges the resulting access token for one restricted to the MCP tool server. Model Context Protocol, or MCP, connects agents to external tools and data. Agents receive the restricted token, not the user’s full-session token or private key.

A separate signed document supplies the delegation. The user’s private key signs a list of the authorized agents’ certificate fingerprints—digital identifiers—along with the user’s name and the delegation’s issuance and expiry times. Each agent carries that document as evidence of permission. This binds authorization to specific agent certificates, rather than merely asserting that an agent represents someone.

A certificate alone does not clear the request

When the coordinating agent calls a specialist agent, it signs the requested tool name, arguments, timestamp and a random, single-use value called a nonce. This signed package proves possession of the private key associated with the caller’s certificate. Presenting a certificate by itself is not enough.

The receiving agent checks the signature, certificate trust chain, permitted caller role and whether the certificate has been revoked. It also checks freshness: the default window is 60 seconds, and previously seen nonces are rejected. Even a legitimate sender retrying after a temporary failure must create a fresh signed package.

At the database boundary, the MCP server checks the token, signed request and user delegation before executing a tool. It also requires the token’s username, the delegation’s subject and the user-identifying portion of the agent certificate to match. That final comparison ties the credentials to one consistent user identity, rather than accepting individually valid but mismatched pieces.

An implementation pattern, with infrastructure attached

Revocation is another live dependency. The design uses Online Certificate Status Protocol, or OCSP, to ask EJBCA whether certificates remain valid. Those checks cover agent certificates and the user certificate behind a delegation. Authority is therefore checked during requests, not treated as valid solely because a certificate was issued earlier.

The example runs model inference through Amazon Bedrock and the Strands Agents SDK. It uses RDS for MySQL as the protected database, SES for email, Secrets Manager for credential storage, and EC2 to host Keycloak and EJBCA. AWS says the authentication pattern can also be adapted to other MCP-compatible tool servers.

Adopting the sample requires more than an agent SDK. Its prerequisites include EJBCA Enterprise with an OCSP responder, an administrator certificate and Keycloak 26.2 or later; AWS warns that older Keycloak token exchange is incompatible. The walkthrough links to an accompanying GitHub repository containing the example source code for teams implementing the design.