Skip to content

[Deferred] CUA: Connect one disposable target through existing policy controls #8450

Description

@jyaunches

Parent epic: #6015

Status

Deferred.

#9649 and merged PR #9657 provide the current CUA foundation. This issue does not block the private browser demo.

Do not implement this issue until maintainers resume first-class target work and accept the exact target transport and validation owner.

Decision boundary

If maintainers resume this issue, first use the existing terminal-agent and policy commands. Do not create a CUA target subsystem.

For this issue, connecting a target means that one NemoCUA sandbox can reach exact services on one caller-managed disposable target. NemoClaw does not create or persist a managed target attachment.

This slice is credential-free at the NemoClaw boundary. If the current target requires NemoClaw to store or forward a target credential, stop and refine that requirement separately before implementation.

Outcome

A caller can:

  1. Create one disposable target outside NemoClaw.
  2. Make its required services reachable through caller-owned transport.
  3. Apply one custom policy preset that permits only the required target routes and requesting binaries.
  4. Pass non-secret target inputs to the NemoCUA harness through nemoclaw <sandbox> agent.
  5. Verify the result outside NemoClaw.
  6. Remove the target policy and destroy the target through their owning lifecycle paths.

This issue adds no CUA-specific public command, schema, registry record, or status projection.

Ownership

NemoClaw owns:

  • feature-gated NemoCUA sandbox creation;
  • validation and application of the custom policy preset;
  • standard terminal-agent command dispatch;
  • existing sandbox policy, recovery, rebuild, and destroy behavior.

OpenShell owns enforcement of the declared routes and requesting binaries.

The caller or scenario owns:

  • target creation and destruction;
  • target image and service versions;
  • target transport and any target credential;
  • target health, reset, and external-effect inspection;
  • task input, task state, result verification, and cleanup confirmation.

Target hostnames, ports, protocols, methods, and paths remain ordinary policy configuration. Existing policy persistence and removal behavior applies.

Trust boundaries and failure behavior

  • The caller-prepared sandbox image remains an explicit caller-owned input.
  • The target and its transport remain outside NemoClaw lifecycle authority.
  • OpenShell must allow only the target routes and requesting binaries declared by the applied policy.
  • Managed inference remains limited to the NemoCUA baseline policy.
  • This capability must not broaden policy beyond the exact target routes. Existing operator-selected policy remains unchanged.
  • The acceptance journey uses a deny-by-default policy and keeps unrelated routes, cloud metadata, host administration, host desktop access, and Docker-socket access denied.
  • Target credentials must not enter command arguments, policy files, logs, diagnostics, registry state, snapshots, or backups.
  • NemoClaw propagates a failed harness command and stores no target success record.
  • An interrupted target request can have an unknown external effect. NemoClaw does not retry it or infer success. The caller inspects or resets the target.
  • A failed policy removal remains a reported failure. NemoClaw must not claim that access was removed.

Observable acceptance

  • Allowed: Apply one exact target policy and pass non-secret target inputs through agent -> the harness reaches the declared routes and managed inference.
  • Denied: Omit the target policy or request an undeclared route or binary -> OpenShell denies target access.
  • Ambiguous: Interrupt a request after dispatch -> NemoClaw reports no target result and stores no CUA state.
  • Recovery: Remove the policy -> later target access is denied. The caller remains responsible for target inspection and cleanup.

Acceptance criteria

  • Simplify experimental CUA to the standard terminal-agent path #9649 behavior remains passing.
  • NemoCUA remains absent unless NEMOCLAW_CUA_ENABLED=1 exactly.
  • One custom policy preset permits only the required target routes and requesting binaries.
  • The standard agent command appends non-secret caller arguments to the NemoCUA harness command.
  • The harness can reach each declared target route and managed inference.
  • Under the acceptance journey's deny-by-default policy, OpenShell denies an undeclared target route and requesting binary.
  • Exact private-host access uses the existing explicit private-host validation.
  • Removing the target policy revokes target access from the sandbox.
  • A failed policy removal does not report that access was removed.
  • An unavailable target causes the harness command to exit nonzero without creating CUA state.
  • An interrupted command records no target success and performs no automatic retry.
  • No target credential or task content enters public output or persisted NemoClaw state.
  • No CUA-specific target, security, lifecycle, readiness, evidence, or qualification state is added.

Validation

Reuse existing tests for:

  • NemoCUA feature selection and caller-prepared image handling;
  • terminal-agent argument dispatch and exit propagation;
  • custom policy validation, add, remove, persistence, and private-host handling.

Add only missing focused evidence for the composed behavior. One live OpenShell journey must confirm:

  • declared target access succeeds;
  • undeclared access fails;
  • access fails after policy removal;
  • unrelated host and metadata routes remain denied under the journey's deny-by-default policy.

The scenario owns target creation, result verification, and cleanup evidence. Do not add a CUA receipt, evidence bundle, or qualification record.

If existing behavior and focused evidence satisfy every criterion, close this issue without adding production code.

Do not add

  • A second CUA feature or qualification gate.
  • Candidate or availability status.
  • CUA target attach, status, health, detach, destroy, or security commands.
  • A target manifest or CUA lifecycle schema.
  • An adapter registry or adapter execution framework.
  • Target attestations, component inventories, digests, receipts, or evidence records.
  • CUA-specific registry state.
  • Automatic target retries or uncertain-effect reconciliation.
  • Target credential storage.

Deferred work

#7753 is not part of this capability.

#7754 can supply applicable security requirements after maintainers resume a concrete capability. It is not a prerequisite or a separate implementation system.

Dependencies

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    CUAComputer-use agent integration and qualificationarea: cliCommand line interface, flags, terminal UX, or outputarea: sandboxOpenShell sandbox lifecycle, runtime, config, or recoveryneeds: designRequires product or architecture direction

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions