Agents· Important· 🧪 Worth Testing

AWS and Keyfactor show how to lock down multi-agent identity using certificates instead of shared tokens

In short: AWS and Keyfactor published a reference design that fixes a known weak point in Model Context Protocol (MCP) deployments: MCP has no built-in way to authenticate which agent is actually making a request. The architecture adds three trust layers — user-to-system, agent-to-agent, and agent-to-tool-server — built on signed request envelopes, delegation assertions signed by the user, RFC 8693 audience-restricted tokens, and live OCSP revocation checks. A working example runs on Amazon Bedrock and the AWS Strands Agents SDK with Keyfactor EJBCA issuing and validating the X.509 certificates, and the full code is on GitHub.

Source: AWS Machine Learning20 Oct 2026, 19:03AWS Original article ↗

This summary was generated automatically by AI from AWS Machine Learning's publication. It is our own text, not a copy of the original — facts, figures and quotes belong to the source, linked above and below.

What changed?

1Three trust layers: user login (OAuth + X.509 cert + delegation minting), agent-to-agent calls (signed envelopes), and MCP tool access (scoped token + envelope + delegation)
2Every agent-to-agent request is signed with RSA-PSS-SHA256 and carries a timestamp plus a random nonce so it can't be forged or replayed
3A user-signed delegation assertion authorizes specific agents to act on their behalf without ever handing over the user's private key or full session token
4RFC 8693 token exchange narrows a token's audience to just the MCP server, so a leaked token can't be reused elsewhere
5OCSP checks run in real time against EJBCA, so revoking one certificate blocks that identity across the whole agent chain immediately
6Demo stack: Amazon Bedrock, AWS Strands Agents SDK, Amazon RDS for MySQL, AWS Secrets Manager, and Keyfactor EJBCA running on EC2

Why it matters

As agent chains grow to include orchestrators, sub-agents, and MCP tool servers, there's currently no standard way to prove which agent sent a request or stop one component from impersonating another — this closes that gap with cryptographic proof instead of shared secrets.

What it means for AI agents and contact centers

Relevant for any team running voice agents that call internal tools, CRMs, or databases via MCP-style tool invocation: the pattern of signed envelopes plus scoped tokens plus real-time revocation is a template worth comparing against whatever auth is currently used between your agent, STT/TTS services, and backend integrations, especially where a leaked credential could expose more than one call.

🧪 Worth Testing

Worth reviewing as a security checklist for multi-agent voice/contact-center systems — specifically whether current agent-to-tool calls use short-lived, scoped credentials with replay protection, or still rely on long-lived shared API keys.

X.509 PKI identity layer for MCP agents (AWS + Keyfactor EJBCA)· New

MCP Agents PKI Security OAuth Amazon Bedrock AWS Strands

Sources

AWS Machine LearningOfficialPrimary source
„Securing AI agent identity with X.509 PKI on AWS“
20 Oct 2026, 19:03
Original article →

Published by source: 20 Oct 2026, 19:03
Found by our system: 20 Oct 2026, 19:16
Summary generated: 20 Oct 2026, 19:49

This article was written by AI from the original source. Facts, numbers and prices come from the source; missing values are marked “Not specified”. Legal notice, copyright and privacy