Network Policy
Network baselines, phase overrides, and run-time host allowlists in task.toml
Often, task authors will want to constrain the network access of the agent or verifier during a rollout for security or reward hacking mitigation.
Network policies can be specified in the task.toml file at varying degrees of granularity. How you choose to specify depends on your environment affordances and use case.
Example
[environment]
network_mode = "public"
[agent] # applies during agent.run() -- but *not* during agent.setup()!
network_mode = "allowlist"
allowed_hosts = ["pypi.org", "api.openai.com"]
[verifier] # applies during verifier.verify()
network_mode = "no-network"Network modes
Harbor supports three network modes: public, no-network, and allowlist.
| Network mode | Description | Supported environments |
|---|---|---|
public | Full network access. | All |
no-network | No network access. | docker³, daytona, e2b, langsmith, tensorlake, cwsandbox, wandb, runloop, modal¹, gke², ec2, novita, islo, blaxel, beam |
allowlist | Network access only to targets listed in allowed_hosts; empty or omitted hosts deny all egress. | docker⁴, daytona¹, e2b, islo, runloop, modal¹, novita¹, blaxel¹, beam⁵ |
¹ Single-container tasks only (not in Docker Compose mode). ² Docker Compose (multi-container) tasks only. ³ Docker support requires Linux containers; Docker Windows containers do not support this network policy mode. ⁴ Docker support requires Linux containers and local Docker runtime support for the nftables kernel features used by Harbor's egress-control sidecar. ⁵ Beam resolves concrete hostnames to IP CIDRs before applying the policy; wildcard host entries are not supported.
Local Docker runtime compatibility
Docker no-network, allowlist, and dynamic network policy support require
Docker Linux containers. Docker Windows containers do not expose the Linux
networking primitives Harbor uses for these modes.
Docker allowlist and dynamic network policy support are implemented with an
egress-control sidecar that applies nftables rules. The ruleset uses nftables
fib expressions, including fib daddr type local. In kernel config terms,
the required capability is CONFIG_NFT_FIB_INET=y or
CONFIG_NFT_FIB_INET=m.
On Linux hosts, Harbor assumes the local Docker runtime supports the required
kernel features and lets the Docker environment start normally. On non-Linux
hosts, Harbor probes Docker's Linux VM before enabling Docker egress control. If
the VM exposes /proc/config.gz, Harbor requires CONFIG_NFT_FIB_INET=y or
CONFIG_NFT_FIB_INET=m; if /proc/config.gz is not present, Harbor assumes the
capability exists and lets the runtime report any later nftables failure.
Docker Desktop for macOS runs containers inside a LinuxKit VM whose kernel may
not enable CONFIG_NFT_FIB_INET. When Harbor can detect that missing support,
Docker no-network, allowlist, and dynamic network policy modes are rejected
during environment validation. If a runtime hides its kernel config but still
lacks the feature, nft rejects the ruleset and the sidecar fails during
startup. On macOS, use a Docker runtime whose Linux VM enables
CONFIG_NFT_FIB_INET, such as OrbStack, or run the task on a Linux Docker host.
allowed_hosts entries can be exact hostnames, IPv4/IPv6 address literals or CIDR ranges, or leading wildcard hostnames such as *.example.com, when supported by the selected environment. They are not URLs, bracketed IPv6 addresses, ports, or paths. Bare hostnames are exact: example.com does not grant access to www.example.com. Wildcard apex behavior is provider-dependent. For portable tasks, include both example.com and *.example.com when both apex and subdomains are needed.
Phases
Network policies can be specified for the following phases:
| Phase | Description | Supported environments |
|---|---|---|
[environment] | The baseline network policy configured at environment start time. | Any environment that supports the requested network mode |
[agent] | Network access during agent.run() phase. This requires the environment provider to support dynamic network policy switching. This overrides the [environment] baseline. | docker⁴, daytona¹, e2b, islo, modal¹, novita¹, beam⁵ |
[verifier] | Network access during verify() phase. This requires the environment provider to support dynamic network policy switching. This overrides the [environment] baseline. | docker⁴, daytona¹, e2b, islo, modal¹, novita¹, beam⁵ |
[verifier.environment] | The baseline network policy configured at verifier environment start time, when using a separate verifier environment. | Any environment that supports the requested network mode |
Baseline phases are subject to the environment supporting the requested network mode (see the table above).
These phases can also be specified at the step-level, when using multi-step tasks.
Capabilities
Each BaseEnvironment implementation declares an EnvironmentCapabilities model describing what it can do. The following capabilities govern network policy enforcement:
| Capability | Description | Environments |
|---|---|---|
disable_internet | The environment can run containers without internet access (no-network). | docker³, daytona, e2b, langsmith, tensorlake, cwsandbox, wandb, runloop, modal¹, gke², ec2, novita, islo, blaxel, beam |
network_allowlist | The environment can restrict egress to configured allowlist entries (allowlist). | docker⁴, daytona¹, e2b, islo, runloop, modal¹, novita¹, blaxel¹, beam⁵ |
network_allowlist_hostnames | The environment can enforce exact hostname entries in allowed_hosts. | docker⁴, daytona¹, e2b, islo, runloop, modal¹, novita¹, blaxel¹, beam⁵ |
network_allowlist_wildcard_hostnames | The environment can enforce leading-wildcard hostname entries in allowed_hosts. | docker⁴, daytona¹, e2b, runloop, modal¹, novita¹, blaxel¹ |
network_allowlist_ipv4_addresses | The environment can enforce IPv4 address literal entries in allowed_hosts. | docker⁴, daytona¹, e2b, modal¹, novita¹, beam⁵ |
network_allowlist_ipv6_addresses | The environment can enforce IPv6 address literal entries in allowed_hosts. | docker⁴, beam⁵ |
network_allowlist_ipv4_cidrs | The environment can enforce IPv4 CIDR range entries in allowed_hosts. | docker⁴, daytona¹, modal¹, novita¹, beam⁵ |
network_allowlist_ipv6_cidrs | The environment can enforce IPv6 CIDR range entries in allowed_hosts. | docker⁴, beam⁵ |
dynamic_network_policy | The environment can switch the active network policy after start, enabling [agent] and [verifier] phase overrides. | docker⁴, daytona¹, e2b, islo, modal¹, novita¹, beam⁵ |
¹ Single-container tasks only (not in Docker Compose mode). ² Docker Compose (multi-container) tasks only. ³ Docker support requires Linux containers; Docker Windows containers do not support this network policy mode. ⁴ Docker support requires Linux containers and local Docker runtime support for the nftables kernel features used by Harbor's egress-control sidecar. ⁵ Beam resolves concrete hostnames to IP CIDRs before applying the policy; wildcard host entries are not supported.
Daytona supports hostname/domain allowlists and IPv4 literal/CIDR allowlists, but a single allowlist policy cannot combine hostname/wildcard entries with IPv4 targets, and IPv6 targets are not supported.
If a task requests a network mode the environment does not declare a capability for, Harbor rejects the trial at validation time rather than running with a weaker policy.
EnvironmentCapabilities also declares non-network capabilities (gpus, tpus, windows, mounted, and docker_compose) which are unrelated to network policy.
Why phases?
Often, task authors will want to enforce different network policies for the agent (or verifier) phase, but do not want those policies enforced when setting up an agent in the environment. For example, you may want to be able to install Claude Code into the environment but then turn off all network access except for Anthropic's API during the rollout.
Support
Environment implementations declare whether they support network policy configuration at start time and during runtime. Configuration at start time is more widely supported than during runtime, however, support is growing for both.