Identity Is the Network

A friend at my church brought an old Mac in a few weeks ago. He wanted to run n8n on it and turn it into our congregation's AI experimentation ground — automating the tedious stuff: rosters, reminders, the small administrative debt every volunteer organization accumulates. Reasonable idea. Then he had to answer the question every home-lab builder eventually hits: how do you let people reach a service running on a machine sitting behind your gateway, without opening that gateway to the entire internet?

He had a Synology NAS already, so he did what a lot of careful people do — he put the NAS's VPN server in front of the Mac and decided nobody talks to n8n unless the VPN tunnel is up. Sound instinct. And it's exactly where I want to start, because the failure mode he was avoiding, and the one he stepped into instead, are both symptoms of the same disease: we've been authenticating devices and networks when we should have been authenticating people.

The Hole You Dig Either Way

The alternative to VPN is remote desktop — RDP or VNC into the Mac directly. It's tempting because it needs zero client setup. Point a browser or a thin client at an address, type a password, done. Which is exactly the problem: "point an address at it" means the address has to be reachable, which means a port has to be open on the gateway, forwarded to a machine inside your private network. Every scanner on the internet finds that port eventually. RDP has one of the worst exposure track records in networking — it's a perennial top vector in ransomware post-mortems precisely because it's a direct, authenticated-at-the-endpoint tunnel into a box that usually has broad filesystem and process access. You're not exposing "a service." You're exposing a full desktop session.

So VPN is the correct instinct. Terminate access at the tunnel, not at the app. But now you've traded one problem for a slower, more annoying one. A VPN needs a client. Someone has to download WireGuard or OpenVPN, import a config file, and — this is the part that kills adoption in a volunteer organization — understand what a config file is. And on the network side, you often still need to open a UDP port on the gateway for the VPN server to be reachable from outside, which means someone has to know what port forwarding is and be trusted to touch the gateway's admin panel to set it up.

None of this is hard for an engineer. It is completely opaque to the person in your church who just wants automated reminders to go out on Tuesdays. And that's the actual constraint: whatever you build has to be operable by people who will never read a networking doc.

Reframing the Problem

Here's the thesis: the friction in both remote desktop and VPN isn't a UX problem you can smooth over with a nicer wizard. It's a modeling problem. Both approaches treat authentication as something that happens to a device at a location — this IP, this port, this machine's private key, configured once, sitting there as a static grant. Change the device, change the network, add a new person, revoke an old one, and you're back into the gateway's admin panel, hand-editing config.

The fix isn't a better VPN client. It's moving the unit of trust from "this device on this network" to "this account, verified continuously, wherever it happens to be." Once identity is the thing being checked — not location, not a static tunnel config — the network topology becomes an implementation detail the system manages for you instead of a thing your users have to reason about.

How Ubiquiti Actually Does This

This is the part I've been close to, because I lead the SSO team at Ubiquiti, and I want to describe it precisely rather than just gesture at "the cloud does it."

Ubiquiti's newest answer to this is UniFi Fabric, a concept the company rolled out only this past year: a set of identities, not the gateway, now governs a set of devices. You bind your consoles into a Fabric, and access to whatever's running behind them becomes a property of who you invite, not a config file you hand out. VPN comes built into that model, not bolted onto it.

Once that's live, granting my friend access to the n8n box isn't "give him the VPN config file." It's assigning a role to a person in Site Manager's People view. The moment a role or permission lands on someone, UniFi automatically sends them an invitation to the UniFi Endpoint app — the identity client, on desktop and mobile — with a 2FA code baked into onboarding. He installs the app, authenticates once, and from that point on the app itself is the credential. No config file changed hands. No port was opened for him personally.

The VPN leg specifically is handled by Teleport, which is where the "no port forwarding" claim actually earns itself. Teleport uses WireGuard, but instead of requiring the gateway to be directly reachable from the internet, the gateway maintains an outbound connection to Ubiquiti's cloud relay. When my friend's device wants in, the connection is brokered through that relay — the gateway never needed an open inbound port, because it never needed to be reachable; it only ever had to reach out. That's the same trick NAT traversal and reverse tunnels have always used, just packaged so nobody has to know the word "NAT traversal" to benefit from it.

Stack those two things and you get what my friend actually wanted: invite a person, they get one-click VPN, the gateway's attack surface never grew, and nobody had to be taught what a port is.

This Isn't New — It's BeyondCorp for Your Garage

I want to be honest about what's genuinely novel here versus what's good packaging. The underlying idea — stop trusting network position, verify identity and device posture on every request — is Zero Trust Network Access, and it's been enterprise doctrine since Google published the BeyondCorp papers describing how they let employees work from any network, coffee shop included, without a traditional VPN, by making every request prove who was making it. "Never trust, always verify," identity as the new perimeter — none of that language is new, and none of it originated at Ubiquiti.

What's actually happening is that a decade of enterprise-grade identity infrastructure — IdP federation, continuous authorization, cloud relay for NAT traversal — is getting compressed into a product a single person can operate for their home network or their church's spare Mac. That compression is the real story of the AI home-lab moment: the people spinning up n8n or a local LLM on hardware in a closet are, without necessarily knowing it, recreating the access-control problem that enterprises spent ten years and considerable headcount solving. They just don't have a security team. The gateway vendor becomes the security team, by default, whether it wants the job or not.

The Security Surface You're Actually Choosing

Here's the part of the argument I'd push back on if I heard someone else make it uncritically: shifting authentication from per-device config to account identity doesn't remove risk, it concentrates it. A leaked WireGuard config compromises one tunnel to one machine. A compromised account, once role-based and federated across WiFi, VPN, and door access, is a much bigger blast radius if it falls into the wrong hands. Centralizing identity is a bet that you can secure the few things that matter — MFA, session policy, anomaly detection on the identity provider — better than you could secure the many things that used to be scattered: a dozen device configs, a dozen static keys, a port-forward rule someone added in 2019 and forgot about.

I think that bet is correct for the overwhelming majority of people, not because account compromise is rare, but because it's a legible risk. You can reason about "is 2FA on, is the session policy sane, has this account done anything unusual." You cannot reason about "which of the forty devices that ever got a VPN config still has it, and is that laptop still in the drawer it was left in." Distributed, invisible trust grants are harder to audit than one well-guarded identity, even though the identity is a scarier single point of failure on paper. Ninety percent of people are safer trusting one strong lock than managing forty forgotten ones — the other ten percent, running real infrastructure at scale, still need the layered device posture and network segmentation that pure identity-centric models compress away. That's a real tradeoff, not a solved problem, and anyone telling you identity-first access has no downside is selling you something.

What This Has to Do With AI Infrastructure

Ubiquiti sells switches, gateways, cameras, WiFi access points. It sells zero AI products. And yet the exact pattern I watched solve my friend's church-automation problem is the pattern every AI home lab and, at a different scale, every AI factory is going to need: a growing population of self-hosted services — n8n instances, local inference servers, agent runners — sitting on private networks, that need to be reachable by specific people without turning the network inside out. Nobody wants to hand-configure a VPN client for every teammate who needs to hit an internal model endpoint, and nobody wants that endpoint exposed to the raw internet either.

The companies that end up mattering to the AI infrastructure stack won't only be the ones selling GPUs and model weights. Some of them will be the ones that already figured out how to make "only the right person, from anywhere, with zero manual network configuration" a one-click default instead of a networking elective. My friend never once thought about IP addresses, VPN clients, or port forwarding to get his automation ground running securely. He thought about who he wanted to invite. That's the interface AI infrastructure needs at every layer above the silicon, and it's a stranger thing than it should be that the company already building it is one nobody associates with AI at all.