[Bug]: transparent agent runs lack invocation-bound gateway authentication

[bbednarski9]

Affected area

• Transparent agent execution (nemo-relay run --agent ...)
• CLI gateway authentication and plugin-directed dispatch

Problem

Transparent agent runs need two different credentials at two different trust boundaries:

1. an invocation credential proving that the child agent belongs to the Relay gateway that launched it; and
2. an upstream provider credential owned by Relay or by the plugin-selected target binding.

Relay previously had no typed distinction between those credentials. In the Hermes path, the child sent the implementation-specific placeholder Authorization: Bearer no-key-required to Relay's loopback gateway. The gateway treated any source Authorization value as an upstream credential, so the placeholder could suppress normal provider authentication and be forwarded to an authenticated upstream.

Recognizing that literal in the generic gateway would fix one symptom but leave the trust model ambiguous:

• it would couple Relay to a private Hermes implementation detail;
• it would not authenticate the child invocation;
• it would not cover Codex, Claude Code, Anthropic-style keys, or future harnesses consistently;
• source credentials could still compete with plugin-owned target credentials after a route change; and
• ambient provider keys could be injected into an explicitly selected keyless or differently authenticated target.

Expected design

Each transparent run should generate an unguessable, invocation-bound proxy credential and deliver it only to the launched child. The gateway should validate and consume that credential at ingress, before request interception or route selection.

After ingress, authentication provenance should be explicit:

• source provider credentials remain source credentials while the request stays on its original route;
• an explicit plugin dispatch owns target authentication through its Relay target binding;
• source provider credentials are removed when the destination changes;
• ambient provider-key fallback is disabled for explicit plugin dispatch;
• a keyless target remains keyless; and
• foreground gateways retain their existing behavior.

The transport may follow each harness's supported configuration mechanism, but the gateway contract must be provider- and harness-neutral. No well-known placeholder credential should be recognized.

Security and compatibility requirements

• Generate a fresh high-entropy proxy credential for every transparent invocation.
• Compare credentials in constant time and reject missing or foreign credentials with HTTP 401.
• Never forward or emit the proxy credential in observable request headers.
• Support both standard OpenAI-style and Anthropic-style authentication carriers.
• Preserve a real provider credential when a harness can carry the proxy credential in a dedicated header.
• Let explicit target-binding headers win after routing, without source or ambient credential leakage.
• Preserve foreground gateway and managed-sidecar behavior.
• Redact the generated credential from --print, logs, configuration artifacts, ATOF, ATIF, and OpenInference output.

Acceptance criteria

• Transparent Hermes, Codex, and Claude Code launches receive the same invocation-bound gateway-authentication semantics.
• Missing or invalid proxy credentials are rejected before interceptors execute.
• OpenAI-to-Anthropic and keyless target dispatches do not inherit source or ambient credentials.
• Same-route requests preserve legitimate provider credentials.
• Unit, gateway, process, server, and Switchyard integration tests cover these invariants.
• A real transparent Hermes run succeeds against an authenticated OpenAI-compatible endpoint.
• A one-task Harbor evaluation succeeds through the CLI-wrapper path without authentication errors or secret leakage.

Implementation

Tracked by #449.