Pilot verifiable X.509 identities for AI agents calling APIs or MCP tools. Test certificate issuance, signed requests, scoped delegation, revocation and audit evidence.

A bearer token does not prove which agent used it

A multi-agent workflow may pass work from an orchestrator to a database or email agent. If every process shares one API key, the protected service cannot reliably distinguish them, restrict one role or revoke a single agent without disrupting the rest.

AWS published a reference architecture on October 20, 2026 using Keyfactor EJBCA, Amazon Bedrock, the Strands Agents SDK and other AWS services. It combines X.509 certificates, signed request envelopes, user-signed delegation, audience-scoped tokens and OCSP revocation. This is an engineering pattern, not a newly released managed AWS feature or a claim that certificates make an agent safe.

A focused Firecrawl search on October 21 returned the AWS post first, a current IETF draft on AI Agent Identity Certificates second, and additional recent identity coverage. Those placements show current public attention to the problem, not verified traffic or effectiveness.

A human owner delegates to an orchestrator certificate, which calls role-specific agents and protected tools through a verifiable trust chain.
Conceptual trust chain. Every hop still needs policy, proof-of-possession and independent authorization.

1. Design a small nonproduction pilot

Use one orchestrator, one protected test tool and synthetic data. Write down the human owner, agent roles, allowed operation, certificate lifetime, issuer, revocation method, audit destination and cleanup procedure. Keep production databases, email recipients and credentials outside the pilot.

The AWS example requires an AWS account with access to Amazon Bedrock, RDS for MySQL, SES and Secrets Manager, plus an EJBCA API administrator certificate and familiarity with X.509, OCSP, OAuth 2.0, RSA signatures and PKCS#12. EJBCA Enterprise is a commercial product. AWS services and certificate infrastructure can incur charges; check current regional availability and pricing before adopting the example.

If the team does not already operate PKI, do not create a production certificate authority merely to follow a blog post. Start with an architecture review or use an approved machine-identity service and security team.

A security engineer issues a certificate to an AI agent while its private key remains in a local vault.
AI-generated conceptual illustration: the private key should remain within the controlled application boundary.

2. Require identity and proof on every tool call

Issue a distinct short-lived certificate for each agent role. Generate the key in the controlled runtime, submit only a certificate-signing request to the issuer and store the private key in an approved secrets or hardware-backed system. Record the certificate fingerprint with the agent register.

Have the calling agent sign the tool name, arguments, timestamp and a fresh nonce. The receiving tool should validate the signature, certificate chain, expiration, allowed caller role, replay window and revocation status before evaluating the requested operation. A certificate common name alone is not authorization.

The expected pilot evidence is a successful permitted call plus rejected cases for the wrong role, altered payload, stale timestamp, reused nonce and untrusted issuer. Preserve the actual verifier results instead of asking the model to report that validation occurred.

A signed request envelope contains the tool, arguments, timestamp and nonce; the receiver validates signature, chain, role, replay and revocation.
Suggested verification sequence based on the AWS reference architecture.

3. Bind the agent to a user and a narrow audience

A user delegation should name the approved agent certificate fingerprint, issuance time and expiry. Use a token scoped to the protected tool and minimum operation rather than forwarding a broad user credential. Cross-check the user, delegation, agent certificate and target audience before executing.

Suggested review prompt for an approved assistant: ‘Given these sanitized verifier logs, list each identity link, scope decision and failed validation with its exact record. Mark missing evidence unknown. Do not reconstruct private keys, tokens or certificate contents that are not supplied.’

Use redacted logs for analysis and keep private keys, bearer tokens and unneeded personal data out of prompts. The assistant can organize the evidence; it cannot substitute for cryptographic verification.

A pilot checklist tests permitted call, wrong role, altered payload, replay, expired certificate and revoked certificate outcomes.
Minimum negative tests for a nonproduction identity pilot.

4. Prove revocation works before trusting issuance

Revoke the test user or agent certificate and repeat the same request. The tool should deny it using the configured OCSP or revocation mechanism and emit a durable reason. Measure propagation in your own environment; do not assume the word real-time describes every network, cache or failure mode.

Test what happens when the revocation service is unreachable. A fail-open choice may preserve availability while accepting a revoked credential; a fail-closed choice may interrupt legitimate work. Document the selected behavior, monitoring and recovery route.

After the exercise, revoke test certificates, remove secrets and synthetic resources, and retain the approved evidence. The AWS reference uses immediate secret deletion in cleanup, but a production secrets policy may require a recoverable window and change approval.

A certificate authority revocation control disables several downstream AI-agent tool paths while audit records remain visible.
AI-generated conceptual illustration: revocation should cut authority without erasing the investigation trail.

Promote only the verified control, not the demo

A successful lab proves only the cases you tested. Before production, add key protection, rotation, issuer availability, tenant isolation, CloudTrail or equivalent audit, latency expectations and incident ownership. Content guardrails and tool allowlists remain necessary because PKI authenticates a caller; it does not prove the requested action is correct.

  • Use a unique, short-lived certificate per agent role.
  • Verify signed requests and scoped delegation at the protected tool.
  • Test revocation, outage behavior and cleanup with synthetic resources.

Put the insight into practice.

Deep Security helps organizations assess risk, validate controls, and build a practical plan to strengthen their defenses.

Talk with Deep Security