> ## Documentation Index
> Fetch the complete documentation index at: https://docs.iearena.org/llms.txt
> Use this file to discover all available pages before exploring further.

# 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

```toml title="task.toml" theme={"system"}
[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"
```

<Frame caption="Network policy across phases in the shared sandbox">
  <img src="https://mintcdn.com/kobe/lMEHI08W1Gq-NdBa/images/netpolicy.png?fit=max&auto=format&n=lMEHI08W1Gq-NdBa&q=85&s=3aaa872b9ecdcd2b354c596425acbdf8" alt="Diagram showing the public environment baseline, the allowlist during the agent phase, and no network during the verifier phase" width="3520" height="728" data-path="images/netpolicy.png" />
</Frame>

<Note>
  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.
</Note>

## 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`⁷                                                            |

<Accordion title="Provider-specific limitations">
  ¹ Single-container tasks only (not in Docker Compose mode).<br />
  ² Docker Compose (multi-container) tasks only.<br />
  ³ Docker and Podman support requires Linux containers; Windows containers do not support this network policy mode.<br />
  ⁴ Docker and Podman support requires Linux containers and local runtime support for the nftables kernel features used by Harbor's egress-control sidecar.<br />
  ⁵ Beam resolves concrete hostnames to IP CIDRs before applying the policy; wildcard host entries are not supported.<br />
  ⁶ 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.<br />
  ⁷ 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.<br />
  ⁸ Islo supports dynamic network policy only when no custom gateway profile or gateway configuration is supplied.
</Accordion>

## 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](/docs/tasks/multi-step).

## 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`⁶                                                                                              |

<Accordion title="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`               | ✓        | ✓        | ✓         | ✓     |             | ✓            |             |         |           | ✓       |       |       | ✓        | ✓      |          |               |            | ✓      | ✓              | ✓        |
</Accordion>

<Accordion title="Provider-specific limitations">
  ¹ Single-container tasks only (not in Docker Compose mode).<br />
  ² Docker Compose (multi-container) tasks only.<br />
  ³ Docker and Podman support requires Linux containers; Windows containers do not support this network policy mode.<br />
  ⁴ Docker and Podman support requires Linux containers and local runtime support for the nftables kernel features used by Harbor's egress-control sidecar.<br />
  ⁵ Beam resolves concrete hostnames to IP CIDRs before applying the policy; wildcard host entries are not supported.<br />
  ⁶ 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.<br />
  ⁷ 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.<br />
  ⁸ Islo supports dynamic network policy only when no custom gateway profile or gateway configuration is supplied.
</Accordion>

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.