Network Segmentation in Practice: How I Separate My Work Environment, Test Lab, and Local AI

What Can a Compromised System Still Reach?

My lab runs deliberately vulnerable applications. It also includes Windows and Linux systems, Active Directory environments, and web applications on which I carry out security tests. A machine being fully compromised can be an intended part of the process.

That should not turn my work environment into another practice target.

This is why I run my work environment, management, lab, local AI, and storage in separate VLANs. I have already outlined the basic setup in my LinkedIn post. Behind it is a question that matters more to my work than the number of networks configured:

What can a machine still reach once it has been compromised?

This is relevant to clients, too. A penetration test can involve internal documentation, test credentials, source code, or information about vulnerabilities that have not yet been fixed. Anyone providing that level of access is entitled to ask about the service provider’s work environment.

In my view, “I have a firewall” would not be an adequate answer. The boundaries between systems, the access rights that remain, and the exceptions needed for day-to-day work are what matter.

Why I Separate Systems by Purpose and Risk

A business work environment has different requirements from a security testing lab. In the lab, I want to understand behaviour, change configurations, and sometimes put systems into an insecure state. In my work environment, I need reliable processes.

Local AI raises its own questions: What information is being processed? Which tools are available to an agent? Is the environment allowed to initiate external connections?

I therefore distinguish between the following areas:

Systems are assigned according to their purpose. The fact that two machines use the same operating system is not a convincing reason to give them the same network environment and the same access rights.

For a test machine, I have to expect a successful compromise. For management access, I need to consider how far-reaching the changes it permits can be. For a storage service, the focus is on which information is accessible and what permissions govern access to it.

Separation provides the basis for reflecting these differences in technical controls. It does not, however, replace decisions about which connections should be permitted between the areas.

What VLAN Separation Actually Achieves

A VLAN creates a logically separate network at the data link layer, or Layer 2. This makes it possible to separate devices even when they are connected to the same physical switch, for example. In a typical routed setup, communication across a VLAN boundary requires a routing point between the networks. Firewall rules can control traffic at that point.¹

The VLAN number itself does not determine whether access is required for a business purpose. If all connections between the networks are then broadly permitted, little of the security benefit remains.

My rule for these connections is therefore that each one needs a specific purpose. That purpose must determine the source, destination, service, and, where relevant, how long access is permitted. The underlying principle is called default deny: a connection is not allowed unless a matching rule explicitly permits it. This restriction applies to both inbound and outbound traffic.²

A simplified example: if an application needs to reach a particular internal service, that initially establishes a requirement for precisely that connection. It does not imply a need to give the application access to the entire destination network. Still less does it imply that every other system on its source network needs the same permissions.

There is also work to do within a VLAN. Devices there can normally communicate directly without traffic passing through the central router. A firewall between VLANs therefore does not automatically control every connection within an area. Depending on the level of protection required, additional boundaries are needed, for example on the individual system or within the application.¹

A lab VLAN therefore does not mean that all experiments running within it should trust one another.

A Permitted Connection Is Not a One-Way Street

When planning network rules, it is easy to overlook the fact that the direction in which a connection is initiated is not the same as the direction of all the data flowing through it.

Suppose an authorised workstation is allowed to access the web interface of a service in another area. A stateful firewall tracks this connection and allows the associated responses back through. The service does not need general permission to initiate new connections to the workstation for this to happen.³

That says nothing, however, about whether its responses can be trusted. The browser still processes content from that service.

For me, this means that permitting access to a single service limits the reachable attack surface. It does not automatically make the permitted communication path harmless. The client application and the service it accesses remain part of the security assessment.

This also matters for local AI. A system without unrestricted internet access can still provide information to an authorised user through a permitted interface. Whether that information is intended for the user must be decided by the application. Network location alone cannot resolve this.⁴

This is precisely why I prefer to discuss specific access rights rather than broadly “trusted” networks.

Why Management Gets Its Own Area

The management plane of my infrastructure is separate from the lab. The reason for this goes beyond separating two ordinary applications.

Access to a test application initially affects that application and its environment. Access to a hypervisor with sufficient privileges, however, can allow changes to multiple virtual machines, their network connections, and their resources. Anyone able to administer the infrastructure can therefore potentially change its existing boundaries as well.

Proxmox plays a role in my setup. Virtualisation allows me to run different test environments. It also means that I have to treat the underlying platform as a shared component of the security architecture. Among other responsibilities, the hypervisor manages access to resources and maintains isolation between virtual machines.⁵

A separate management VLAN initially provides logical separation. It would be wrong to infer a fully independent or physically isolated administration environment from that alone. Protection also depends on which systems can reach the management services and which permissions apply there. Restricting administrative access to designated systems and networks is also part of established hardening guidance.²

Virtual networking adds another consideration. A network diagram can look tidy on paper yet no longer match the actual configuration. An additional virtual network interface or a differently assigned virtual bridge may change the available paths. The assessment therefore cannot stop at the physical switch; virtual networks and the connections between them are part of it.⁶

I therefore see VLAN separation as one layer of protection. It does not remove the dependency on a correctly operated virtualisation platform.

Local AI Gets No Special Status

My locally hosted AI models have their own network segment. The fact that they run on my own infrastructure is not a reason to trust them more than other applications.

Running locally initially answers the question of where computation takes place. Which data an application can access and which actions it may perform are separate decisions.

Outbound Connections Remain Restricted

In my current AI lab, the agent is not allowed to communicate freely with external systems. Outbound traffic, often called egress, is strictly controlled.

If external access were necessary, for example for updates, I would at most consider a separately restricted route through a proxy with explicitly approved destinations. This would not give the agent general internet access. In my view, a need for software updates does not justify permanently allowing a running application to make arbitrary outbound connections.

Such permissions do, however, require precision. “Only certain URLs” is technically different from “only certain domains”. A proxy that merely forwards an HTTPS connection as a tunnel cannot simply inspect the full requested URL path. With the usual CONNECT method, the destination is initially specified as a hostname and port; the subsequent connection may be encrypted end to end.⁷

Any claimed restriction must therefore match what the control in use can actually observe and enforce. The word “proxy” alone tells us very little about that.

The starting point for my AI zone is accordingly restrictive: the agent has no unrestricted communication path to the internet. Any exceptions require separate justification.

Network Access and Agent Permissions Are Two Different Things

A valid point was raised under my VLAN post on LinkedIn: a network boundary does not determine what an agent is allowed to do within a service it can reach.

An example makes the distinction clear. If an agent has access to a document service, the firewall can allow or block the connection to that service. Whether the agent may only read a document, overwrite it, or delete it depends on the functions made available and the permissions of the identity it uses.

Unwanted changes to locally accessible data do not require internet access.

Restrictions must therefore also apply to tools and target systems. A task that only requires reading does not need a delete function. The decision about whether an action is permitted must not be left to the language model alone. OWASP addresses this combination of excessive functionality, permissions, and autonomy under the term Excessive Agency.⁸

I do not currently run an additional proxy in my AI lab that evaluates the appropriateness of every individual agent action before execution. For the current scope, I consider such an additional component unnecessary operational overhead.

That does not make network segmentation equivalent to action-level controls. A restricted network segment does not replace permission checks within a reachable service. If an agent’s purpose changes, its access rights would also need to be reassessed.

What Separation Means for Client Data

For clients, the question that ultimately matters is not how many VLANs exist. It is whether an experiment, a test machine, or an additional tool can access information it does not need for its task.

A dedicated storage network only partially answers that question. It can limit network access to storage resources. The service itself must determine which directories or documents an authorised identity may actually read.

A simple counterexample illustrates this: if a test system could reach a network drive and mount it with extensive write permissions, the separate storage VLAN would not revoke those permissions. The access would already have been granted. Similarly, membership of an internal network is not sufficient grounds for trust; authentication and authorisation remain separate tasks.⁴

For my work, it is therefore important to keep these questions distinct. Network separation, project permissions, and the handling of working copies are related, but they are different measures.

The presence of local AI, for example, does not answer whether certain project information should be processed there. Likewise, a separate storage network says nothing about how long documents are retained or who may still access them after a project ends.

For me, these points belong in the discussions when agreeing an engagement. A technical description of the infrastructure should support that discussion rather than replace it with blanket security promises.

Why a Storage VLAN Is Not Yet a Backup Strategy

Network segmentation also does not establish recoverability.

A storage system in its own VLAN may still be reachable through a permitted service or with valid credentials. If backups can also be modified or deleted through that access, network separation alone does not adequately protect them.

A backup strategy therefore needs to answer additional questions: Which identity may delete backups? Which copies remain inaccessible if the work environment is compromised? And can those copies actually be restored? CISA recommends measures including encrypted offline backups and regular recovery tests.⁹

The same applies to logs. A firewall log can show that a connection was allowed or dropped. Establishing what happened within a permitted application session may require additional logging at the application level. Protecting and analysing those logs are also separate tasks.⁹

I would therefore not infer either full recoverability or a complete audit trail of all activity from the statement “management and storage are separate”.

How to Assess Whether Separation Works

A network architecture must produce expectations that can be tested. The statement “the lab and work environment are separate” is still too vague for that purpose.

A specific test question might be whether a lab machine can reach a management service it should not be allowed to access. Another might be whether an authorised workstation can use the intended application service without gaining access to other services on the same system.

A failed connection attempt is not sufficient evidence on its own. The target service might not be running at that moment. The destination address might be wrong. A meaningful test must distinguish between the intended security control preventing access and some other prerequisite simply being absent.

The starting point is equally important. A successful test from the work environment does not automatically describe what a machine in the lab can do. Other active network paths, such as a second network interface or IPv6, must be included in the assessment. Otherwise, only part of the actual reachability is being tested.

Changes to firewall rules must also take existing connections into account. Stateful firewalls may continue handling established sessions until their states expire or are removed. A new rule and an ongoing connection may therefore not immediately produce the same behaviour.³

These considerations give me a practical benchmark: separation is meaningfully described when it is possible to explain why a particular access is possible, where its boundary lies, and how that boundary can be verified. The actual virtual network configuration is just as much a part of this assessment as the intended firewall rules.⁶

What Matters to Me as a Service Provider

I run a test lab because I want to understand technical relationships for myself and investigate them in practice. This includes environments that are deliberately configured insecurely. Separating my work environment, management, lab, AI, and storage reflects these different approaches to risk.

It is not a promise that my infrastructure can never have a vulnerability or configuration error. Its purpose is to limit dependencies and avoid unnecessarily increasing the potential impact of a mistake.

I consider this distinction important for clients. I should be able to explain how I work, including the limitations. That also means being open about which question a measure answers and which it does not.

Anyone giving me access to their application is therefore entitled to ask how I handle that information. For me, the technical work environment belongs in that conversation just as much as the test scope, the access required, and the eventual handover of results.

Technical References