Reuse reserved proxy sockets and verify each connection's executable identity #4804

User Story

I use OpenShell network policies that give different executables different permissions. When a backend sends workload traffic through the supervisor's proxy, I need each connection checked against the executable that opened it. The backend's launcher also needs to keep its reserved listening socket until sandbox cleanup finishes.

Problem Statement

The supervisor's direct proxy setup accepts an address and one fixed executable identity. A backend cannot pass in a socket its launcher has already bound or supply a trusted way to identify the executable behind each connection.

That leaves two gaps: every connection is treated as the same executable, and the launcher must release its reserved address so the supervisor can bind it again.

Impact / Why This Matters

Using one identity for several executables makes network policy decisions and audit records less accurate. Releasing and rebinding the address also creates a window in which another process can claim it.

Backend authors must work around these gaps or maintain their own supervisor changes to reuse OpenShell's network policy enforcement, TLS inspection and provider credential handling.

Proposed Design

An isolation backend's trusted supervisor setup can configure the OpenShell supervisor to serve a listening socket already reserved by the backend's launcher and resolve the executable identity of each connecting workload process. Operators continue authoring network_policies through the existing OpenShell policy workflow.

The supervisor evaluates each connection using the verified caller identity. If attribution is missing, ambiguous or fails, the supervisor denies the request and records an OCSF denial event. It does not substitute the configured static identity. The backend's launcher can retain its socket handle until sandbox cleanup completes, even if the supervisor closes its copy.

The compute driver continues to manage sandbox lifecycle, the isolation backend provides workload isolation, and the supervisor owns proxy authentication, network policy evaluation and provider credential handling. Existing static-identity listeners and isolation backends using transparent network mediation keep their current behavior. Incompatible listener settings fail at supervisor startup with a clear error.

Acceptance Criteria

• An isolation backend's trusted supervisor setup can supply its launcher's already-bound TCP listener without releasing and rebinding the address.
• Connections from different workload executables receive policy decisions and audit attribution based on their own verified identities.
• Missing, ambiguous or failed attribution denies the request and records an OCSF denial event without using a static fallback.
• The supervisor rejects a supplied socket with an unexpected bound address at startup.
• The supervisor rejects direct-listener settings combined with transparent network mediation.
• Closing the supervisor's socket copy leaves the backend launcher's retained reservation intact.
• Existing static-identity proxy and transparent network mediation flows continue to pass their relevant tests.

Alternatives Considered

• Use one static executable identity. This works when every proxy connection represents the same executable, but cannot distinguish multiple workload processes.
• Release and rebind the address. This lets the supervisor create its own listener, but breaks continuous ownership of the backend launcher's reservation.
• Use supervisor middleware, gateway interceptors or providers. These extension points inspect requests or manage credentials. They do not control the supervisor's listening socket or establish authoritative workload process identity at connection acceptance.

Agent Investigation

No response

Checklist

• I've reviewed existing issues and the published docs
• This is a design proposal, not a "please build this" request