feat: prime host-level allow/block egress lists

[mikasenghaas]

Summary

• Bump prime-sandboxes to >=0.2.33 and adopt its new egress-policy surface: PrimeConfig takes host-level allow / block lists (exact hostnames, leftmost-label *. wildcards, IPv4 addresses/CIDRs) instead of the removed network_access switch. VM-only and mutually exclusive, validated at config parse by mirroring the SDK contract (validate_egress_lists).
• The policy is applied through an update request (set_network) in prepare_execution — after trusted setup, right before the agent starts — matching Docker's trusted-setup-then-restrict shape. Framework routes (interception endpoint, MCP URLs) are auto-allowlisted, so allow = [] permits only those. Since set_network only governs new connections once the data plane acks (applied), the rollout polls for that and fails closed with a SandboxError after 60s rather than starting the agent unrestricted.
• cpu / memory / disk now default to None and are only sent when set, deferring to the sandbox SDK defaults (task-declared TaskData.resources still apply on top of unset values via resolve_runtime_config).
• Docs: docs/v1/evaluation.md gains a "Prime host policies" section; the prime table in skills/evaluate-environments/references/REFERENCE.md is updated.

Breaking

• PrimeConfig.network_access is removed (the field no longer exists in the SDK's CreateSandboxRequest). Migration: network_access = false → vm = true + allow = [] (blocks all agent-phase egress except framework routes); network_access = true is the default (leave allow/block unset).
• PrimeConfig.cpu / memory / disk defaults change from 1.0 / 2.0 / 5.0 to None (unset → SDK defaults, currently the same values). Pin them explicitly to keep provisioning independent of SDK defaults.

Verification

Dummy agent rollouts (bash harness in a prime VM sandbox, agent instructed to probe example.com and google.com and report reachability, reward = report matches the scenario's expected reachability):

Scenario	Runtime config	Result
open	no lists	reward 1.0 — both hosts reachable, agent completed
partial allow	allow = ["example.com"]	fails closed: SandboxError (policy accepted, never applied)
blocked	allow = []	fails closed: SandboxError (policy accepted, never applied)
deny one	block = ["example.com"]	fails closed: SandboxError (policy accepted, never applied)

The fail-closed results are a platform-side gap, not an integration bug: direct SDK probes (no verifiers involved) show the egress-policy data plane never converges right now — applied_generation stays -1 for 6+ minutes in both the provider-default and us regions, on both paths:

• create-time network_allowlist=["example.com"] → all egress blocked (even the allowlisted host), applied=False forever;
• set_network on a running VM → policy accepted (generation=1) but egress stays fully open, applied=False forever.

Given set_network is fail-open until applied, the 60s ack-wait in prepare_execution is what keeps these rollouts from silently running unrestricted. Once the platform's policy agent ships, the same rollouts should go green with no changes here.

🤖 Generated with Claude Code

---

Note

Medium Risk
Changes sandbox networking and rollout gating (fail-closed on policy apply); breaking config surface for Prime, though behavior aligns with Docker’s post-setup restriction model.

Overview
Prime VM egress replaces the removed network_access flag with optional host-level allow / block lists (validated at config parse, VM-only, mutually exclusive). Sandboxes still provision with open networking; prepare_execution calls set_network, auto-prepends interception/MCP route hosts to an allowlist, and polls up to 60s for applied before the agent runs—otherwise it raises SandboxError instead of starting unrestricted.

Provisioning no longer sends network_access on create; cpu, memory, and disk default to None and are omitted so prime-sandboxes>=0.2.33 SDK defaults apply.

Docs add a Prime host-policies section in evaluation.md and refresh the Prime table in the evaluate-environments reference.

Breaking: migrate network_access=false → vm=true + allow=[]; pin resource fields if you relied on the old fixed defaults.

^{Reviewed by Cursor Bugbot for commit a013c39. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Add host-level allow/block egress lists to Prime runtime

• Replaces the network_access: bool field in PrimeConfig with allow: list[str] | None and block: list[str] | None fields that define host-level egress allow/deny lists, validated at config parse time via prime_sandboxes.models.validate_egress_lists.
• Adds PrimeRuntime.prepare_execution which applies the egress policy after trusted setup and before the agent starts, automatically prepending framework route hostnames to allow lists and polling until the data plane acknowledges the policy (60s timeout).
• An empty allow list results in denying all traffic except framework routes; allow and block are mutually exclusive and VM-only.
• cpu, memory, and disk fields now accept None to defer to SDK defaults instead of fixed numeric defaults.
• Risk: network policy is no longer applied at sandbox creation time; it is applied in prepare_execution, which is a behavioral change from the previous network_access approach.

^{Macroscope summarized a013c39.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit a013c39. Configure here.}

[cursor]

Missing reuse guard for egress

Medium Severity

prepare_execution applies a lasting host egress policy after trusted setup, but PrimeRuntime never claims the sandbox as single-rollout the way Docker does for the same trusted-setup-then-restrict shape. A box from agent.provision reused across runs keeps the prior agent-phase policy through the next setup, so later setups can run restricted instead of open.

 

^{Reviewed by Cursor Bugbot for commit a013c39. Configure here.}

[macroscopeapp]

Approvability

Verdict: Needs human review

Unable to check for correctness in a013c39. This PR introduces new network egress control functionality for Prime sandboxes, which is security-sensitive. Additionally, there's an unresolved review comment identifying a potential bug with egress policy persistence across sandbox reuse. Both factors warrant human review.

^{You can customize Macroscope's approvability policy. Learn more.}