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.

[johntmyers]

@maruiz93 have you tried using host.openshell.internal? so something like:

network_policies:
  host_service:
    name: host_service
    endpoints:
      - host: host.openshell.internal
        port: 8080
    binaries:
      - path: /usr/bin/curl

The service you are running will need to be addressable by the driver infra you choose. For example with Docker the service you are running will need to be reachable by other containers in order for the sandbox workload to reach it through host.openshell.internal.