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 = "no-network"
[agent]
network_mode = "allowlist"
allowed_hosts = ["pypi.org", "api.openai.com"]
[verifier]
network_mode = "public"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², novita², islo² |
allowlist | Network access to the hosts listed in the allowed_hosts list. | e2b, islo, runloop, modal¹ |
¹ Single-container tasks only (not in Docker Compose mode). ² Docker Compose (multi-container) tasks only.
Phases
Network policies can be specified for the following phases:
| Phase | Description | Supported environments |
|---|---|---|
[environment] | The baseline network policy configured at environment start time. | All³ |
[agent] | Network access during agent.run() phase. This requires the environment provider to support dynamic network policy switching. This overrides the [environment] baseline. | e2b |
[verifier] | Network access during verify() phase. This requires the environment provider to support dynamic network policy switching. This overrides the [environment] baseline. | e2b |
[verifier.environment] | The baseline network policy configured at verifier environment start time, when using a separate verifier environment. | All³ |
³ 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. Three 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², novita², islo² |
network_allowlist | The environment can restrict egress to configured hostnames (allowlist). | e2b, islo, runloop, modal¹ |
dynamic_network_policy | The environment can switch the active network policy after start, enabling [agent] and [verifier] phase overrides. | e2b |
¹ Single-container tasks only (not in Docker Compose mode). ² Docker Compose (multi-container) tasks only.
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.