Network policies

Network policies documentation for Harbor.

Often, task authors want to constrain the network access of the agent or verifier during a rollout for security, reproducibility, 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

task.toml

[environment] # default unless overridden by [agent] or [verifier]
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 policy across phases in the shared sandbox

In this example, downloading and installing the agent still works because agent.setup() uses the public [environment] baseline. [agent] applies only to agent.run(). If a phase has no override, it inherits its sandbox’s baseline policy.

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³, podman³, daytona, e2b, langsmith, tensorlake, cwsandbox, wandb, runloop, modal¹, gke², ec2, novita, islo, blaxel, opensandbox, skypilot, beam, hyperbrowser, vercel⁷
allowlist	Network access only to targets listed in allowed_hosts; empty or omitted hosts deny all egress.	docker⁴, podman⁴, daytona¹, e2b, langsmith, islo, runloop, modal¹, novita¹, blaxel¹, beam⁵, tensorlake⁶, hyperbrowser, vercel⁷

Provider-specific limitations

¹ Single-container tasks only (not in Docker Compose mode).
² Docker Compose (multi-container) tasks only.
³ Docker and Podman support requires Linux containers; Windows containers do not support this network policy mode.
⁴ Docker and Podman support requires Linux containers and local 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.
⁶ TensorLake allowlists accept exact hostnames, leading-wildcard hostnames (a wildcard matches subdomains at any depth but not the apex domain), IPv4 literals, and IPv4 CIDR ranges, but not IPv6 targets.
⁷ Vercel allowlists are available for single-container tasks only. They match domain rules on the TLS SNI, accept exact and leading-wildcard hostnames but not IP literals or CIDR ranges, and deny plain-text HTTP to an allowlisted host. The policy applies from sandbox creation and can be updated on a running sandbox. Compose tasks support public and no-network only.
⁸ Islo supports dynamic network policy only when no custom gateway profile or gateway configuration is supplied.

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⁴, podman⁴, daytona¹, e2b, islo⁸, modal¹, novita¹, beam⁵, hyperbrowser, vercel⁷, tensorlake⁶
[verifier]	Network access during verify() phase. This requires the environment provider to support dynamic network policy switching. This overrides the [environment] baseline.	docker⁴, podman⁴, daytona¹, e2b, islo⁸, modal¹, novita¹, beam⁵, hyperbrowser, vercel⁷, tensorlake⁶
[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³, podman³, daytona, e2b, langsmith, tensorlake, cwsandbox, wandb, runloop, modal¹, gke², ec2, novita, islo, blaxel, opensandbox, skypilot, beam, hyperbrowser, vercel⁷
network_allowlist	The environment can restrict egress to configured allowlist entries (allowlist).	docker⁴, podman⁴, daytona¹, e2b, langsmith, islo, runloop, modal¹, novita¹, blaxel¹, beam⁵, tensorlake⁶, hyperbrowser, vercel⁷
network_allowlist_hostnames	The environment can enforce exact hostname entries in allowed_hosts.	docker⁴, podman⁴, daytona¹, e2b, langsmith, islo, runloop, modal¹, novita¹, blaxel¹, beam⁵, tensorlake⁶, hyperbrowser, vercel⁷
network_allowlist_wildcard_hostnames	The environment can enforce leading-wildcard hostname entries in allowed_hosts.	docker⁴, podman⁴, daytona¹, e2b, langsmith, runloop, modal¹, novita¹, blaxel¹, hyperbrowser, vercel⁷, tensorlake⁶
network_allowlist_ipv4_addresses	The environment can enforce IPv4 address literal entries in allowed_hosts.	docker⁴, podman⁴, daytona¹, e2b, modal¹, novita¹, beam⁵, tensorlake⁶, hyperbrowser
network_allowlist_ipv6_addresses	The environment can enforce IPv6 address literal entries in allowed_hosts.	docker⁴, podman⁴, beam⁵
network_allowlist_ipv4_cidrs	The environment can enforce IPv4 CIDR range entries in allowed_hosts.	docker⁴, podman⁴, daytona¹, modal¹, novita¹, beam⁵, tensorlake⁶, hyperbrowser
network_allowlist_ipv6_cidrs	The environment can enforce IPv6 CIDR range entries in allowed_hosts.	docker⁴, podman⁴, beam⁵
dynamic_network_policy	The environment can switch the active network policy after start, enabling [agent] and [verifier] phase overrides.	docker⁴, podman⁴, daytona¹, e2b, islo⁸, modal¹, novita¹, beam⁵, hyperbrowser, vercel⁷, tensorlake⁶

Full feature grid

Capability	docker	podman	daytona	e2b	langsmith	tensorlake	cwsandbox	wandb	runloop	modal	gke	ec2	novita	islo	blaxel	opensandbox	skypilot	beam	hyperbrowser	vercel
disable_internet	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓
network_allowlist	✓	✓	✓	✓	✓	✓			✓	✓			✓	✓	✓			✓	✓	✓
network_allowlist_hostnames	✓	✓	✓	✓	✓	✓			✓	✓			✓	✓	✓			✓	✓	✓
network_allowlist_wildcard_hostnames	✓	✓	✓	✓	✓	✓			✓	✓			✓		✓				✓	✓
network_allowlist_ipv4_addresses	✓	✓	✓	✓		✓				✓			✓					✓	✓
network_allowlist_ipv6_addresses	✓	✓																✓
network_allowlist_ipv4_cidrs	✓	✓	✓			✓				✓			✓					✓	✓
network_allowlist_ipv6_cidrs	✓	✓																✓
dynamic_network_policy	✓	✓	✓	✓		✓				✓			✓	✓				✓	✓	✓

Provider-specific limitations

¹ Single-container tasks only (not in Docker Compose mode).
² Docker Compose (multi-container) tasks only.
³ Docker and Podman support requires Linux containers; Windows containers do not support this network policy mode.
⁴ Docker and Podman support requires Linux containers and local 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.
⁶ TensorLake allowlists accept exact hostnames, leading-wildcard hostnames (SDK 0.5.110+; a wildcard matches subdomains at any depth but not the apex domain), IPv4 literals, and IPv4 CIDR ranges, but not IPv6 targets.
⁷ Vercel allowlists are available for single-container tasks only. They match domain rules on the TLS SNI, accept exact and leading-wildcard hostnames but not IP literals or CIDR ranges, and deny plain-text HTTP to an allowlisted host. The policy applies from sandbox creation and can be updated on a running sandbox. Compose tasks support public and no-network only.
⁸ Islo supports dynamic network policy only when no custom gateway profile or gateway configuration is supplied.

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.

Why phases?

Often, task authors want to enforce different network policies for the agent (or verifier), 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.