One-Line Summary: Mutual TLS (both sides authenticate via certificates) and ed25519 message signatures (compact, fast, modern) are the cryptographic substrate of federated agent systems — they are how a remote agent proves "I am who I say I am" before any meaningful interaction begins.

Prerequisites: Cross-machine agent federation, transport-layer security basics

What Are mTLS and ed25519?

mTLS (mutual TLS) extends standard TLS by requiring both endpoints to present certificates. Standard HTTPS authenticates the server to the client; mTLS additionally authenticates the client to the server. For agent federation this is essential — when a peer talks to your agent, you want to know which peer.

ed25519 is a modern public-key signature scheme: 32-byte private keys, 64-byte signatures, fast verification (~50µs), strong security. It is the consensus choice for new systems requiring digital signatures (used by SSH, Tor, Signal, Bitcoin's Schnorr predecessor). For agent identity and per-message signatures, ed25519 is the right default.

The combination: mTLS provides the secured channel and authenticated session; ed25519 provides per-message signatures so individual decisions, vote-casts, and memory writes are independently verifiable even after the channel closes.

How They Fit a Federated Agent Pipeline

When peer A wants to send a command to peer B:

  1. Connection: A connects to B over mTLS. Both sides verify the other's certificate against a trust anchor (a CA, a known-key list, or a federation registry).
  2. Identity confirmation: B looks up A's mTLS-verified identity in its peer registry. If A is unknown or untrusted, refuse.
  3. Per-message signing: A signs the command with its ed25519 private key. The signature accompanies the message.
  4. Signature verification: B verifies the signature against A's known public key.
  5. Command execution: Subject to additional authorization (behavioral trust, ACLs).
  6. Signed response: B signs the result with its own key.
  7. Audit log: Both ends log the (peer-id, message, signature) tuple for later verification.

The signed-message layer is what lets B forward A's command to a third peer C and have C independently verify A's authority — without trusting B.

Why This Matters for Agents

Without authenticated identity, federation is impossible. "An agent told me to delete production" is uncheckable in plain HTTP; it is verifiable in a properly-deployed mTLS+ed25519 system. The work is non-trivial but the tooling is mature: Rust's rustls, OpenSSL, libsodium, age, and similar libraries handle the cryptographic primitives correctly.

A second reason: signatures are forensic-grade. After-the-fact, a signed command tells you exactly which peer issued it and at what time, regardless of what happened in between. That auditability is critical for any deployment with regulatory exposure.

Key Technical Details

  • Certificate authorities vs. self-signed: mTLS works with any trust model. A federation might use a single CA (centralized), per-organization CAs (federated trust), or pinned self-signed certs (decentralized). Pick based on operations.
  • Key rotation matters: Long-lived keys are a liability. Plan rotation from day one — short-lived certs (hours/days) plus automatic renewal.
  • Hardware-backed keys (TPM, secure enclave) are the right answer for high-value agents.
  • Replay protection: Signed messages need a nonce or timestamp; otherwise an attacker can re-send a captured command.
  • Performance: mTLS handshake ~few milliseconds; ed25519 sign/verify ~50–100µs. Both negligible compared to LLM call latency.
  • Quantum migration roadmap: ed25519 is not post-quantum-secure. For long-lived guarantees, plan for hybrid signatures using post-quantum schemes (ML-DSA / Dilithium) by 2027–2028.

How Harnesses & Frameworks Implement This

Harness / FrameworkmTLS + ed25519
Claude CodeNone natively
Claude Agent SDKDIY
rufloFirst-class — federation transport
LangGraphDIY
AutoGenDIY
CrewAIDIY
OpenAI Agents SDKDIY
Codex CLI / Cursor

Connections to Other Concepts

  • cross-machine-agent-federation.md — The setting that needs this.
  • behavioral-trust-scoring.md — Reputation layer that sits above identity.
  • pii-gating-and-aidefence.md — Application-layer protection complements transport-layer.

Further Reading

  • RFC 8446 (TLS 1.3) and RFC 8032 (EdDSA / ed25519).
  • libsodium documentation — the friendliest entry point for ed25519.