docs(rfc): make process identity optional

Signed-off-by: John Myers <johntmyers@users.noreply.github.com>

Author: johntmyers

rfc/0005-sandbox-proxy-egress-adapter/README.md

@@ -92,9 +92,9 @@ enforcement contracts.
    policy evaluation.
 2. **Egress intent and decision.** Shared authorization evaluates L4 policy and
    endpoint selection once per connection intent and returns one decision
-   containing the matched policy, matched endpoint, process identity, allowed
-   IP metadata, TLS behavior, protocol enforcement, and credential injection
-   and middleware plans.
+   containing the matched policy, matched endpoint, optional process identity
+   evidence used for evaluation, allowed IP metadata, TLS behavior, protocol
+   enforcement, and credential injection and middleware plans.
 3. **Relays.** Relays receive an authorized destination connector, not an
    already-open upstream socket. HTTP relays evaluate every request before
    upstream write. TCP relays copy bytes for L4-only endpoints or hand the
@@ -342,6 +342,18 @@ If supervisor middleware is configured, the proxy runtime must also receive the
 effective middleware service registry, validate/refresh bindings, enforce
 `fail_open` and `fail_closed`, buffer within configured caps, invoke middleware
 on the request path, and emit middleware OCSF events.
+
+Process identity is mode-dependent. Embedded supervisor mode can usually
+resolve the workload process, binary, and ancestors. Network-only, standalone,
+and sidecar modes may intentionally have no local process identity. In those
+modes the adapter should pass an explicit unavailable identity envelope, and
+the decision should record identity as unavailable rather than treating it as
+an accidental lookup failure. Authorization must not turn a missing identity
+into a broader allow. Process-scoped predicates should either be treated as
+non-matching for that runtime or rejected during policy/capability validation.
+Policies that require binary/path scoping need an explicit capability check or
+fallback rule before they are allowed to run in identity-less modes.
+
 The nftables rules that force or reject userland traffic belong to the sandbox
 network boundary even if the proxy process later moves into a standalone binary
 or sidecar.
@@ -376,7 +388,9 @@ The intended order is:
   endpoints. Failures should remain fail-closed and sanitized.
 - Transparent TCP capture adds network namespace interception complexity and
   must coexist with the nftables bypass reject/log table.
-- Sidecar mode needs a reliable identity source for binary/path scoped policy.
+- Sidecar mode may intentionally lack process identity. Binary/path scoped
+  policy needs a reliable identity source or must be rejected/ignored for that
+  deployment mode.
 - Metadata loopback and `policy.local` expand sandbox-local control surfaces
   and need strict route validation, body limits, redaction, and authentication
   boundaries.
@@ -436,8 +450,8 @@ adapter wire middleware separately.
 2. Should direct IP connects to a policy-DNS-resolved TCP endpoint be accepted,
    or should DNS query correlation be required for stricter modes?
 3. What TTL cap and stale-generation grace period should policy DNS use?
-4. Which process identity source should sidecar mode use when it cannot inspect
-   payload process metadata through local `/proc`?
+4. Which policy features should be disabled, rejected, or treated as
+   non-matching when the proxy runtime advertises no process identity support?
 5. Which proxy capabilities should be negotiated with the gateway at startup?
 6. Should metadata loopback be modeled as an adapter inside
    `openshell-supervisor-network`, or remain orchestrated by `openshell-sandbox`

rfc/0005-sandbox-proxy-egress-adapter/current-shape.md

@@ -39,6 +39,13 @@ routes, identity cache, provider credential injection, and token grants.
 helpers, nftables bypass rules, and the bypass monitor that turns nftables LOG
 entries into OCSF events.
 
+In embedded supervisor mode, the network leaf can usually use process metadata
+resolved by the process/orchestrator side for binary-scoped policy and OCSF
+context. Future network-only, standalone, or sidecar proxy modes may
+intentionally lack that metadata. The adapter model should preserve this as an
+explicit "identity unavailable" state rather than fabricating an empty binary
+identity.
+
 ## Current Userland-Facing Surfaces
 
 The networking surface currently includes:

rfc/0005-sandbox-proxy-egress-adapter/implementation-plan.md

@@ -14,6 +14,9 @@ direction-focused.
   paths.
 - Add tests for exact declared private endpoint trust and `allowed_ips`
   behavior across CONNECT and forward HTTP.
+- Add tests for identity-less runtime modes where process identity is
+  intentionally unavailable and binary/path scoped policy does not
+  accidentally match.
 - Add tests proving static credential injection works in L4-only HTTP and
   HTTP-inspected paths.
 - Add tests proving token grant success injects the configured header and token
@@ -42,6 +45,9 @@ direction-focused.
   local-service internal.
 - Include protocol enforcement, supervisor middleware, and credential injection
   plans on the decision.
+- Include process identity availability and fields used on the decision. Treat
+  missing process identity as an explicit runtime mode, not as an implicit
+  lookup failure.
 - Fail closed when required endpoint metadata cannot be materialized.
 - Emit consistent OCSF network denial events from the shared boundary.
 
@@ -144,7 +150,10 @@ direction-focused.
   configured listeners, policy updates, provider credentials, token grants,
   supervisor middleware registry, gateway calls, telemetry, denial/activity
   events, and shutdown.
-- Identify process identity requirements for standalone and sidecar modes.
+- Advertise process identity capability for embedded, network-only,
+  standalone, and sidecar modes. Reject policies that require unavailable
+  identity dimensions, or define those predicates as non-matching for the
+  runtime mode.
 - Add capability negotiation with the gateway if standalone proxy versions can
   differ from gateway versions.
 
@@ -164,6 +173,7 @@ direction-focused.
 - Unit-test authorization precedence for overlapping policy and endpoint rules.
 - Unit-test provider-derived rule namespace handling and `policy.local`
   filtering.
+- Unit-test identity-available and identity-unavailable authorization inputs.
 - Integration-test shared destination validation across CONNECT, forward HTTP,
   and transparent TCP.
 - Integration-test HTTP keep-alive and pipelined requests with REST, GraphQL,

rfc/0005-sandbox-proxy-egress-adapter/technical-design.md

@@ -27,7 +27,7 @@ It should carry:
 - entry transport: CONNECT, forward HTTP, transparent TCP, local HTTP, policy
   DNS, or metadata loopback;
 - requested destination host/port or captured original IP/port;
-- process identity inputs collected by the adapter/runtime;
+- optional process identity inputs collected by the adapter/runtime;
 - optional first HTTP request for forward proxy traffic;
 - optional local service route;
 - policy generation or DNS mapping generation when relevant.
@@ -46,7 +46,7 @@ It should carry:
 - whether the policy is user-authored, provider-derived, or local-service
   internal;
 - deterministic matched endpoint identifier and endpoint metadata;
-- process identity used for evaluation;
+- process identity availability and any identity fields used for evaluation;
 - destination and allowed IP constraints;
 - TLS behavior;
 - protocol enforcement;
@@ -94,7 +94,7 @@ enum EgressTransport {
 struct EgressIntent {
     transport: EgressTransport,
     destination: RequestedDestination,
-    process: ProcessIdentity,
+    process: ProcessIdentityEvidence,
     first_request: Option<ParsedHttpRequest>,
     local_route: Option<LocalRoute>,
     generation: Option<PolicyGeneration>,
@@ -104,10 +104,27 @@ struct EgressDecision {
     outcome: PolicyOutcome,
     matched_policy: Option<MatchedPolicy>,
     endpoint: Option<MatchedEndpoint>,
+    process: EvaluatedProcessIdentity,
     request_processing: RequestProcessingPlan,
     log_context: EgressLogContext,
 }
 
+enum ProcessIdentityEvidence {
+    Available(ProcessIdentity),
+    Unavailable(ProcessIdentityUnavailableReason),
+}
+
+enum ProcessIdentityUnavailableReason {
+    RuntimeMode,
+    UnsupportedAdapter,
+    LookupFailed,
+}
+
+struct EvaluatedProcessIdentity {
+    evidence: ProcessIdentityEvidence,
+    fields_used: Vec<ProcessIdentityField>,
+}
+
 struct MatchedPolicy {
     id: PolicyId,
     source: PolicySource,
@@ -213,6 +230,27 @@ struct RelayContext {
 validated destination and lets relays/processors open an upstream connection
 only after protocol policy allows it.
 
+## Process Identity Availability
+
+Process identity is evidence, not an always-present input. Embedded supervisor
+mode can usually populate binary, PID, ancestry, command-line path, and binary
+hash data. Network-only, standalone binary, or sidecar proxy modes may
+intentionally have no local process metadata. That should be represented as
+`ProcessIdentityEvidence::Unavailable(RuntimeMode)`, not as an empty string
+that accidentally matches policy.
+
+Authorization should evaluate only identity dimensions that are available. If
+no identity is available, binary/path scoped policy should either be skipped as
+non-matching or rejected at policy/capability validation time, depending on the
+runtime mode contract. The important invariant is that missing identity must
+not produce a synthetic binary, broaden a binary-scoped allow rule, or cause
+the relay to query process metadata later. During `EgressDecision` hydration,
+absent process evidence should be carried forward as unavailable identity and
+process-derived fields should be omitted from the hydrated decision. The
+decision should record identity availability and fields used so OCSF logs and
+deny responses can distinguish "policy denied this binary" from "this runtime
+did not provide process identity."
+
 ## Current Owners And Proposed Cleanup
 
 | Current owner | Current responsibility | Proposed cleanup |