Skip to content

Add a sandbox quarantine command with durable restart fencing and receipts #10140

Description

@ericksoa

Problem Statement

NemoClaw has no operator command that stops a suspicious sandbox, blocks automatic or manual restart, and preserves its state for inspection.

nemoclaw <name> stop stops the runtime provider workload but preserves the sandbox registry, workspace, credentials, and shared gateway state. A later start can resume it. nemoclaw <name> destroy removes the sandbox and its registry entry. Neither operation provides a durable emergency-control state with a secret-free receipt.

Operators need this boundary when an agent behaves unexpectedly, consumes resources without authorization, or may have attempted unauthorized access. The operation must stop execution and sandbox access without deleting workspace state or evidence.

Desired Behavior

Add a user-facing sandbox quarantine operation. Proposed syntax:

nemoclaw <name> quarantine --reason "<reason>"

The final command name requires maintainer approval because NemoClaw already uses quarantine for other blocked states.

For one registered sandbox, the operation must:

  1. Acquire the existing sandbox lifecycle lock.
  2. Resolve the runtime provider and exact target identity from the sandbox registry.
  3. Reject missing, ambiguous, stale, or replaced target identity before mutation.
  4. Record a durable quarantine fence and operation journal before ordinary lifecycle commands can reactivate the sandbox.
  5. Stop messaging channels, dashboard and service access paths, and the runtime provider workload through their owning interfaces.
  6. Verify that execution and sandbox access stopped.
  7. Preserve the sandbox registry entry, workspace, snapshots, logs, and other evidence.
  8. Write a secret-free receipt with the request identity, target identity, lifecycle generation, attempted operations, observed outcomes, timestamps, and failures.

start, recover, rebuild, onboarding reuse, restore, and upgrade paths must refuse to reactivate a quarantined sandbox. Read-only status and evidence collection should remain available when they do not weaken the fence. destroy may remain available through its existing confirmation and exact-target cleanup contract.

A separate explicit operation must release the quarantine fence. Releasing the fence must not start the sandbox. The operator must run start separately.

Repeated requests with the same idempotency key must reconcile the existing operation and return its receipt. A transport timeout must trigger target-state inspection. It must not trigger an automatic mutation through another transport.

Example:

$ nemoclaw my-agent quarantine --reason "unexpected outbound activity"
Sandbox 'my-agent' is quarantined.
Execution: stopped and verified
Sandbox access: stopped and verified
Workspace: preserved
Receipt: <path>

Proposal Details

Scope and Exclusions

In scope:

  • One sandbox-scoped emergency-control operation.
  • A durable restart fence and crash-recoverable operation journal.
  • Exact runtime-provider and target identity checks.
  • Idempotent reconciliation after interruption or ambiguous transport results.
  • Secret-free receipts that separate enforcement results from observed postconditions.
  • Guards on every supported path that can reactivate or replace the sandbox.
  • User documentation and focused runtime evidence.

Out of scope:

  • A fleet, tenant, or remote control service.
  • A second sandbox registry or lifecycle authority.
  • Canonical workflow run_id storage. A future run-level adapter may invoke the sandbox operation for each resolved target.
  • Direct Docker or Podman commands that bypass the selected runtime provider or OpenShell.
  • Automatic revocation of credentials at external providers.
  • Automatic deletion of the sandbox, workspace, or evidence.
  • A claim of atomic multi-target quarantine.

The maintainer decision must define behavior when the exact target is proven but NemoClaw cannot persist the durable fence. The implementation must not report quarantine success unless both enforcement and required observations complete.

Ongoing Ownership

Proposed owner: NemoClaw runtime integration maintainers. An accountable maintainer must be named before implementation starts.

Placement and Support Expectations

Requested placement: core NemoClaw.

This proposal adds a user-visible sandbox lifecycle and security control. Maintainers must record Accept, Request changes, Defer, or Decline. An Accept decision must name the accountable maintainer and the required validation evidence.

Validation Plan

  • Unit tests for command input, reason redaction and bounds, target resolution, idempotency, receipt shape, and every lifecycle guard.
  • Negative tests for missing registry state, stale lifecycle generation, target replacement, wrong gateway, unsupported runtime provider, concurrent mutation, and unauthorized release.
  • Failure tests for partial channel or service shutdown, runtime-provider failure, transport ambiguity, observation failure, receipt persistence failure, interruption, retry, and cleanup.
  • Tests that start, recover, rebuild, onboarding reuse, restore, and upgrade cannot bypass an active fence.
  • Tests that status, doctor, and approved evidence collection do not remove or weaken the fence.
  • Tests that receipts and diagnostics contain no credential values, policy bodies, message content, or user task data.
  • A live E2E test using a real OpenShell sandbox. It must verify execution stops, access paths stop, state remains available, restart is denied, repeated invocation is idempotent, and explicit release does not start the sandbox.
  • Runtime-provider evidence for each provider accepted by the maintainer decision. An unsupported provider must fail before mutation.

Compatibility Requirements

The operation must extend the current runtime-provider bundle and sandbox lifecycle lock. It must not add a parallel provider registry.

Availability is capability-based. A runtime provider without the required stop and observation behavior must return a nonzero result before mutation. The issue does not require a direct container-engine fallback.

Related work:

No open issue or PR found in the duplicate search provides this user-facing operation.

Security or Privacy Impact

This command crosses the host, NemoClaw state, OpenShell gateway, sandbox, policy, credential, inference, and messaging trust boundaries.

Required controls:

  • Authenticate and authorize the exact sandbox and action at the owning boundary.
  • Bind mutations to the recorded gateway, runtime provider, lifecycle generation, and live target identity.
  • Persist the fence before an ordinary lifecycle path can reactivate the target.
  • Fail closed on ambiguous, replaced, or unproven target identity.
  • Keep the fence active after partial enforcement, interruption, or inconclusive verification.
  • Preserve credential custody. Do not copy credential values into the registry, receipt, logs, arguments, or sandbox.
  • Treat runtime-provider responses as enforcement claims. Record independent observed postconditions separately.
  • Require explicit release. Release must verify the same fence and target generation and must not start the sandbox.

The receipt may contain sandbox and provider identifiers, reason text, timestamps, operation outcomes, and evidence references. It must not contain credentials, policy bodies, prompts, tool inputs, tool outputs, messages, or workspace content.

Implementation Idea

Extend the existing runtime-provider bundle with one bounded quarantine capability. Reuse SandboxEntry.lifecycleGeneration, lifecycleLiveIdentityFingerprint, gatewayName, and gatewayPort for exact target binding.

Implement the orchestration beside the current sandbox stop action. Reuse the sandbox lifecycle lock and provider-specific lifecycle surface. Add durable fence and operation-receipt state to the existing NemoClaw sandbox registry or its established transaction state, subject to the accepted design.

The first capability slice should quarantine one registered sandbox through its selected runtime provider. Run-level fanout and any missing OpenShell enforcement primitives should remain separate follow-up work.

Category

Feature

Checklist

  • I searched existing issues and this is not a duplicate
  • I described the problem and desired behavior

Activity

  1. added
    area: cliCommand line interface, flags, terminal UX, or output
    area: sandboxOpenShell sandbox lifecycle, runtime, config, or recovery
    area: securitySecurity controls, permissions, secrets, or hardening
    needs: designRequires product or architecture direction
    needs: triageAwaiting maintainer classification
    on Aug 24, 2026
  2. jyaunches commented on Sep 2, 2026

    @jyaunches
    Contributor

    Maintainer direction: simplify before implementation

    The operator need may be valid: stop a sandbox, prevent NemoClaw from restarting it, and preserve its workspace and registry state. The current proposal and PR expand that need into a new qualification, exact-authority, transaction-journal, observation, and receipt system. We should not add that product and maintenance surface without a demonstrated requirement for those stronger guarantees.

    If this feature is still necessary, implement it as a small durable lifecycle hold:

    1. Add one bounded lifecycleHold record to the existing sandbox registry, containing an ID and creation time. A bounded operator reason may be included if needed.
    2. Add one shared lifecycle guard at the common activation boundaries. start, onboarding reuse or launch, recover, rebuild, restore destination, and upgrade must refuse while the hold is active.
    3. The hold command acquires the existing sandbox lifecycle lock, persists the hold before invoking the existing stop operation, and leaves the hold active if stop fails.
    4. Status reports the hold and the result of the stop request without claiming complete containment.
    5. A separate release command requires the matching hold ID, clears the hold under the lifecycle lock, and does not start the sandbox.
    6. Preserve the workspace and registry. Keep existing destroy behavior separate.

    Do not add a runtime-provider quarantine contract, per-agent qualification manifests, exact-container authority snapshots, operation journals, forensic receipts, independent postcondition observers, or idempotent transaction reconciliation unless a separate accepted requirement demonstrates why each guarantee is needed.

    Target a focused implementation: one registry field, one shared guard, two small commands, status output, and tests at the principal activation boundaries. If this cannot remain within roughly 8–15 files and 500–1,000 added lines, first centralize lifecycle authorization rather than scattering feature-specific checks.

    This narrower contract should state exactly what NemoClaw guarantees: it persists a lifecycle hold and requests the existing stop operation; NemoClaw-managed activation paths respect the hold. It should not claim security-grade incident containment or forensic evidence preservation.

  3. ericksoa commented on Sep 3, 2026

    @ericksoa
    MemberAuthor

    Maintainer decision: Defer — pending OpenShell support

    The operator workflow is valid, and a NemoClaw command can be a convenience surface, but the authoritative lifecycle hold belongs at the OpenShell gateway. I opened NVIDIA/OpenShell#3153 to request that capability.

    Decision:

    • Defer NemoClaw implementation until the upstream issue is accepted and a released OpenShell version exposes a durable, gateway-enforced hold plus explicit release.
    • Once available, NemoClaw may add thin nemoclaw <name> quarantine / release UX and map the upstream state into status. Enforcement and the restart prohibition must delegate to OpenShell; NemoClaw must not create a parallel durable lifecycle authority.
    • Do not implement the previously suggested NemoClaw-local lifecycleHold as an interim substitute. It could guard NemoClaw-managed activation paths, but it cannot block a direct OpenShell CLI, SDK, API client, reconciler, or another controller from starting the sandbox.
    • Until the upstream capability exists, stop remains an ordinary retained stop and must not be presented as quarantine or security-grade containment.

    This fits OpenShell's current scope: it already owns the authenticated gateway, durable sandbox lifecycle state, per-sandbox lifecycle serialization, cross-driver stop/start, and access shutdown. OpenShell #2652 / PR #2653 shipped the underlying storage-preserving stop/start primitive; #3153 is the missing “stopped and not startable until explicit release” state. The upstream request intentionally excludes forensic receipts, credential revocation, operation journals, and claims of complete incident containment.

    Dependency: NVIDIA/OpenShell#3153.

  4. added
    needs: unblockBlocked item needs dependency or decision resolved
    and removed
    needs: designRequires product or architecture direction
    on Sep 3, 2026
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

    area: cliCommand line interface, flags, terminal UX, or outputarea: sandboxOpenShell sandbox lifecycle, runtime, config, or recoveryarea: securitySecurity controls, permissions, secrets, or hardeningneeds: unblockBlocked item needs dependency or decision resolved

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions