Scaling a platform from a dozen users to thousands exposes every shortcut you took in your network architecture. The tools you chose matter less than the principles behind them - and getting those principles wrong early means painful rework later. Jay Stapleton, a Solutions Engineer at Tailscale, shares a framework for designing networks that stay flexible, secure, and manageable as your platform grows.

Main insights

• Zero trust networking - where every connection is verified by identity before access is granted - must be the foundation of your architecture, not an afterthought added after migration.
• Networks are defined by their policies and architecture, not by their physical components or the specific tools you use to build them.
• Removing services from the public internet reduces your attack surface more effectively than trying to defend everything exposed to it.
• Observability must be built in from day one - you cannot retrofit visibility into a network that was never designed for it.

Jay brings decades of hands-on networking experience, from soldering 10Base-2 coaxial cables in the 1990s to designing zero-trust architectures for modern distributed platforms. He has also worked as a college professor and run a coffee shop - experiences he credits for sharpening his ability to explain complex technical concepts clearly. You can watch the full discussion here if you missed it.

The fundamentals never change, even as tools evolve

Jay frames every network architecture decision around three principles that have held constant across decades of change: connect what needs to be connected, don't connect what doesn't need to be connected, and maintain visibility into what's happening.

"The network needs to connect the things that need to be connected. It needs to not connect the things that don't need to be connected. And it needs to have some mechanism for visibility into what's connected and what's not and who's doing what and where and why," Jay explains.

These principles apply whether you're managing a startup's first cluster or a global enterprise network. What changes is the complexity of the technical debt you accumulate along the way - old servers, unpatched systems, and forgotten corners that go unexamined for years.

Jay uses the Ship of Theseus thought experiment to make a critical point: if you replace every cable, switch, and VPN link in your network, is it still the same network? His answer is yes - because what defines your network is the policies and architecture you use to build it, not the collection of physical parts. This reframe matters enormously when modernizing infrastructure. Organizations that treat migration as a hardware swap miss the opportunity to adopt modern capabilities like conditional access and identity-based policies. The goal isn't to replicate your old VPN architecture with new tools. It's to rethink the architecture entirely.

Identity enforcement must happen at authentication time

The most common mistake Jay sees during zero trust migrations is treating identity as a cleanup task. Teams complete the "big lift" of moving off legacy VPN hardware, then plan to fine-tune access policies afterward. A year later, very little has changed.

Identity must be the foundation, not a finishing touch. Tailscale integrates with existing identity providers - Okta, Microsoft Entra, or any OIDC-compatible provider - rather than creating a parallel identity system. This matters because, as Jay puts it: "Identity is a hard problem. It's incredibly complex. It's a difficult thing to get right 100% of the time and it's very problematic if you get it right 99% of the time."

Once a user authenticates, that identity follows every connection they make. In Tailscale's implementation, identity is cryptographically bound to a user's IP address, enabling granular policy enforcement. You can specify that a developer can SSH into a production web server from their workstation but not from their phone, or that anyone accessing production systems must have disk encryption enabled and be enrolled in your MDM tenant. These aren't configurations you layer on later - they're decisions you make at design time.

Policy as code: Your network's source of truth

Jay recommends managing network policies through code rather than graphical interfaces. While GUI editors are useful for exploration, most teams implement policies through GitOps workflows, Terraform, or direct API calls - leveraging the code review, approval workflows, and version control they've already built.

"What this file is, is your source of truth of what the network looks like and who's allowed to connect to which endpoints and under what conditions," Jay explains.

This approach also enables the perspective network concept. In a mesh network where all devices can theoretically reach all others, each device sees a different logical network based on who's logged in and what policies apply to them. A developer might see development and staging environments. A database administrator sees production databases. The same physical network presents different views based on identity and policy - and all of it is auditable, testable, and reproducible from a single policy file.

Reduce attack surface by removing public exposure

Jay uses the metaphor of water droplets naturally minimizing their surface area to describe a core security principle: pull services off the public internet wherever possible. The motivation is practical. "When you look at the logs, a lot of your traffic, sometimes 90% of your traffic, is automated attacks against your systems," he notes.

Keeping systems patched and following best practices helps, but the pace of AI-powered vulnerability scanning is making it harder to stay ahead. "With these agentic analysis tools churning out vulnerability POCs very quickly, it's hard to keep up to date with public-facing endpoints," Jay warns.

Moving services behind a private, encrypted mesh network with identity-based access eliminates most of this noise. Only authenticated, authorized users can attempt a connection in the first place. This doesn't replace defense in depth - it dramatically reduces the surface area you need to defend.

Build observability in from day one

Observability isn't something you add when something breaks. Jay treats it as a first-class requirement: "Having observability tools in place is one of my very high priority checkboxes whenever I'm building out a new network."

In practice, this means capturing network flow logs that record who connected to what, when, and how much data transferred. When something looks anomalous, you need the ability to investigate - not just detect. Tailscale's integration with Grafana Cloud illustrates the pattern: telemetry flows to a SaaS observability platform without exposing internal systems to the public internet. The same zero trust principles that protect your workloads protect your monitoring pipeline.

Agentic systems fit into existing network patterns

When asked how AI agents change network design priorities, Jay's answer is refreshingly direct: they don't, fundamentally. "The way that agents behave over networks I feel is a lot more flexible, partly because the agent isn't going to care about latency the same way a user on a Zoom call is going to care about latency."

He uses the analogy of filling a jar with ball bearings, then sand, then water. Agent traffic - small, frequent API requests - fills the gaps between human-driven workloads the way sand fills space between ball bearings. Your network should already be optimized for human use patterns; agent traffic uses the available capacity.

For agent identity specifically, Jay recommends treating agents as separate entities with their own tagged identities rather than extensions of user accounts. This enables fine-grained access control, better observability, and cleaner audit trails. Tools like Tailscale's Aperture LLM gateway can enforce policies on agent behavior, set cost guardrails, and provide session playback for security reviews.

​

If you enjoyed this, find here more great insights and events from our Platform Engineering Community.

For more comprehensive guidance, check out the Platform Engineering Certified Architect Course and learn best practices from industry experts.

Key takeaways

• Prioritize identity from the start: Don't treat identity-based access control as a post-migration cleanup task. Integrate with your existing identity provider and enforce authentication before granting any network access - this decision is much harder to retrofit than to build in from day one.
• Define your network by policy, not hardware: Your network's identity lives in its policies and architecture, not its physical components. Managing policy as code gives you auditability, reproducibility, and the ability to modernize continuously without complete rebuilds.
• Remove services from public internet exposure: The most effective security measure available to you is reducing attack surface. Moving services behind a private, encrypted mesh with identity-based access eliminates the majority of automated attack traffic before it ever reaches your systems.
• Implement observability before you need it: Comprehensive logging and monitoring must be part of your initial network design. When you need to investigate an incident or troubleshoot a connection, the data either exists or it doesn't - and you can't go back in time to collect it.