Standalone `nono proxy` command

[panga]

What problem are you trying to solve?

We want to use nono's network-layer protections, domain allowlisting and credential injection, for workloads that provide their own OS-level isolation: Docker containers, Docker sandboxes (sbx), Kata Containers, Kubernetes pods, Firecracker and gVisor, or really any workload that needs a central credential broker sitting in front of its egress.

The two capabilities we need from nono here are:

1. Domain allowlisting — restrict the workload's outbound HTTP(S) egress to a known set of hosts/endpoints.
2. Credential injection — inject credentials into outbound requests via the reverse proxy so the AI tool inside the guest never sees the raw secret.

Today the proxy only starts as a sidecar of nono run / shell / wrap: it spins up the filtering + credential-injection proxy, wires HTTP(S)_PROXY and the session token into the sandboxed child, and tears it down when the child exits. There is no supported way to run just the proxy as a standalone, long-lived server that an external process, can point its tools at.

This restricts nono to runtimes where nono run itself works. nono run is not supported in Firecracker or gVisor today. In all of those cases we still want nono's allowlist + credential brokering.

Concrete use case I have: Docker Desktop proxying through nono, so I can safely let an AI use my Docker daemon, egress is allowlisted and credentials are brokered by nono instead of being handed to the AI tool. (Integrating that wiring directly into nono is a possible follow-up, but the standalone proxy is the primitive that unblocks it.)

What would you like to see?

A standalone nono proxy command that runs the network-filtering / credential-injection proxy as a foreground server with the following features:

• Reuse the exact same config-building machinery as the sandboxed path (allow-domain parsing, endpoint/TLS-intercept handling, upstream-proxy chaining) so behavior matches run/shell/wrap.
• Load network + credential settings from a profile (--profile), with explicit flags extending (allow-domains, credentials) or overriding (network profile, upstream proxy) profile values.
• Print connection details for the user to point their own tools at — proxy URL, token, HTTP(S)_PROXY exports, per-route diagnostics, and the TLS-interception trust bundle path — then block until Ctrl-C.
• Support credential injection for known services and cmd:// credential-capture routes, so captured credentials are injected the same way as on the sandboxed path. This is what keeps secrets out of reach of the AI tool in the guest.

Proposed surface:

nono proxy                                   # Ephemeral port, token auth, prints connection info
nono proxy --port 8080                       # Fixed port
nono proxy --port 8080 --no-auth             # Open loopback proxy (no token required)
nono proxy --allow-domain github.com         # Allowlist a host
nono proxy --profile my-profile              # Load network/credential settings from a profile

Flags: --listen, --port, --no-auth, --pass, --profile, --network-profile, --allow-domain, --upstream-proxy, --upstream-bypass, --proxy-ca-validity, --trust-proxy-ca (macOS), --credential.

Security notes (fail-secure behavior this command must keep):

• --no-auth must be refused for non-loopback bind addresses so we never start an open proxy reachable from other hosts.
• --pass must reject an empty password so it can't collapse to an effectively-absent secret; --no-auth and --pass are mutually exclusive.
• --upstream-bypass requires --upstream-proxy (otherwise the bypass entries are silently dropped).

What have you tried instead?

• Running nono run / shell with a dummy long-lived child purely to keep the proxy alive — fragile, ties proxy lifecycle to an unrelated process, and doesn't fit runtimes where nono isn't (or can't be) the sandboxing parent.
• Running the workload under nono run directly — not supported on Firecracker / gVisor, and redundant where a container already provide the required isolation.
• A generic forward proxy (mitmproxy / Squid) in front of the guest — gets us allowlisting but not nono's profile-driven credential injection / cmd:// capture, so the AI tool still ends up handling raw secrets.

How is this blocking you?

It's blocking production use of nono

Additional context

No response