The gap between “an agent called this tool” and “this agent, acting for this person, was allowed to call this tool” is where most agent security programmes stall. On 20 October 2026, AWS published a reference architecture that closes it with public-key infrastructure rather than shared secrets.
What happened
The AWS Machine Learning Blog post, “Securing AI agent identity with X.509 PKI on AWS,” describes a joint reference architecture built with machine-identity vendor Keyfactor and its EJBCA certificate authority. It is a worked design with source code, not a managed AWS service: the pieces are wired together on Amazon Bedrock, the AWS Strands Agents SDK, Amazon RDS for MySQL, Secrets Manager, SES and EC2.
The stated problem is the one practitioners keep hitting. Agents call each other and call tools over the Model Context Protocol (MCP), and MCP — in AWS’s words — “has no built-in authentication standard” and is transport-agnostic by design. Passing API keys between components or forwarding OAuth tokens down an agent chain does not establish who the caller is, whether the request is fresh, or whether the original user ever authorized this particular hop.
The architecture answers with three authentication layers — user to system, agent to agent, and agent to MCP tool server — built from four mechanisms:
- Signed request envelopes. Every agent call carries a signature over the request with a nonce and timestamp, giving proof-of-possession and replay resistance rather than a bearer secret that anyone who intercepts it can reuse.
- User-signed delegation assertions. The human authorizes an agent by signing a delegation statement, so the agent never receives the user’s credential. The authorization chain is explicit and can be inspected at each hop.
- RFC 8693 audience-scoped tokens. Token exchange narrows a token to a specific audience, so a token disclosed at one tool server cannot be replayed against another.
- Real-time OCSP revocation. Certificate status is checked against the CA on each use, so revoking an agent takes effect immediately across every agent and tool server rather than waiting for a CRL to propagate.
The post walks through certificate issuance at login, agent enrollment, delegation minting, tool invocation and session cleanup, with a database as the protected resource — though the authors note the same pattern applies to any MCP-compatible tool server. Complete example code is published in an accompanying GitHub repository.
Why it matters for KYA
This is the most concrete public answer yet to the question KYA exists to ask: who is this agent, and who is accountable for what it just did?
- Identity moves from configuration to cryptography. An API key in an environment variable identifies a deployment, not an agent instance; it cannot be scoped per task, cannot be proven fresh, and cannot be revoked without breaking every other component that shares it. A short-lived certificate bound to a key pair can do all three. That is the difference between a name and an identity.
- Delegation becomes a signed artifact. The delegation assertion is the technical form of the mandate that KYA keeps insisting on: a record of which principal authorized which agent, for what, and until when. Because the user signs it, the agent’s authority is provable after the fact — not reconstructed from logs.
- Revocation is designed in, not bolted on. Real-time OCSP turns “we can cut the agent off” from a runbook entry into a property of every request. A verification you cannot withdraw at machine speed is theatre.
- It names the MCP authentication gap in public. MCP’s transport-agnostic design left authentication to implementers, and implementers mostly reached for shared secrets. An AWS reference architecture that treats MCP tool servers as relying parties gives platform teams a pattern to copy instead of inventing one.
There are limits worth stating plainly. This is a reference architecture, not a supported AWS product with an SLA; the certificate authority in the design is Keyfactor’s commercial EJBCA Enterprise, so the PKI operations — enrolment, availability, OCSP scaling — become your responsibility or your vendor’s contract. The post also assumes an OAuth-capable identity provider and a reasonably mature secrets and compute estate. Smaller deployments may find the operational overhead heavier than the risk they are carrying.
The useful test for a buyer or architect is narrow: take one agent-to-tool call in your estate and try to produce (a) a cryptographic identifier for the calling agent, (b) a signed statement of who delegated to it, and (c) a revocation path that takes effect on the next request. If any of the three is missing, this blueprint is a reasonable place to start.
Sources
- AWS Machine Learning Blog, “Securing AI agent identity with X.509 PKI on AWS”, 20 October 2026, by Deepakkumar Sharma, Alex Ament and JD Kilgallin — aws.amazon.com.
- IETF RFC 8693, OAuth 2.0 Token Exchange — the audience-scoped token mechanism used in the design — rfc-editor.org.
- Keyfactor, EJBCA Enterprise product documentation — the certificate authority in the reference architecture — keyfactor.com.
Note: the architecture, component list and the “MCP has no built-in authentication standard” characterization are as stated by AWS in the 20 October post. This is a vendor reference design, not an independent evaluation or a compliance certification.
Know Your Agent (KYA) explains agent identity, verification and accountability. This is an explainer, not legal or compliance advice — see our Sources & methodology. New to KYA? Start with What is Know Your Agent? and the glossary.