Make external-component providerless onboarding agent-independent; validate OpenClaw and Hermes

## Upstream dependency and live qualification blocker — September 11, 2026

The maintainer has selected [OpenShell PR #3259](https://github.com/NVIDIA/OpenShell/pull/3259) as a prerequisite for resuming live qualification of this issue. Wait for its merge and a compatible OpenShell release, then upgrade NemoClaw through the separate shared runtime upgrade workflow. The upstream PR remains open as of this update.

Maintainer scope decision: cjagwani accepts the proposed core NemoClaw support boundary for OpenClaw and Hermes. The upstream dependency, compatible-release upgrade, security review, and fresh qualification requirements below remain approval gates.

The upstream PR introduces validation of the effective policy and provider configuration before workload activation. It does not establish that APF is configured or provide a network-only preparation command.

Fresh-host validation of #11584 with OpenShell 0.0.116 stopped with `endpoint_restricted` before component preparation for both OpenClaw and Hermes. Connection configuration requires the inspected Docker bridge address before gateway startup creates the network.

Keep the network-ordering repair separate from #11584. After the upstream upgrade, verify a startup sequence that preserves OpenShell network ownership and prevents workload execution before APF preparation and activation. Do not assume the upgrade alone resolves this ordering gap.

Completion requires:

- The merged OpenShell PR and a separately reviewed NemoClaw upgrade to a compatible OpenShell release, with exact revisions recorded.
- Fresh-host network preparation and gateway startup without manual network creation or changes to configuration and lifecycle ownership.
- Regression coverage for missing, existing, incompatible, and ambiguous network state, plus preparation failures.
- Live Linux validation of sandbox creation, activation, agent startup, managed inference, and allowed/denied requests for OpenClaw and Hermes.
- Adequate Docker capacity and host prerequisites before live testing; distinguish deterministic results from live evidence.

This dependency update does not mark live qualification complete or authorize changes to policy, authentication, credential custody, or bounded activation.

## Problem Statement

The shared providerless onboarding flow restricts the selected agent to OpenClaw. This couples the external-component lifecycle to one agent runtime and prevents Hermes from using the same integration.

Source review at main commit `80ba0c8914da4c3006fe8d99519d67622c435a36` confirms the restriction:
- [Creation guard](https://github.com/NVIDIA/NemoClaw/blob/80ba0c8914da4c3006fe8d99519d67622c435a36/src/lib/onboard/sandbox-create/orchestration.ts#L692) rejects a requested or resolved agent other than OpenClaw.
- [Existing regression cases](https://github.com/NVIDIA/NemoClaw/blob/80ba0c8914da4c3006fe8d99519d67622c435a36/test/onboarding/onboard-fresh-create-identity.test.ts#L55) explicitly expect Hermes rejection.

The guard reports:

```text
Interceptor onboarding supports providerless sandbox creation only. No sandbox or provider was created.
```

This is source and existing-test evidence, not a completed live Hermes reproduction. #11486 and #11525 provide the combined lifecycle and connection interface, but do not remove this restriction.

## Desired Behavior

Make the shared external-component providerless onboarding lifecycle agent-independent. Use the selected agent's existing image, configuration, and startup integration instead of assuming OpenClaw.

Validate the complete flow for both OpenClaw and Hermes:
1. Validate one registered external component and the selected agent's inputs.
2. Prepare authenticated component connections through the existing interface.
3. Create a new sandbox with externally supplied policy.
4. Verify immutable sandbox identity and effective policy.
5. Complete the existing bounded activation exchange and revalidate its evidence.
6. Start the selected agent and verify inference through the configured managed route.

Providerless means onboarding does not create an ordinary inference provider. It does not mean an agent can run without inference. Define how both agents use an externally configured managed route without copying upstream credentials into the sandbox.

Concrete example: the same component declaration and lifecycle work with either `--agent openclaw` or `--agent hermes`, using policy appropriate for that agent. Neither selection silently changes to the other agent.

## Scope and Exclusions

Include the shared lifecycle correction, necessary integration with existing agent adapters, tests for both agents, and owning guidance.

Do not replace the OpenClaw-only restriction with scattered OpenClaw/Hermes branches in shared lifecycle code. Use existing agent definitions and capabilities where they express the required behavior. Keep genuinely agent-specific startup and configuration in their existing adapters.

Agent-independent orchestration does not establish support for every agent. Initially qualify OpenClaw and Hermes. Reject agents without the required integration before external effects, with a clear reason.

Preserve:
- NemoClaw ownership of OpenShell configuration and gateway lifecycle.
- OpenShell authority over effective policy and enforcement.
- Existing preparation, authenticated dynamic registration, and verified activation.
- Agreement between requested and resolved agent identity.
- Rejection of conflicting provider, credential, messaging, and tool-provider inputs.

Exclude a new plugin framework, speculative capability registry, new component schemas, external service installation, policy compilation, policy copies, and a parallel installer. Do not add activation retries, recovery, resume, recreation, declarative configuration, or shared runtime upgrades.

Do not delete the agent guard without replacing its safety checks and validating both agent lifecycles. Report any concrete contract gap before expanding scope.

## Ongoing Ownership

Accepted owner: NemoClaw maintainers responsible for shared onboarding and the OpenClaw/Hermes integrations. External component maintainers retain ownership of their services.

## Placement and Support Expectations

Accepted placement: core NemoClaw, extending existing onboarding and agent integrations.

The accepted support boundary covers OpenClaw and Hermes through the validation plan below. Issue acceptance does not waive the recorded prerequisite, compatibility, security, or qualification gates.

## Validation Plan

- Use a shared behavior matrix for OpenClaw and Hermes through the same external-component lifecycle.
- Verify requested and resolved agent identity, including disagreement and an agent without the required integration.
- Verify each agent's image selection, startup configuration, sandbox registry identity, and managed inference routing.
- Verify that providerless creation does not create ordinary provider credentials or silently select another agent.
- Test missing or invalid policy, invalid declarations, authentication failures, identity mismatch, and policy drift.
- Verify that refused, malformed, or timed-out activation preserves incomplete state and never reports success or retries.
- Keep ordinary onboarding for both agents and existing OpenClaw external-component behavior unchanged.
- Run fresh Linux end-to-end tests for both agents with a generic authenticated component and real NemoClaw-managed OpenShell. Verify startup, identity handoff, activation, inference, and one allowed and one denied request for each agent.
- Record exact revisions and distinguish fixture results from complete live onboarding evidence. Update owning guidance for verified behavior only.

## Compatibility Requirements

Use a NemoClaw build containing #11486 and #11525, its managed OpenClaw and Hermes images, and compatible managed OpenShell APIs. Record exact versions during qualification.

The separate shared OpenShell upgrade remains outside this issue. Do not bypass blueprint version or artifact-integrity checks to qualify this flow.

## Security or Privacy Impact

No new credential custody or permission expansion is requested. Keep TLS, caller authentication, endpoint validation, protected trust files, and immutable identity checks.

Preserve the accepted callback-manifest authority and failure policies. Do not widen policy or introduce a fallback that bypasses it.

Upstream credentials must remain in their existing protected host-side stores under existing access, lifetime, and removal rules. Do not put credentials in declarations, activation payloads, sandbox configuration, or logs.

## Implementation Idea

Remove the shared flow's assumption that providerless external-component onboarding requires OpenClaw. Reuse existing agent selection, image/startup adapters, component protocols, and verified finalization. Keep lifecycle behavior shared and agent-specific behavior with its current owner.

## Category

Feature

## Checklist

- [x] Searched existing issues and open pull requests; no matching focused issue was found.
- [x] Described the problem and desired behavior.
- [x] Record maintainer acceptance of the proposed support boundary before implementation.

Start with src/lib/onboard/sandbox-create/orchestration.ts at the creation guard and test/onboarding/onboard-fresh-create-identity.test.ts, then review the existing agent adapters and the integrations from #11486 and #11525. Done means the shared providerless lifecycle supports both OpenClaw and Hermes without changing agent identity, preserves the existing safety checks, passes regression coverage, and completes the specified fresh Linux validation after the OpenShell prerequisite is available.

Written by the indexing model from the issue text.