Network segmentation for developer machines: practical isolation

A developer machine is usually a flat trust zone. Git credentials, cloud access keys, browser sessions, and agent tokens all live on one laptop, and any tool that gets compromised gets all of them. Segmentation is the practice of breaking that flat zone into smaller pieces so a failure in one piece does not become a failure in everything. It does not require exotic hardware or a corporate network team: a host firewall, a few network namespaces, and deliberate egress rules deliver most of the benefit. This article covers the practical layers, starting with the machine itself.

Start with the host firewall

Most desktop distributions ship with no inbound firewall rules at all, which means every service listening on a dev machine is reachable from the local network. Set a default-deny policy for inbound traffic, then allow only what you actually use: SSH, a VPN, and little else. ufw makes this a few commands, and nftables gives finer control when you need it. Restrict listening services to the interfaces they need — a database or dev server that should only be reachable from localhost should bind to 127.0.0.1, not 0.0.0.0. Inbound filtering is the cheapest segmentation there is, and it is the one most machines lack.

Isolate by function

Separate workloads that do not need to share a network. A guest Wi-Fi network or VLAN for personal devices keeps them off the work segment entirely. On a single machine, rootless containers or virtual machines give each project its own network namespace: the project’s services, caches, and test databases live in an isolated network that only the project’s container joins. This makes the blast radius of a compromised dev dependency much smaller — the attacker gets the project’s network, not the host’s. Podman and QEMU support per-project networks without administrative overhead, and the pattern works on a laptop as well as a workstation.

Control egress, not just ingress

Segmentation is usually thought of as inbound control, but for developer machines the egress direction matters more. A compromised agent or tool will try to phone home or exfiltrate data, and most machines allow outbound traffic to anywhere. Enumerate the destinations your dev processes legitimately need — package registries, your git remote, your cloud provider’s API endpoints — and deny the rest at the firewall. For AI agent traffic, route API calls through a local proxy that restricts per-host access; a DLP reverse proxy with per-host rules is one way to enforce that an agent can only reach the endpoints you configured. Egress allowlisting turns “the attacker can send your data anywhere” into “the attacker can send your data to the four hosts you already allow.”

Keep credentials off the network boundary

Segmentation cannot help with secrets that are copied everywhere: .env files on shared drives, tokens pasted into chat, keys copied between machines. Keep credentials in a local store and deliver them into processes at run time. A credential broker such as trustless (https://github.com/ikkun1222/trustless) reads an existing pass or Bitwarden store and injects secrets into a subprocess environment, so the secret is created on the machine that needs it and never crosses the network in the first place. Combine that with segmented networks, and the credential is both hard to reach and hard to leak.

Segmentation is a practice, not a project

Networks drift. New tools bind new ports, new agents need new egress destinations, and rules written once go stale. Review the firewall rules, re-check listening ports, and re-verify the egress list on a schedule. The goal is not a perfect diagram; it is that a compromise in one tool no longer implies a compromise of everything on the machine.

What does your machine’s firewall allow right now, and can you name every port that is listening?