Running LM Studio Locally Doesn't Mean It Never Connects Out

Running LM Studio locally does not mean it remains completely disconnected from the network. While inference can indeed occur entirely on the PC, the application itself possesses network-capable features. Software like LM Studio might necessitate connectivity for tasks such as searching for models, downloading models and runtimes, checking for application updates, and more.

Additionally, it could expose a local API server, connect to MCP servers, enable CORS, or serve the API to devices on the local area network. These features are not inherently problematic, but they require careful consideration when aiming for a more narrow environment.

My goal was to achieve a specific setup: local execution of the model with minimal external connectivity. I treated "local execution" and "network isolation" as two distinct issues. For typical use, I envisioned this configuration: LM Studio | +---- 127.0.0.1 / localhost ---- allowed | +---- LAN ----------------------- blocked | +---- Internet ------------------ blocked.

It is crucial to understand the significance of the loopback connection. Restricting all communications blindly can also disrupt internal machine communications. Thus, the rule became to deny external communication while explicitly permitting loopback.

Configuration does not inherently define the security boundary. LM Studio offers useful settings by default, so I disabled features I did not require for this evaluation. This includes disabling features like serving on the local network, CORS per-request, MCP, MCP servers from mcp.json, cloud features/web search, automatic model switching, or unexpected model loading. I also opted to keep the API server off, as it was unnecessary for my evaluation.

To enhance the security of the environment, I implemented two layers: LM Studio settings combined with OS network controls. The first layer sets the intended configuration, while the second enforces the security boundary. These settings can be modified, so I also ensured that the OS network controls remained in place. The setup and normal-use phases were separated to address this.

During setup, network access is temporarily enabled for actions that genuinely require it, such as installing LM Studio, downloading the approved runtime, downloading the approved model, and verifying the files. Afterward, the environment undergoes a different phase, where normal use does not necessitate model discovery or downloads.

Another essential consideration was avoiding the misconception that because LM Studio is approved, any model within it is automatically approved. These are two separate decisions. At startup, I first unload existing models using the command `lms unload --all`, then load the approved model using `lms load approved-model --context-length 8192 --identifier approved-model`.

The startup wrapper verifies that the expected model is available before proceeding. If the desired state cannot be established, the startup should fail rather than silently revert to another configuration. This small adjustment significantly enhances reproducibility. If you require the API server, my current use case does not necessitate it, so I leave it disabled.

However, LM Studio's CLI allows explicitly binding the server to loopback using the command `lms server start --bind 127.0.0.1 --port 1234`. This differs significantly from `lms server start --bind 0.0.0.0`, as the latter makes the server accessible beyond localhost and substantially alters the security boundary. For a controlled local evaluation, exposing the server would only be appropriate if there is a concrete reason to do so.

To validate the configuration, I included checks to observe the actual behavior, such as identifying processes listening on ports, detecting unexpected external connections, verifying whether the API server is running, checking MCP configuration changes, determining which model is loaded, identifying any unexpected GGUF files, and ensuring that firewall rules are still present.

This approach ensures that the configuration aligns with the intended behavior. In summary, while "local" indicates where the model inference takes place, it does not necessarily imply network isolation. To achieve both local inference and network isolation, I designed the system to prepare with network access while connected, then run with the outside closed and only permit the communication that must remain within the machine.

This approach provides a smaller operational boundary around the model, ensuring a more secure environment for evaluation.