AWS and Keyfactor give three AI agents their own certificates, so revoking one certificate cuts the whole chain

Your team has an AI assistant made of several agents (AI software that calls tools on its own) with access to the company database and mailbox. An employee leaves today. Can you shut off everything those agents do on that person’s behalf in one action, or do you have to hunt down every API key (the key a program uses to call a service), every login session and every agent? On October 20, 2026, engineers from AWS and Keyfactor published a reference architecture that answers that question with digital certificates, and it is worth reading even if you use neither company’s products.

What the AWS and Keyfactor post proposes

The post is by Deepakkumar Sharma, Alex Ament and JD Kilgallin on the AWS Machine Learning blog. They describe the problem: MCP (Model Context Protocol, the protocol that connects agents to tools and data) has no authentication standard of its own, so any component could impersonate an agent or replay intercepted credentials. According to the post, sharing API keys between components or passing OAuth tokens (temporary access tokens) through a chain of agents falls short of enterprise zero-trust (trust nothing by default) requirements.

Their architecture uses X.509 certificates, digital identity documents signed by a certificate authority, with Keyfactor’s EJBCA as that authority. It has four mechanisms:

• A signed envelope for each request. The orchestrator agent signs the whole request (tool name, arguments, a timestamp and a one-time random number) with its own private key. The receiving agent can check that the sender really holds the key. Re-sending the same prompt requires a new envelope, and an old envelope cannot be replayed.
• A delegation assertion signed by the user. At login, the application generates key pairs, requests certificates for the user and for three agents, and the user signs a document listing the SHA-256 fingerprints of the three agent certificates. Agents carry this document instead of the user’s credentials.
• Audience-scoped tokens. Using the RFC 8693 standard, the session’s full token is exchanged for a narrow token that works only with the MCP server. Only the narrow token is given to agents.
• Real-time revocation checks. Every request queries EJBCA over OCSP (a protocol that asks whether a certificate has been revoked).

At logout, the system revokes the user certificate and the three agent certificates. The post says that revoking one user certificate invalidates every delegation and all downstream agent authority without deleting tokens or sessions one by one, because every request passes an OCSP check. This is the vendors’ own description of a sample system; the post reports no measurements or independent tests, and its example uses a database as the protected resource. The certificates in the example are valid for 7 days, and the system denies a request if OCSP cannot be reached, the signature is wrong, the timestamp has expired, a one-time number is repeated or the audience is wrong.

Three questions to take to your own system

The three questions below are this article’s suggestions and have not been tried on any system. You can ask them of any agent identity solution, including one that does not use X.509 certificates.

1. If you revoke one person, does the agents’ authority disappear with them? List everything the agents hold on behalf of one user: API keys, tokens, sessions. For each, write down who revokes it and how long it takes. Anything that outlives the user or must be deleted by hand is a gap to close first.
2. When the revocation-check component does not answer, does the system deny or let requests through? The post chooses to deny. Temporarily shut down the checking service in a test environment and see whether the agents’ requests are blocked. If they still go through, the agents’ authority depends on that service never failing.
3. Can an agent call another agent outside the allowed list? In the example, only the orchestrator agent can call the database agent and the email agent; the sub-agents do not call each other and do not call upward. Try having one sub-agent call another. If it works, write down who allowed it and why.

If all three questions have an answer you can write in one line, you know where the agents’ authority ends. If any answer is “don’t know,” do not extend agents’ permissions until you do.

Sources

1. AWS Machine Learning Blog, “Securing AI agent identity with X.509 PKI on AWS” (October 20, 2026) — the AWS and Keyfactor reference architecture: signed envelopes, delegation assertions, RFC 8693 tokens, OCSP checks, the revocation cascade at logout and the security considerations.