RFC 0005: Sandbox proxy egress adapter model

[johntmyers]

Summary

Drafts RFC 0005 for reshaping sandbox proxy egress around transport adapters, shared EgressIntent / EgressDecision authorization, and relay-owned byte handling. The proposal covers CONNECT, forward HTTP, DNS, local services, native TCP, supervisor middleware, credential injection, WebSocket/body injection, JSON-RPC, MCP, and optional process identity for sidecar-style modes.

Related Issue

N/A - RFC proposal.

Changes

• Adds RFC 0005 for the sandbox proxy egress adapter model.
• Splits current-state notes, technical details, and implementation plan into RFC appendix documents.
• Documents flow diagrams for unified adapters, relay handling, DNS/native TCP, local services, and deployment modes.
• Accounts for recent networking changes including nftables, supervisor middleware, JSON-RPC/MCP L7 support, and identity-less runtime modes.

Testing

• mise run pre-commit passes
• Unit tests added/updated
• E2E tests added/updated (if applicable)

RFC-only documentation change. Ran git diff --check and ASCII scans on the RFC files. Pre-commit was intentionally not run for this RFC draft.

Checklist

• Follows Conventional Commits
• Commits are signed off (DCO)
• Architecture docs updated (if applicable)

[maruiz93]

Thanks for this RFC — the adapter/authorization/relay separation is a clean model.

I wanted to flag #1633 (supervisor-proxied host-local endpoints) as a consumer of this design. The host.local / host_local: true pattern proposed there is structurally identical to inference.local — the supervisor proxies a CONNECT request to 127.0.0.1:<port> on the host instead of resolving DNS and connecting externally. It works across all deployment modes in the RFC's table because the supervisor always runs in the host/pod network namespace.

The RFC's local service adapter category is the natural home for this, but Phase 8 currently models only the three existing services (inference.local, policy.local, metadata loopback) without a generalization step for policy-declared host-local endpoints.

A few questions:

1. Could Phase 8 include a step for policy-declared host-local endpoints, even if implementation is deferred? Designing the adapter boundary to accommodate this now would avoid bolting it on later.

2. In the context of the EgressTransport enum, would a reserved hostname like host.local become a new local adapter (Option A from feat(proxy): supervisor-proxied host-local endpoints — generalize the inference.local pattern for arbitrary host services #1633), or would a host_local: true flag on a standard endpoint trigger routing through the existing LocalHttp transport (Option B)?

3. The shared destination validation in Phase 2 centralizes SSRF checks — host-local endpoints bypass DNS entirely (the supervisor connects to 127.0.0.1 directly). Does the destination validator need an explicit carve-out for host-local routing, similar to how inference.local bypasses OPA network policy today?

Our use case: we're designing host-side API servers for fullsend (container builder, repo provisioner) and have an ADR and early experiments around it. Today the experiments bind to 0.0.0.0 with allowed_ips — the workaround described in #1633. Supervisor-proxied host-local endpoints would eliminate the network exposure and make the setup driver-agnostic, and we'd like to build on a stable foundation rather than the workaround.