Harden author network egress (both backends) — allowlist to model API + git remote

[renmengye]

Problem

Both author backends run inside apptainer exec --containall --cleanenv with full host network (no --net), bash/command execution enabled, and their provider API key in-env. This is required for the author to reach the model API and to build/test — but it means a subverted author (e.g. prompt-injection from the target tree) could exfiltrate its API key or workspace contents to an arbitrary host.

This is the pre-existing posture of the author role (the reviewer is already read-only + sanitized). Surfaced by terra's second opinion on #121 (codex --sandbox danger-full-access), which brought codex to parity with the Claude author rather than introducing the gap.

Goal

Restrict author network egress to only what the author legitimately needs (the model API host, the git remote for the target/PR), denying arbitrary hosts — covering both the Claude and codex authors uniformly (a shared apptainer-invocation layer, not a per-backend bandaid).

Options to evaluate

• Egress allowlist proxy: run the author with --net in a fresh netns whose only route is an HTTP(S) proxy that allows the API host + git remote and denies the rest; inject HTTPS_PROXY. Handles TLS via CONNECT allowlist.
• netns + nftables/iptables egress rules: allow the API/CIDR set, drop the rest. Simpler than a proxy but IP-based (API hosts rotate IPs) — likely brittle.
• Confirm the reviewer path stays unaffected (already read-only/tokenless where possible).

Non-goals

• Not a codex-only fix. workspace-write's command-level net isolation is non-functional here (needs bwrap, absent) and would leave the Claude author unhardened anyway.

Context

• Author harnesses: ClaudeCodeHarness, CodexHarness in src/autoresearch/harness.py — neither passes --net.
• Both wrap in apptainer exec --containall --cleanenv with --home + workspace binds and APPTAINERENV_* for the key.
• Related: instruction-smuggling hardening (--bare/sanitize on the reviewer), the pull_request_target fork-PR exfil concern.

[renmengye]

Code-owner decision (2026-08-22): deferred for now.

Risk is low while the author only touches the lab's own private target (autoresearch-pilot) with rotatable lab keys, and apptainer already bounds the blast radius to the run's own in-env key + its workspace. This is also parity with the long-standing Claude author, not a codex regression.

Do this BEFORE either trigger — at which point it moves from unlikely to the obvious attack:

1. the author runs on any untrusted / external target content (external repos, or intake pulling outside-contributor content), or
2. the public flip (fork PRs via pull_request_target — see the fork-exfil note).

Until then, keeping the author strictly on trusted targets is the interim mitigation.