Concepts

Mediated network

Two frontends cross the sandbox boundary and terminate in one Netd enforcement engine.

Three crossings, two frontends, one engine

The MIR contains a destination allowlist. A trusted host then selects how the confined workload reaches that decision.

ARCHITECTUREStandard client through Netd

curl / git / npmunmodified client

Loopback frontendSeatbelt direct or bwrap relay

Maelys Netdauth + allowlist + DNS

Authorized upstreamconnected destination

The fd 4 frontend

A Maelys-aware workload receives an AF_UNIX datagram control channel at fd 4. It sends connect(host, port) and receives an already-connected stream with SCM_RIGHTS. Unknown destinations are rejected before DNS or connect.

CODE

aware workload ── request on fd 4 ──► host mediator
aware workload ◄─ connected TCP fd ── SCM_RIGHTS

The workload is aware of Warden. It does not receive a SOCKS or HTTP proxy.

The proxy frontend

Unmodified tools already understand HTTP_PROXY, HTTPS_PROXY or ALL_PROXY. Warden injects authenticated URLs and clears both NO_PROXY spellings.

On Linux, Bubblewrap keeps a private network namespace. An Executor-owned protocol-blind relay listens on private loopback and forwards bytes through a read-only mounted AF_UNIX path to Netd.
On macOS, Seatbelt admits exactly the per-execution Netd loopback port and denies direct Internet plus every neighboring localhost service. No relay process is needed.

Per-execution isolation

Each mediated spawn currently has its own Netd server, credential, socket or loopback binding, and network receipt stream. The installed relay bootstrap file is shared read-only; its running process and state are private to one workload.

Limits

Proxy mode supports tools that honor proxy configuration. A program that ignores it cannot reach external IP networks; Warden does not perform transparent interception or TLS termination.