The Remote Control Plane

I travel constantly. An AI agent stack that only works when I’m sitting at my desk is useless to me.

I wanted the entire capability in my pocket—accessible from an iPad in a hotel room or an iPhone in an airport terminal, operating at full power 24/7.

The catch: remote access is also the primary vector an attacker wants. Because this machine controls my home HVAC, my financial database, and my personal biometrics, security couldn’t be a feature added at the end. It had to be the foundation.

---

Why public port forwarding is a trap

The naive approach to remote access is opening an inbound port on your home router, setting up a dynamic DNS hostname, and SSHing in with a password.

That is how home networks get annexed into botnets. The second you expose a port to the public internet, automated port scanners hit it continuously. You have to be right every single day; an attacker only has to get lucky once.

My setup uses zero open inbound ports. Zero.

There is no public IP entry point on my network to scan or brute-force.

---

Zero-trust mesh & hardware FIDO2 keys

Instead of opening a public port, every device connects over a private zero-trust mesh using Tailscale.

My Mac Mini host, iPad, and iPhone form an encrypted peer-to-peer network that is completely invisible to the open internet. To authenticate a new device onto the mesh, identity verification is enforced at the hardware layer:

1. Google Advanced Protection Program: My primary identity is enrolled in hardware-enforced authentication. Signing in requires physically tapping a hardware FIDO2 security key (YubiKey).
2. Key-Only SSH Auth: Password authentication on the Mac Mini host is disabled entirely. Access requires a cryptographic key pair over the Tailscale mesh.

No hardware security key means no identity. No identity means no network access. No network access means no entry point to the host.

The result is a stack that is instantly accessible to me anywhere in the world and completely dark to everyone else.

---

Resilient mobile tmux execution

Security controls that create friction get bypassed. The remote architecture has to survive how I actually work—on flaky hotel Wi-Fi, airplane internet, and cellular data switches.

Two tactical design choices make remote terminal access bulletproof:

1. Persistent Headless Session Management (tmux)
Remote agent tasks don’t run inside the ephemeral SSH connection; they execute locally on the host inside a persistent tmux session driven through Termius on my iPad.

When my iPhone drops from 5G to Wi-Fi mid-task—which normally kills an SSH connection with a broken pipe error—the agent keeps running uninterrupted on the host. When I reconnect, a single tap re-attaches to the live terminal session. A long-running multi-step task survives walking through an airport terminal without losing state.

2. Headless Display Emulation
The M2 Mac Mini runs headless without a monitor. macOS scales down GPU performance and throttles background processes when no display is detected. A $7 HDMI EDID dummy plug tricked the OS into detecting a virtual 4K display, keeping GPU hardware acceleration fully enabled 24/7.

---

The enterprise governance lesson

Most organizations approach AI security backwards: they build an agent demo first, and then attempt to bolt governance and access controls on top before launch.

That order of operations is wrong.

I didn’t build this secure control plane and then search for tasks to automate. I built the zero-trust control plane first, because I was never going to grant an AI agent access to my financial ledgers or home infrastructure without a verified execution boundary under it.

Every enterprise exploring agentic AI is facing this exact architectural gate. No executive will grant an agent execution authority over real infrastructure until the underlying control plane is locked down. Build the control plane first—it’s what earns you the confidence to let an agent do real work.