Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[ENV-C5] Network egress mediation and model-endpoint allow-listing for container backends (post-MVP)

Open
  • Is something wrong?
#294 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
18/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
docker, python
Domain
infrastructure, security

Research direction

Start with ADR 0005 §9 and D9, then read #266, #270, #274, #290, and the runtime model in AGENTS.md to understand the security constraints and dependencies. First decide whether egress mediation is feasible within the controller runtime and rootless Docker constraints; record the mechanism, alternatives, and residual risk in an ADR amendment. If the decision is positive, define the enforcement proof and tests in the ADR before implementation; done means the acceptance criteria are met, including real Docker negative tests and refusal when enforcement is unavailable.

Written by the indexing model from the issue text.

Description

enhancement

Artifact: decision-first design and implementation task of EPIC #266. Wave: C (post-MVP). Size: L. Baseline: main 388ecb3 (2026-10-23). Created by the 2026-10-23 planning reconciliation of #266 (review: #266 comment). No implementation is authorized by this planning action.

Why this issue exists

#270 originally asked the Docker MVP to allow "only the model endpoints required by #290 and explicitly authorized dependency downloads". That is domain-level egress mediation. On 2026-10-23 it was moved out of the Docker MVP into this issue, for these reasons:

  • ADR 0005 §9 lists "No network egress mediation, proxy, firewall or DNS policy" as a non-goal (docs/adr/0005-outer-sandbox-and-host-resource-capability-model.md:1906), and ADR 0005 D9.1 (:1139) has agents share the host network today.
  • Docker gives a network namespace (bridge) or no network (--network none). It does not restrict a bridge network to a set of domains: that needs a proxy, a firewall or DNS policy, which is a new subsystem.
  • The LAUNCH-E audit confirmed the residuals and kept egress control out of scope (#257, maintainer residual table of 2026-10-22: R3 "model credential readable by every tool in its launch", confirmed by design; R4 "network egress and loopback", confirmed; "Egress control is out of #257's scope").

The security concern is deferred, not removed. Until this issue lands, an agent that holds its model credential and has general outbound access can exfiltrate that credential. The Docker MVP documents this as a residual (#270, #274) and never claims that bridge networking restricts traffic to model endpoints.

Objective

Decide, and if the decision is positive implement, controller-owned network egress mediation for container backends. It restricts each launch class's outbound traffic to an explicit, per-run allow-list (the model endpoints of the selected provider route from #290, plus explicitly authorized dependency sources), and refuses rather than degrades when it cannot be enforced.

Hard dependencies

  • #274 (ENV-B4): the Docker MVP is proven end to end first. This issue never blocks #271 or #274.

Design questions (decide before implementing)

  • Mechanism: an HTTP(S) CONNECT proxy run by the controller, network-namespace firewall rules, DNS policy, or a combination. Which of them work for rootless Docker (slirp4netns or pasta) and for rootful Docker, and which need privileges AutoForge must not take?
  • How a launch's allow-list is derived: per provider route from #290 (Claude Code, OpenCode 2.x, Pi), per launch class (agent, validation and pre-merge commands), and for dependency downloads. Is it operator configuration, under strict key validation, with no repository-controlled entries?
  • What it means for repository commands that need the network (sandbox.validation_network, sandbox.premerge_network today).
  • How doctor and the capability probe prove enforcement with a real minimal launch (ADR 0005 D14.1 style), and how a launch that cannot be enforced is refused under sandbox.mode: required.
  • How it composes with AutoForge's runtime model: a local helper owned by one controller process, with no shared service and no distributed machinery (root AGENTS.md, "Runtime model").
  • What remains: an allowed model endpoint can still carry exfiltrated data. State the residual precisely.

Acceptance criteria

  • ADR amendment (to ADR 0005 §9 / D9) records the mechanism, its rationale, the rejected alternatives and the residual risk; a negative decision is a valid outcome and is recorded the same way.
  • If implemented: a launch reaches only its allow-listed destinations; negative tests show that other hosts, the host loopback, the Docker bridge gateway and link-local metadata addresses are refused, on real Docker, with skipped real-backend tests reported as untested.
  • Under sandbox.mode: required, a host or runtime that cannot enforce the policy refuses the launch before anything is saved, charged or spawned; no silent fallback to unrestricted bridge networking.
  • No credential in the proxy or firewall configuration, logs, state or argv; allow-lists are visible in dry run and doctor by role, not by secret.
  • Docs (the security documentation, docs/security.md, which #257's LAUNCH-E work introduces, and docs/configuration.md) replace the MVP's "no egress control" residual with exactly what is now enforced and what is not.
  • Existing regression suite passes; Podman (#275) and remote (#277) parity are stated as tested or unsupported, never implied.

Non-goals

  • Not a prerequisite of the Docker MVP (#271, #274) or of Public Alpha #255.
  • No privileged helper, no Docker socket inside an agent, no host network mode.
  • No claim that egress control prevents an agent from misusing its own model credential through an allowed endpoint.
Dominant language
Python
Stars
0
Forks
0
Avg merge
5h 46m
Merged PRs (30d)
82

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from iceboundrock/AutoForge

All issues in iceboundrock/AutoForge

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.