Add a trusted sandbox HTTP(S) egress broker and bridge

[RaresKeY]

Prerequisites

• I searched open issues and pull requests first. #6091 and #5815 are the existing trackers; #6093 covers provenance-sensitive egress, not this low-level sandbox transport.
• I searched discussions and did not find this concrete broker/bridge proposal already being debated.
• This is a concrete, actionable child slice of the existing sandbox work.

Area

Auth / Security

Problem or Motivation

Network isolation is only useful if a sandboxed process has a deliberately constrained way to make the HTTP(S) requests it is allowed to make. The transport boundary should be independently reviewable, with strict address and protocol handling, before it is wired into every process-execution path in #5818.

Proposed Solution

Scope

• Provide a trusted sandbox egress broker for the supported HTTP and HTTPS request paths and a minimal bridge that lets sandboxed processes reach that broker.
• Enforce public-address filtering after DNS resolution and on reconnect, with explicit handling for redirects and target changes.
• Bound HTTP and CONNECT behavior, request sizes, response sizes, connection lifetime, redirects, and concurrent connections using named configuration values.
• Handle TLS and configured CA behavior deliberately, scrub proxy-variable and credential-like environment leakage, and keep failure responses free of sensitive internal details.
• Define bridge startup, shutdown, reconnect, and failure behavior so the process sandbox can depend on one stable transport contract.

Non-goals

• This issue does not own provenance-sensitive egress, private-data policy, or exact approval decisions; those belong to #6093 and the wider #5815 sequence.
• This issue does not route subprocesses or background jobs through the broker; that is a separate child of #6091.
• This issue does not own Docker/Compose installation, AppArmor, or host boot diagnostics; those belong to the deployment child.
• This issue does not create a general-purpose unrestricted proxy or expose new user-facing authority modes.

Validation contract

• Test public-address filtering, DNS rebinding and reconnect behavior, redirect handling, HTTP and CONNECT limits, TLS/CA behavior, and proxy-variable scrubbing.
• Test concurrent limits, bridge lifecycle, broker restart/failure behavior, timeout handling, and safe error reporting.
• Include negative tests showing that private or loopback destinations cannot be reached through alternate resolution or reconnect paths.
• Leave container-host installation checks to the Docker/Compose child and document the dependency precisely.

Alternatives Considered

Allowing each process path to implement its own network exceptions risks inconsistent filtering and reconnect behavior. Disabling all network access would prevent legitimate sandboxed HTTP(S) use. A model-visible instruction to avoid private addresses is not a transport enforcement boundary.

Prior Art / Related Issues

Parent tracker: #6091

Broader tracker: #5815

Related provenance policy: #6093

Source coordination proposal: #5818

Are you willing to implement this?

Yes — I can open a PR

Candidate implementation and dependencies

The candidate implementation is PR #6118, opened as a draft against dev. It covers only the broker/bridge transport and behavioral tests; Docker/Compose, host boot integration, process wiring, and application network-profile propagation remain separate slices. It is independently reviewable as the egress substrate and depends on PR #6119, tracked by Issue #6114, for the trusted seccomp substrate.