Mutual TLS (mTLS)

Both parties traverse the chain of trust to a mutually trusted root CA during the handshake. This process verifies:

• The certificate has not expired or been revoked (via CRL or OCSP stapling)
• The digital signature matches the issuing CA's public key
• The certificate's Key Usage and Extended Key Usage extensions permit client/server authentication Any break in this chain immediately terminates the connection.

Authentication is not merely presenting a certificate; it requires proof-of-possession of the corresponding private key. During the handshake, the client signs a transcript of all preceding handshake messages using its private key. The server verifies this signature against the public key embedded in the client's certificate, cryptographically binding the session to that specific identity and preventing replay attacks.

After mutual authentication, both parties derive identical symmetric session keys using an ephemeral key exchange (typically ECDHE). This ensures Perfect Forward Secrecy (PFS)—even if a long-term private key is later compromised, past session keys cannot be decrypted. All subsequent agent communication is encrypted with AEAD ciphers like AES-256-GCM, providing both confidentiality and integrity.

In agentic mesh networks, sidecar proxies (like Envoy or Linkerd) automatically perform mTLS between services without application code changes. The mesh issues short-lived SPIFFE-compliant certificates tied to workload identity rather than IP addresses. This enables:

• Automatic certificate rotation (often every 24 hours)
• Fine-grained access policies based on service accounts
• Transparent encryption of all east-west traffic

In TLS 1.3, the server initiates client authentication by sending a CertificateRequest message immediately after its own CertificateVerify. This message specifies:

• Acceptable certificate authorities via certificate_authorities extension
• Supported signature algorithms (e.g., ecdsa_secp256r1_sha256)
• Optional certificate_extensions for OIDC or SPIFFE identity documents The client responds with its certificate chain and a CertificateVerify signature, all encrypted under the handshake traffic key.

The complete framework of roles, policies, hardware, and software required to create, manage, distribute, and revoke digital certificates. mTLS depends entirely on a robust PKI to validate the certificates presented by both client and server.

• Certificate Authorities (CAs) issue and sign certificates
• Registration Authorities (RAs) verify identity before issuance
• Certificate Revocation Lists (CRLs) and OCSP handle invalidation
• A compromised CA undermines all mTLS trust in the system

A security model that eliminates implicit trust and requires continuous verification of every access request. mTLS is the transport-layer enforcement mechanism that makes zero-trust agent networks possible.

• Never trust, always verify — regardless of network location
• Every agent-to-agent call requires mutual authentication
• Micro-segmentation limits lateral movement after a breach
• Combines with continuous authentication for defense-in-depth

A dedicated physical computing device that safeguards and manages digital keys for strong authentication. In mTLS deployments, HSMs protect the private keys associated with agent certificates from exfiltration.

• Prevents private key theft even if the host is compromised
• Performs cryptographic operations in tamper-resistant hardware
• Achieves FIPS 140-2 Level 3 certification
• Essential for high-assurance agent identity in regulated industries

A hardware-based security paradigm that protects data in use by performing computation in a Trusted Execution Environment (TEE). Extends mTLS protection to the runtime memory of agent processes.

• Intel SGX and AMD SEV create encrypted memory enclaves
• Shields agent logic and data from the host operating system
• Enables remote attestation to verify agent integrity before mTLS handshake
• Prevents privileged insider threats from inspecting agent memory

An application-level mechanism for sender-constraining OAuth tokens. DPoP requires the token presenter to prove possession of a private key, mitigating token replay attacks in agent API calls.

• Binds access tokens to a specific client key pair
• Prevents stolen bearer tokens from being reused by attackers
• Complements mTLS at the application layer
• Defined in RFC 9449 for OAuth 2.0 protected resources