Enforce AMS sandbox network-egress deny-by-default + allowlist (implements #7648)

[JSONbored]

Problem

#7648 ratified AMS's sandboxed execution environments to deny-by-default network egress with a curated allowlist (OS package registries, the target repo's own git remote, the repo's declared language-ecosystem registries). No enforcement mechanism exists yet — AMS's execution sandboxing (packages/loopover-engine/src/miner/worktree-pool.ts) is code/filesystem isolation only; nothing restricts network access from inside an attempt.

Area

packages/loopover-engine/src/miner/worktree-pool.ts and wherever the actual coding-agent subprocess is launched (self-host today; also the future hosted-AMS execution path once #7180's container work lands).

Proposal

Enforce #7648's ratified default at the point an attempt's sandbox spins up: deny all outbound network access by default, punch through only the ratified allowlist categories (OS package registries, the repo's own git remote, its declared package-ecosystem registries), and provide the per-repo allowlist-extension request path #7648 deferred (pin down the actual review-gate mechanism as part of this issue, rather than inventing one). Follow the same "not a complete solution alone" caveat #7648 cites from Codex/Copilot's own docs — pair this with not assuming egress control alone stops exfiltration (output-channel vectors like auto-rendered remote content bypass it regardless of how tight the allowlist is).

Deliverables

• Egress enforcement wired into wherever the sandbox subprocess launches, deny-by-default.
• The ratified default allowlist implemented and configurable per repo.
• A concrete, working allowlist-extension request path (with the review-gate identified, not assumed).
• Tests: a disallowed outbound request from inside a sandbox is blocked; an allowlisted one succeeds; a repo-specific addition takes effect.

Resources

• Decide default network-egress policy for AMS sandboxed execution (deny/allowlist, not open) #7648 (the ratified decision this implements)
• packages/loopover-engine/src/miner/worktree-pool.ts (existing code-isolation precedent)

Boundaries

Egress enforcement only — does not address other agent-safety concerns (output-channel exfiltration, prompt injection), out of scope for this issue.

maintainer-only — security-critical sandbox enforcement, not a first-pass contributor task.

[linear-code]

JSO-5495

[JSONbored]

Investigated before implementing. Two real, unresolved gaps — flagging rather than picking an interpretation silently, since this issue explicitly touches a ratified security posture.

1. No architectural mechanism exists to actually enforce this today. Self-host AMS runs the coding-agent CLI (claude/codex) as a bare child_process.spawn() sibling process inside the same container as the long-running miner (packages/loopover-miner/lib/coding-agent-construction.ts's createRealCliSubprocessSpawn) — no network namespace isolation, no per-attempt container. The miner's own Dockerfile/docker-compose.miner.yml sets no network_mode, cap_add, seccomp, or AppArmor profile; it gets Docker's default bridge network with full outbound egress. worktree-pool.ts (this issue's cited precedent) is pure in-memory scheduling — no IO, no subprocess spawning, no isolation of any kind beyond git-worktree/filesystem.

Real enforcement needs one of:

• Container-level iptables/nftables rules (needs NET_ADMIN, not granted today, and would affect the whole container's traffic since the coding-agent subprocess shares its network namespace — including the miner's own legitimate calls to loopover's API/GitHub, so the ruleset has to be scoped carefully, not a blanket deny).
• A per-attempt container/network-namespace boundary (matching the architecture Provisioning core: create/destroy a tenant's Container + Postgres DB #7180's future hosted path uses via Cloudflare Containers, which already exposes a coarse enableInternet toggle — but that path isn't wired to run AMS attempts yet, and it's a platform on/off switch, not a curated allowlist by itself).
• A mandatory-proxy architecture — HTTPS_PROXY/HTTP_PROXY are already passed through to the subprocess (CODING_AGENT_ENV_ALLOWLIST in cli-subprocess-driver.ts), but that's advisory only; nothing prevents the subprocess from ignoring the proxy env vars and connecting directly without a network-level block backing it.

None of these is a small addition to the files this issue names — each is a real infra/security-architecture decision with a different blast radius.

2. The ratified allowlist source has a trust-boundary gap #7648 never resolved. One allowlist category is "the repo's declared language-ecosystem registries." If that means reading the target repo's own manifest (package.json, requirements.txt, etc.) — the only place ecosystem detection exists today (review-enrichment/src/analyzers/dependency-scan.ts, PR-diff-scoped, 3 ecosystems) — this directly contradicts this codebase's own established trust boundary. packages/loopover-engine/src/ams-policy-spec.ts's header states it explicitly: a target repo must never be able to "let the operator's agent spend more budget or submit live instead of observing... since that would let a malicious or compromised repo talk an operator's own miner into raising its own risk tolerance against that exact repo." A malicious repo could add a fabricated manifest entry to widen its own attempt's network allowlist toward an attacker-controlled endpoint disguised as a legitimate registry. #7648's ratification comment only fixed the allowlist category list — it didn't specify a safe way to populate the ecosystem-registry category, and explicitly deferred the review-gate mechanism for extension requests to "the implementation issue" (this one) without one existing today.

Recommend re-opening #7648 (or a follow-up decision issue) to pick: (a) which enforcement mechanism, given today's shared-container reality, and (b) how ecosystem-registry detection can populate the allowlist without trusting the target repo's own files. Leaving this issue open rather than implementing a partial/advisory-only version that would look like enforcement without actually being one.

[JSONbored]

Follow-up after deeper research + a maintainer decision on the two open questions from my last comment.

Enforcement mechanism — deferred, by explicit decision. Researched two more angles before deferring:

• UID-scoped iptables rules (isolating only the coding-agent subprocess's traffic, not the whole container) is not available today: the subprocess is spawned via a plain child_process.spawn() with no uid/gid option (packages/loopover-miner/lib/coding-agent-construction.ts's createRealCliSubprocessSpawn), so it inherits the exact same UID as the parent miner process (both USER node, uid 1000, per the Dockerfile). Giving it a distinct UID would require restructuring the container to start as root and drop privileges for the child — a bigger change than this issue should carry on its own.
• Container-level enforcement (NET_ADMIN + iptables/nftables on the whole miner container, allowlist including the miner's own small fixed set of legitimate destinations alongside the coding-agent's) is mechanically workable — Debian base (node:24-slim), iptables/nftables installable via apt (not present today), and this repo already has one NET_ADMIN precedent (the tailscale service in docker-compose.yml). Deferred anyway rather than built now — leaving this open for a future pass once self-host vs. hosted-per-attempt-container direction is clearer, rather than shipping a container-wide capability grant as a side effect of this issue.

Allowlist source — resolved. Extending AmsPolicySpec/.loopover-ams.yml (operator-local-only by design, never fetched from the target repo — see that file's own header) with an operator-declared ecosystem/host allowlist field, matching the existing selfLoopAutonomy field's "declared but inert until a later piece of work consumes it" precedent in the same file. This ships now and closes the trust-boundary gap from my last comment (no path for a target repo's own manifest to smuggle a destination into its own attempt's allowlist), independent of when the OS-level enforcement piece lands.

Net: this issue stays open, scoped down to "wire the declared allowlist into real OS-level enforcement" — the config surface a future implementation will read is landing as its own piece of work.