Network Policies

A network policy limits outbound traffic only from processes inside an Environment. It does not limit requests made by AgentCompass on the host.

You can control network access separately while an Environment is prepared, while the agent runs, and while the result is verified. For example, setup can download trusted dependencies before the agent is restricted to the files already provided with the task.

Policies for the Three Phases

Task commands run in the task Environment. The Benchmark chooses how verification works: it can verify directly on the host, reuse the task Environment, or create a clean verifier Environment. verifier_network_policy affects only the latter two approaches.

Field	Where it applies
network_policy	The baseline policy. It covers Environment startup, preparation, artifact collection, and other in-Environment operations outside the agent-run and verification contexts.
run_network_policy	Processes inside the Environment while the agent is running.
verifier_network_policy	Verification in either the reused task Environment or a newly created verifier Environment. It does not affect a verifier process running on the host.

network_policy defaults to public. If run_network_policy or verifier_network_policy is omitted, that phase inherits network_policy. A recipe may also supply settings required by its Benchmark. When defining a custom policy, setting all three fields explicitly is the clearest approach.

AgentCompass switches to run_network_policy only after Environment preparation. Trusted dependencies can therefore be installed under the baseline policy before the agent runs under a stricter policy.

Network Modes

Mode	Effect
public	Allows outbound internet access. Use it when a phase must download dependencies or call external services.
no-network	Blocks all outbound network access. Use it when a task must rely only on local files and tools.
allowlist	Allows only the hostnames, IP addresses, or networks in allowed_hosts.

Write public and no-network as strings. An allowlist is an object:

{
  "network_mode": "allowlist",
  "allowed_hosts": [
    "api.example.com",
    "*.assets.example.com",
    "203.0.113.10",
    "203.0.113.0/24"
  ]
}

Each allowlist entry must be one of the following:

• a hostname, such as api.example.com;
• a hostname with the *. prefix, such as *.assets.example.com;
• an IP address; or
• a CIDR range.

Do not include a URL scheme, path, or port. For example, https://api.example.com/v1 is invalid. A CIDR must use its canonical network address: use 203.0.113.0/24, not 203.0.113.10/24. Providers also differ in the address types and number of entries they support; see the support table and provider pages below.

Which Requests Are Controlled

Whether a request is restricted depends on whether the process making it runs on the host or in an Environment.

Request origin	Controlled by the Environment policy?
AgentCompass host process	No. For example, a model API request made by a Harness running on the host is outside the policy.
Process in the task Environment	Yes. The agent and any Harness running there use the current phase policy.
Process in a verifier Environment	Yes. It uses verifier_network_policy.

A model, search, or grading endpoint needs to be allowlisted only when a process inside an Environment calls it. Requests that AgentCompass makes from the host to create or close an Environment are outside this policy.

The policy controls outbound access only. It does not restrict connections entering the Environment from the host or a provider control plane.

Provider Support

Provider	Supported modes	Phase switching	Notes
host_process	public	No	Processes use the host network directly, so network isolation cannot be enforced.
docker	public, no-network, allowlist	Yes	Dynamic switching requires a bridge-style Docker network. An auxiliary egress proxy enforces allowlists.
daytona	public, no-network, allowlist	Yes	Domain and IPv4 network entries cannot be mixed. Daytona also limits the number of entries.
modal	public, no-network, allowlist	Yes	Supports domains, IPv4, and IPv6. Phase switching requires a compatible Modal SDK.

AgentCompass manages Docker’s auxiliary egress proxy automatically. It enforces the allowlist and is not a separate Environment that you need to configure. On an offline host, make sure Docker can access the proxy image in advance.

Daytona accepts at most 20 domain entries or 10 IPv4 network entries. See each provider page for its exact formats, mutually exclusive settings, and prerequisites.

Configure a Policy

The following CLI example passes all three fields through --env-params. See Configure an Environment for configuration-file, Python SDK, and orchestration-file forms. This example permits network access during preparation and disables it during the agent and verification phases:

agentcompass run <benchmark> <harness> "$MODEL_NAME" \
  --env docker \
  --env-params '{
    "network_policy": "public",
    "run_network_policy": "no-network",
    "verifier_network_policy": "no-network"
  }'

To use an allowlist, replace the string for the relevant phase with an allowlist object:

{
  "run_network_policy": {
    "network_mode": "allowlist",
    "allowed_hosts": ["api.example.com"]
  }
}

When configuring a policy for the first time, run one task before increasing concurrency. This makes missing redirect, artifact-delivery, or authentication hostnames easier to identify.

Verify the Policy

Run a test task with predictable behavior and --file-log-level DEBUG. These log fields show the final resolved shared policies for setup, the agent run, and verification:

• setup_network_mode
• run_network_mode
• verifier_network_mode

If the task lets the agent execute terminal commands, also test one address that should be allowed and one that should be blocked. Make sure the requests originate inside the Environment; running the same command on the host does not test an Environment policy.

A single failed request is not proof that isolation is active. DNS resolution, credentials, or an unavailable service can produce the same result, so check the shared policies in the logs as well. If provider-native network fields are also configured, use the provider configuration and actual access tests to determine the final network behavior.

Troubleshoot Network Problems

Symptom	Common cause	What to do
Dependencies cannot be installed during preparation	network_policy is too restrictive, or the allowlist is missing a package or artifact host.	Temporarily use public, complete the setup allowlist, or preinstall dependencies in the image.
Model calls fail after the agent starts	The model is called from inside the Environment, but its endpoint is not allowed during the run phase.	Add the actual endpoint hostname to run_network_policy.allowed_hosts.
An allowed URL is still unreachable	The request redirects or depends on another authentication or CDN hostname.	Inspect the full request chain and add only the required hostnames.
Docker cannot switch phase policies	The Environment uses host, none, container:<id>, or another network that does not support switching.	Use a bridge-style Docker network.
Daytona rejects an allowlist	Domains and IPv4 networks are mixed, an unsupported address type is used, or the entry limit is exceeded.	Use one supported entry family and reduce the list to the provider limit.
The run succeeds but verification fails	The verifier needs a local dependency or external endpoint that its policy blocks.	Check verifier_network_policy and allow only what verification requires.

For errors not specific to network access, see Troubleshooting Runs.

Related Pages

• Choose an Environment
• Environment Resource Limits
• Recipes