Network Mode
NETWORK is the opt-in mode. The containers are given an external network connection so the agent can reach the internet — useful for fetching API documentation, contacting a remote resource, or running a network-dependent test. The point of NETWORK mode is that turning it on is a deliberate, conscious choice, not an always-on default.
What changes
In RESTRICTED mode the containers run on an internal network with no external routes: no outbound path, no egress. In NETWORK mode the containers run on a standard external network instead — a virtual interface with a gateway — and outbound HTTP, HTTPS, DNS, and TCP work as they would for any container.
Workspace isolation does not change. The agent still only sees the directory bind-mounted into the container at session start. The home directory, SSH keys, .env files, and the rest of the host filesystem stay invisible. NETWORK mode reopens one channel — the network — and nothing else.
Switching modes
The mode is a per-session setting controlled by the SITU config file at ~/.situ/situ.conf. Edit that file to set the mode to network; the next session will start with a network-attached pod.
Run a query in NETWORK mode after editing the config:
$ cd ./my-project
$ situ -p "Fetch the latest stripe-node release notes and summarize the breaking changes"
To return to the default, set the mode back to restricted in ~/.situ/situ.conf (or remove the override) and start a new session. Mode is locked for the lifetime of a session — there is no command to flip the network on mid-conversation, by design.
A specific config file can also be supplied for a single run via situ -c <file> — convenient for keeping restricted.conf and network.conf presets side by side and selecting the mode at the command line.
What works in NETWORK mode
| Capability | RESTRICTED | NETWORK |
|---|---|---|
| Outbound HTTP / HTTPS | Blocked | Allowed |
| DNS resolution | None | Standard |
| Package registries (npm, PyPI, crates.io, …) | Unreachable | Reachable |
| Container registries | Unreachable | Reachable |
| LAN services (databases, internal APIs) | Unreachable | Reachable |
| Workspace bind-mount only | Yes | Yes |
| Ephemeral containers, destroyed on exit | Yes | Yes |
When to use NETWORK mode
- Fetching live documentation. Asking the agent to read the official docs of a third-party API and apply them to the codebase.
- Looking up package versions or release notes. Resolving the latest stable version of a dependency, or checking a package's changelog before bumping it.
- Running network-dependent tests. Integration tests that hit a staging endpoint, a database on the LAN, or a mock service over HTTP.
- Pulling a fresh model or container image. Updating the local llama.cpp image or pulling a new GGUF.
When NOT to use NETWORK mode
Treat NETWORK mode as a tool, not a default. Whenever the task does not need the network, switch back. In particular:
- Working with proprietary or regulated source code. If the data should not leave the machine under any circumstance, do not give the pod a network. RESTRICTED is the only correct mode.
- Running an unfamiliar or untrusted model. A model that can be coaxed into making outbound requests is a leakage risk only if there is a network to leak through.
- Sessions on untrusted networks. Coffee-shop Wi-Fi, hotel networks, conference Wi-Fi — RESTRICTED removes the attack surface entirely.
- Long-running or unattended sessions. If no one is watching the agent's egress, do not give it a way out.
If a task does not need the network, it should not have one. Open the channel for the task that requires it, complete the task, and close the channel again by returning to RESTRICTED.
Security implications, stated plainly
- NETWORK mode reintroduces a normal network attack surface for the agent process. Outbound exfiltration becomes technically possible — that is what "having a network" means.
- Workspace isolation, ephemeral container lifecycle, and shell-level safeguards remain in place, but the categorical "cannot leak" guarantee of RESTRICTED is, by definition, not present.
- The right mental model: NETWORK mode is a normal sandboxed container. RESTRICTED mode is a sandboxed container whose network has no external routes. Treat them differently.
Verifying the difference
Running situ -t in NETWORK mode produces a different report — the external probes succeed where they would have failed in RESTRICTED. That output is the most direct way to confirm which mode the current session is actually running in.
Related
- Restricted Mode — the default, kernel-level isolation guarantee.
- First Steps — installation, the first isolated session, and network-isolation verification.