Does mTLS replace OAuth for agent-to-agent authentication?

The two patterns compose. mTLS authenticates the connection at the transport layer. OAuth authenticates the request at the application layer. Deployments often use both: mTLS binds the connection to the calling agent's identity, and OAuth binds the request to the initiating user's identity through the DPoP or similar bearer-token mechanism.

How short should agent certificate validity periods be?

The tradeoff is rotation frequency against operational overhead. Short-lived certificates (hours to a day) reduce the exposure of a stolen certificate to hours. The rotation cost is CA capacity and agent-side reload complexity. Deployments with automated certificate delivery (SPIFFE/SPIRE, cert-manager) tolerate short-lived certificates without operational overhead. Deployments with manual delivery tend toward multi-week validity periods.

What happens when a receiving agent's inspection layer is unavailable?

The inspection layer's availability determines the deployment's availability. A fail-closed architecture blocks all agent-to-agent calls when the layer is unavailable. A fail-open architecture allows calls to proceed with a degraded audit record. Most deployments run fail-closed with the layer deployed at high availability (multiple regions, multiple availability zones).

Does the delegation chain grow unboundedly in long workflows?

The chain length is capped by the deployment's policy. A workflow that legitimately runs through more than the cap requires an explicit exception or a workflow restructure. Cap values in the range of 5 to 10 hops handle the common workflow patterns without capping legitimate use.

How does the pattern work when agents run in different clouds or on different providers?

The mTLS binding is portable across clouds because it operates at the transport layer. The inspection layer at each cloud terminates the mTLS connection using the certificate chain from the trusted CA. Cross-cloud deployments federate the CA or use a common workload identity provider (SPIFFE) that spans clouds.

Can existing HTTP libraries emit the delegation chain header without code changes?

The header is a simple HTTP header, and every HTTP library supports emitting custom headers. Deployments that adopt the pattern typically wrap the HTTP client in a helper that adds the required headers automatically based on the current request context. The wrapper is a small library change, not a per-request code change.

Agent-to-Agent TLS: Mutual Authentication Between AI Agents in a Multi-Agent Workflow

A multi-agent workflow chains AI agents. A supervisor agent decomposes the user's request and delegates to worker agents. Each worker agent calls the next agent in the chain, or calls tools on its own, or returns a result to the supervisor. The chain typically runs over HTTP, and the security posture at each hop depends on the mutual authentication between the two agents making the call.

The NIST NCCoE AI agent identity and authorization project treats agent-to-agent authentication as one of the four core problems the framework addresses. The OWASP Top 10 for Agentic Applications 2026 lists identity spoofing between agents as one of the ten categories. The mTLS pattern is the current baseline for satisfying both.

I want to walk through the mTLS pattern for agent-to-agent authentication, the certificate lifecycle, and the inspection-layer architecture that binds every agent-to-agent call to a verified identity pair.

The mTLS pattern

Mutual TLS extends the standard TLS handshake with a client certificate. The server presents its certificate as it does in one-way TLS. The client also presents a certificate. The server validates the client certificate against a trusted certificate authority before accepting the connection. Both parties are authenticated cryptographically before any application data flows.

For agent-to-agent calls, mTLS works as follows.

Agent A issues an HTTPS request to Agent B's service endpoint. Agent A presents its client certificate as part of the TLS handshake.

Agent B's TLS terminator validates Agent A's client certificate against the trusted CA chain, extracts the subject from the certificate, and rejects the connection if validation fails.

Agent B's application receives the request with the validated subject attached as a request-context field. The application enforces authorization based on the subject.

The subject in the certificate is the agent's non-human identity. The certificate is issued to the agent by the internal CA and rotates on a schedule appropriate to the risk profile.

Certificate lifecycle

The certificate lifecycle has five stages, and each stage has a control point that can fail.

Issuance

The agent's identity is registered with the internal CA. The CA issues a certificate bound to the agent's subject with an appropriate validity period (typically 24 hours to 30 days for short-lived, 6 to 12 months for long-lived). Short-lived certificates reduce the exposure of a stolen certificate.

Distribution

The certificate is delivered to the agent's runtime. The private key never leaves the agent's key management surface. Common patterns include:

The CA writes the certificate and key to a Vault path the agent reads at startup.
The workload identity provider issues the certificate to the agent through SPIFFE/SPIRE.
The Kubernetes cert-manager issues the certificate to the agent's pod through the standard secret mount pattern.

Presentation

The agent presents the certificate on every outbound TLS handshake. The TLS library at the agent's runtime handles the presentation, and the agent's application code does not need to be aware of the certificate.

Validation

The receiving agent's TLS terminator validates the certificate chain against the trusted CA, checks the expiration and validity period, and checks for revocation through OCSP or CRL. Revocation checks that time out fall back to soft-fail (accept) or hard-fail (reject) based on the deployment's policy.

Rotation

The agent rotates its certificate before expiration. Short-lived certificates rotate every few hours, and the rotation is transparent to the calling agents because both certificates chain to the same CA. Long-lived certificates require a coordinated rotation to avoid mid-flight failures.

The identity binding at the request layer

The mTLS handshake binds the connection to the agent's certificate subject. The binding happens once per connection. Multiple requests can flow over the same connection, and all of them carry the connection's subject.

The identity binding at the request layer extends the connection-level binding to the per-request level. Each request carries a header that identifies the request's on-behalf-of subject: the human user or the upstream agent whose delegation the current call is executing.

The X-DeepInspect-Agent-Subject header carries the immediate caller's identity. The X-DeepInspect-On-Behalf-Of header carries the ultimate initiator. The X-DeepInspect-Delegation-Chain header carries the full chain from the initiator through every intermediate agent to the current caller.

The receiving agent's TLS terminator confirms the header claim matches the mTLS certificate subject. Any mismatch (header claims subject X, certificate is subject Y) fails the request.

Inspection-layer architecture

The inspection layer between agents produces the authoritative record for the agent-to-agent call. Four properties of the layer make the binding durable.

mTLS termination at the inspection layer

The inspection layer terminates the mTLS connection on behalf of the receiving agent. The certificate validation happens at the layer, and the subject is extracted from the certificate before the request forwards to the receiving agent.

Delegation chain verification

The inspection layer verifies the delegation chain header against the policy that governs the chain. A chain that includes an agent not authorized to act on behalf of the ultimate initiator fails at the layer. A chain that skips a required authorization step fails at the layer.

Per-hop policy evaluation

The inspection layer evaluates each hop in the chain against the policy that applies to the pair. Agent A calling Agent B on behalf of user U is a distinct policy decision from Agent A calling Agent C on behalf of user U. The layer maintains per-pair policy and evaluates each hop independently.

Audit record per hop

The layer produces an audit record for each hop. A multi-agent workflow that runs through four agents produces four audit records, and the records are linked by the delegation chain field. The auditor reviewing the workflow reconstructs the full chain from the linked records.

Compliance implications

The agent-to-agent authentication pattern is the enforcement point for multiple compliance obligations.

The EU AI Act Article 19 identity requirement extends to multi-agent workflows. The natural person on whose behalf the workflow runs has to be identifiable in every audit record. The delegation chain header and the per-hop audit record satisfy the requirement.

The ISO 42001 Annex A.7.2 controls for AI system access require authenticated access between AI system components. The mTLS binding is the evidence artifact.

The OWASP Top 10 for Agentic Applications 2026 identity spoofing category is closed by the mTLS + delegation chain pattern. The evidence artifact is the per-hop audit record that shows the mTLS validation succeeded and the chain verification passed.

DeepInspect

This is exactly what DeepInspect does. DeepInspect sits inline between agents in a multi-agent workflow, terminates mTLS on each hop, verifies the delegation chain, evaluates the per-hop policy, and produces the per-hop audit record.

The four-property architecture at the inspection layer replaces the pattern where every agent implements its own TLS termination, delegation verification, and audit logging. The enforcement point is consistent across every agent in the workflow, and the audit trail is complete across every hop.

Book a demo today.