Nine Lives for netcat on a Tailnet

When two of your agents talk to each other, what exactly is authenticating them? Not the prompt. Not the framework. In most deployments I have looked at, the honest answer is an IP address, a port number, and a shared secret someone pasted into an environment variable eight months ago. We build elaborate reasoning loops on top of a transport layer that has no idea who is on either end.

Which is why a small utility called Tailcat caught my attention this week. The pitch is deliberately unglamorous: it is netcat, but the bytes ride Tailscale’s data plane instead of the ordinary socket path. Pipe in, pipe out, between two machines on a tailnet. I have not audited the implementation, and I would encourage anyone deploying it to read the source before trusting it with anything sensitive. But the shape of the idea is worth thinking about carefully, because it touches something agent architecture keeps getting wrong.

The control plane and the data plane are different animals

Tailscale’s design separates coordination from carriage. A control plane handles identity, key distribution, and policy. The data plane, built on WireGuard, moves encrypted packets directly between peers when it can, falling back to relays when NAT gets in the way. That split is the interesting part. Identity is established once, cryptographically, at the level of the device and user. Everything that flows afterward inherits that context.

A tool that speaks directly to the data plane is therefore not just a convenience wrapper. It is a different trust model. Instead of “open a port, hope the firewall is configured, add a token,” you get “this stream came from a peer whose key the control plane vouched for.” The authentication is not bolted onto the payload. It is underneath it.

Why this matters for agents specifically

Agent systems have converged on the humblest interface imaginable. The Model Context Protocol’s most common transport is stdio. Tool calls shell out. Sub-agents get spawned as child processes and communicate through pipes. We spent a decade building service meshes and gRPC schemas, and then the agent era arrived and everybody went back to standard input.

There is a reason for that, and it is not laziness. Pipes compose. A byte stream with no opinions about its contents can carry JSON-RPC today and something else tomorrow. It needs no schema registry, no sidecar, no code generation step. For systems whose behavior is defined at runtime by a model rather than at compile time by a developer, that flexibility is close to essential.

The problem is that pipes stop at the machine boundary. The moment your agent needs to reach a tool on another host, you leave the tidy world of file descriptors and enter the messy one of listeners, certificates, and reverse proxies. Most teams solve it by exposing an HTTP endpoint and guarding it with a bearer token, which means the agent’s identity is now a string that any component holding it can replay.

A stream primitive that carries peer identity from the network layer collapses that gap. The mental model stays “pipe to another process,” but the other process happens to be on a different machine, and you know which machine, verified by keys you did not have to manage yourself. That is a meaningfully better foundation for distributed agent topologies than a token in a header.

The part that should make you cautious

Mesh networking has a failure mode that agent developers are unusually well positioned to trigger. Flat networks make lateral movement easy, and an autonomous system that can generate its own connection targets is a very effective lateral movement engine. If your agent can reach any node on the tailnet, a prompt injection in a scraped web page becomes a network reconnaissance tool.

So the access control policy is not a deployment detail here. It is the actual security boundary. I would want per-node ACLs written as tightly as the task allows, separate identities for separate agent roles rather than one shared machine key, and logging at the connection level so that after an incident you can reconstruct which peer talked to which. None of that comes free with a transport tool, and a tool this ergonomic makes it easy to skip.

There is also a philosophical tension. Part of what makes netcat useful is that it does nothing. It has no notion of sessions, retries, or backpressure. Agent workloads are long-lived, bursty, and prone to hanging mid-stream while a model thinks. A raw pipe will happily let you build something fragile. The solid version of this pattern still needs framing, timeouts, and cancellation semantics layered on top.

What I take from it

The interesting claim embedded in Tailcat is not about performance. It is that the right place to put agent identity might be the network, not the application. We keep reinventing authentication inside every framework, and every reinvention leaks. Pushing it down a layer, where cryptographic peer identity is already solved, means the agent code gets simpler and the guarantees get stronger at the same time.

Small tools are often where architectural arguments show up first. This one is arguing that the pipe was always the right abstraction, and it just needed to learn who was on the other end.

🕒 Published: August 27, 2026