Most AI agents live somewhere else.
The one I use — Muse — runs in a cloud virtual machine. And to be precise: I use Muse, I don't own it. It's a service, not software I control or a model running on my hardware. That's by design, and mostly it's a feature: the agent gets its own computer, its own browser, its own filesystem, and if something goes sideways, it goes sideways over there, not on the laptop with my life on it.
It also raises the stakes of everything below. Letting your own software onto your home network is one decision. Letting a service you use — but don't own — reach in is a different one, and it only makes sense if the access is narrow, approved by you, and revocable by you. Which is exactly the shape Muse + Tailscale takes.
But that distance has always come with a tax. The interesting machines in my life are not in the cloud. They're here. On my desk, on my home network, behind NAT, deliberately not exposed to the internet. A file server. A dev box. Lab hardware. Every agent I've used before hit the same wall at my router, and the workaround was always the same degrading ritual:
I became the USB cable.
The agent would tell me a command to run. I'd paste it into a terminal. I'd paste the output back. Repeat fifty times. The smartest software I've ever used, reduced to dictating to the slowest peripheral in the room — me.
Muse shipping with Tailscale built in quietly removes that wall. I think it's one of the most underrated design decisions in personal agents so far, and I got to prove it on the best possible test case: a piece of radio hardware that cannot, by definition, be moved to the cloud.
What actually shipped
Muse has a built-in Tailscale client. Not "install this package and configure a VPN" — a client that exists for one purpose: letting a cloud agent join your private network, as a peer, under your control.
The security shape matters, so here it is plainly:
- It joins as its own device — it shows up in my tailnet as
muse— and only after I approve it in my Tailscale admin console. No approval, no network. - It is client-only. It makes outbound TCP connections. It accepts no inbound connections, hosts nothing, and routes no traffic for anyone else. It is a guest that can knock on doors, not a new door into my house.
- The first connection to each exact address needs its own approval too, and that approval covers that address for the lifetime I choose. A different name or address for the same machine is a new approval. Friction, yes — intentional friction, at exactly the moment a new reach is being established.
- If I ever want it gone, I disconnect it and delete the device. Revocation is a button, not an incident response plan.
Compare the alternatives for giving an agent reach into a home lab: port-forwarding a service onto the public internet (never), exposing SSH and hoping (no), or babysitting a reverse tunnel I built myself (I have done this; it becomes a pet, and pets die at 2 a.m.).
Tailscale gives the agent a private road to exactly the machines I say, and gives me the keys to the road.
The test case: a radio that only exists in my house
A test of "can the agent reach my network" could have been a ping and a screenshot. Instead, an opportunity fell into my lap: I resurfaced a MicroPhase ANTSDR E200 I'd bought and shelved — a software-defined radio in the PlutoSDR family, built around an AD9361 chip, tunable from 70 MHz to 6 GHz.
An SDR — software-defined radio, a receiver (and transmitter) whose behavior is defined in software instead of fixed circuits — is the perfect honesty test for agent reach, for three reasons:
- It is irreducibly physical. It receives the actual air in my actual room. There is no cloud version of the RF environment around my desk.
- It is awkward on purpose. The E200 is Ethernet-only, no USB data, with a static IP address. It wants a host computer next to it doing the talking.
- I actually had a job for it. I wanted to look at 2.4 GHz — the band where the Spektrum SLT protocol that runs several of my RC cars lives. That work starts with seeing what's on the air.
So the chain we built looked like this:
Muse (cloud VM) → Tailscale → my MacBook Pro → a small radio server → the E200
On the Mac, a small server written for the job exposes the radio as structured tools — the Model Context Protocol (MCP), the emerging standard for giving agents tools with defined inputs and outputs, rather than a raw shell. Under the hood it talks to the radio through the standard pyadi-iio library. Version one was deliberately receive-only: tune, report status, capture spectrum. No transmit path at all. Least privilege isn't a slogan; on a radio, it's manners and law at the same time.
Tailscale and MCP do different jobs, and the combination is the point. Tailscale is the road — private, encrypted, approved by me. MCP is the language spoken at the end of the road — not "here's a terminal, good luck," but five named tools with bounded behavior. Either one alone is half an answer.
Receipts
On November 7, from its cloud VM, Muse called the radio — through my tailnet, to a server on my Mac, to hardware sitting in my house — and the radio answered:
- Status came back live: PlutoSDR Rev.C hardware (Z7010 + AD9361), firmware v0.34-dirty, tuned to 2.400 GHz, sampling at 30.72 million samples per second across 18 MHz of bandwidth.
- A spectrum capture came back real: 32,768 samples, and in them a strong cluster of energy at 2401.8–2402.2 MHz, about 33 dB above the noise — right in the neighborhood of Bluetooth Low Energy's advertising channel 37. The air in my room, measured by my radio, analyzed by an agent that has never been in my room.
No pasted commands. No pasted output. I approved the device, I approved the address, and then I watched an agent drive hardware across a network I own.
That session was the test. It has since become the working setup — the captures that followed are how we've been decoding the RC protocol the radio was pointed at in the first place.
The honest limits
Because this is CybrSec Media and not a press release:
- It's TCP only. No UDP, no ICMP — a failed ping across the tailnet proves nothing, and some protocols simply won't ride this road. For tool servers and SSH-shaped work, that's fine. For everything, it isn't.
- It's client-only, full stop. Muse can't host a service on your network or be reached inbound through this. That's the right default for an agent, and it also means some designs — anything that needs the lab to call the agent back — need a different piece. (We hit that elsewhere, with ephemeral cloud GPU machines, and solved it the other way around: the ephemeral box phones home to a fixed point. Same instinct: constant, approved destinations; no standing inbound doors.)
- First-contact approval is real friction. For interactive work — me, present, exploring a radio — it's a seatbelt. For unattended automation, any design that needs a human tap per run has failed at being automation. Knowing which mode you're in is the whole ballgame.
Why I think this matters
The conversation about agents is mostly about models: smarter, faster, longer context. This was a reminder that reach is a capability too — and reach, done carelessly, is how agents become security incidents with good vocabulary.
The pattern I want more of looks like this: the agent lives at a safe distance by default; it joins my network as a named, approved, revocable guest; it travels a private road instead of the public internet; and at the end of the road it speaks a bounded tool language to a small server I control, with the dangerous verbs — like "transmit" — simply not built yet.
An agent that can only chat is a novelty. An agent that can reach the bench, carefully, is a colleague.
And there's a selfish footnote I won't pretend isn't part of the appeal: the first thing the agent did on my network was help me listen to the air. If you'd told teenage me — the one taking apart radios — that one day software would sit in a data center, reach through an encrypted mesh into his house, and help him decode the signals flying around his own desk, he'd have had one question.
When do we start?
We started November 7.
