So we’re building a whole fleet of AI agents now? And they need to talk to each other with “mutual TLS”? Wonderful. Just what my systemd unit files were missing.
Back in my day, if you needed two machines to trust each other, you set up SSH keys, hardened the config, and maybe used a simple netcat script in a cron job. Now we need a “LangGraph orchestrator” and a guide for it. What’s wrong with a well-crafted bash script and some careful firewall rules? It’s auditable. It’s simple. It works.
What permissions does this “orchestrator” even need? Full network access, I bet. Reads your entire keystore? 🧐 Let’s see this guide, then. I’m sure it’s a model of minimalism.
> Back in my day, if you needed two machines to trust each other, you set up SSH keys
Oh absolutely, and that still works great for a lot of stuff! I'm right there with you on the beauty of a clean bash script.
The mutual TLS thing, for me, is about when you start treating these agents like separate microservices on a bigger internal network. You might have a dozen tiny llama.cpp instances on different VMs, each with a specific job. SSH tunnels get messy at that scale. mTLS lets them all authenticate without a central password file, and the orchestrator can just be another service with its own cert. It shouldn't need your keystore - it just needs its own keypair and to trust the CA that signed the agents' certs.
It's definitely more moving parts than a netcat cron job, I'll give you that. But when the guide drops, I'm hoping it's just OpenSSL commands and some config snippets we can adapt. Fingers crossed it's not a 20-container monstrosity.
--Ryan
You're right that complexity is a real audit risk. A simple system with a known, limited blast radius is often safer than a "secure" one that's too intricate to verify.
Where I see mTLS fitting in is for audit trails in regulated environments. SSH key auth is solid, but logging and proving *which* agent made which call across dozens of systems gets messy fast. With a proper PKI setup, you get cryptographically signed sessions that are easier to trace for compliance. It's not about being minimalist, it's about producing evidence.
But you've hit the core issue: that orchestrator shouldn't need your keystore. If it does, the design is wrong. It should only need its own identity certificate and the public CA cert. If the guide suggests anything else, we should call it out.
Audit-ready or go home.
I appreciate the sentiment, because the skepticism is correct. The complexity of any mTLS setup is directly proportional to the attack surface. A bash script with tightly scoped SSH keys is absolutely more auditable.
The problem is that the threat model changes when you shift from "a few machines I control" to "a fleet of automatically provisioned, ephemeral agents." SSH key distribution and revocation at that scale becomes its own operational nightmare, often leading to key sprawl and the exact permission issues you're worried about. A proper PKI, while heavier initially, centralizes the trust root (the CA) and makes revoking a compromised agent a one-line operation.
That said, if your orchestrator requires the CA *private* key, rather than just its public certificate, the guide is fundamentally broken and you've just introduced a single point of catastrophic failure. It should only need its own client certificate and the public CA cert to validate others. Any design suggesting otherwise deserves the side-eye you're giving it.
A CVE a day keeps the complacency away.
SSH keys and a bash script work perfectly until you have to rotate 500 keys at 3am because an agent VM got pwned. That's the scale problem.
Your point about the orchestrator's permissions is correct though. If it needs more than its own keypair and the CA public cert, the design is broken. It shouldn't touch a keystore.
The real audit nightmare is managing those cron jobs across a fleet. With containers, you can lock it down: read-only rootfs, non-root user, seccomp profile. Harder to do with a custom systemd unit.
USER nobody