[DeepSeek Harness 6/8] Enforce the accepted DeepSeek Harness trust and policy boundary

## Summary

Define and enforce the accepted DeepSeek Harness tool, plugin, profile, filesystem, process, network, browser, telemetry, and state trust boundary inside a NemoClaw-managed sandbox.

Parent epic: #9328

Depends on:

- #9329, **[DeepSeek Harness 1/8] Accept product scope, ownership, threat model, and compatibility matrix**;
- #9330, **[DeepSeek Harness 2/8] Produce a reproducible DeepSeek Harness candidate runtime**.

It must align with #9331 for user surfaces, #9332 for state and recovery, and #9333 for managed inference. #9335 consumes the resulting policy and negative-test evidence.

## Problem Statement

DeepSeek Harness is a plugin-composed agent runtime with shell and filesystem tools, profiles, skills, workflows, subagents, background work, optional code execution, project-controlled resources, Web settings, MCP, network tools, package installation, telemetry, and feedback paths. Several of those surfaces can execute instructions or change effective runtime behavior.

DSH's inner filesystem sandbox is not a network, host-control, or container boundary. Host and Origin checks on the Web server are reachability checks, not user authentication. A DSH approval prompt or settings restriction also cannot replace NemoClaw and OpenShell enforcement.

NemoClaw therefore needs an exact, versioned DSH trust matrix and a deny-by-default policy. Without it, repository content, restored state, a plugin, a browser action, or a tool process could expand filesystem or network access, recover an old trust decision, alter managed inference, contact telemetry/search endpoints, or seek sandbox lifecycle authority.

## Desired Behavior

Gate 1 defines one exact supported DSH preset, tool roster, approval behavior, configuration-source order, and enabled-feature matrix. Gate 6 turns that decision into a root-owned configuration envelope plus NemoClaw/OpenShell policy.

Only declared workspace and state paths are writable. Only the managed inference route and other explicitly accepted destinations are reachable. Undeclared plugins, profiles, skills, MCP servers, Web/search tools, package installation, self-update, telemetry, feedback export, Creator/Code modes, subagents, workflows, and background processes are unavailable unless Gate 1 accepts and Gate 7 qualifies them.

The outer sandbox policy remains authoritative. Any accepted DSH inner approval or filesystem restriction is defense in depth and must fail compatibly; it must not create a bypass, contradictory approval path, or false security claim.

## Scope

- Versioned DSH trust matrix covering every configuration, executable, browser, tool, plugin, skill, profile, project, state, and network source.
- Exact supported preset and tool roster, including the accepted behavior for shell, filesystem, code execution, workflows, subagents, and background jobs.
- Root-owned final configuration and policy overlays that untrusted or restored inputs cannot replace.
- Baseline network policy and explicit policy additions.
- Filesystem read/write/execute boundaries for workspace, DSH home, attachments, sessions, caches, and reconstructed runtime files.
- Process limits, subprocess cleanup, and denial of container-runtime, OpenShell lifecycle, host-control, and provider authorities.
- Browser reachability behavior consistent with Gate 3; no authentication claim based solely on Host or Origin checking.
- Telemetry, anonymous identity, feedback export, direct search/fetch, update, registry, package-installation, MCP, and external-plugin behavior.
- Log, status, diagnostics, snapshot, backup, restore, and evidence redaction.
- Negative security tests and exact policy evidence consumed by Gate 7.

## Required tests and evidence

The implementation PR must include an adversarial fixture containing conflicting DSH settings, a project profile, a project instruction, a skill, a plugin reference, an MCP definition, a package-install request, a direct-provider/search request, and restored executable trust state. Tests must prove each input is either accepted by the Gate 1 matrix or rejected without expanding authority.

At minimum, repository-owned tests must prove:

1. Declared workspace and state operations succeed, while reads, writes, execution, symlink traversal, and canonical-path escapes outside the accepted boundary fail.
2. Only accepted network destinations are reachable. Direct DeepSeek APIs, DSH search, telemetry, feedback, package registries, update endpoints, arbitrary web destinations, and local/host control addresses fail unless individually accepted.
3. The sandbox cannot access Docker or Podman sockets, OpenShell lifecycle credentials, host namespaces, provider credentials, or privileged control paths.
4. User settings, Web mutations, profiles, project resources, plugins, skills, MCP definitions, environment variables, and restored files cannot replace managed inference or policy authority.
5. Disabled Creator/Code modes, subagents, workflows, background jobs, external plugins, MCP, Web tools, package installation, and self-update remain undiscoverable or return stable fail-closed errors.
6. The accepted approval behavior is observable for shell and filesystem tools, and cancellation or disconnect cannot leave an ungoverned child process running.
7. Telemetry, anonymous identity, and feedback artifacts are neither emitted nor restored when Gate 1 disables them.
8. Backup, snapshot, restore, diagnostics, logs, and status preserve only accepted state and redact credentials, route material, browser tokens, and prohibited trust records.
9. The Gate 3 browser boundary remains intact under hostile Host, Origin, forwarded-header, unauthenticated, and direct-port requests.

Evidence must identify the exact NemoClaw commit, DSH package and integrity, managed-image digest, architecture, accepted trust-matrix version, generated-config digest, network/filesystem policy digest, test-fixture version, every positive and negative result, and the location of bounded secret-free artifacts.

## Documentation

- Add a contributor-facing trust matrix naming enabled, disabled, reconstructed, persistent, and prohibited DSH surfaces.
- Document which layer owns browser reachability, agent approvals, filesystem enforcement, network enforcement, process limits, lifecycle authority, inference authority, and credential custody.
- Record stable remediation text for denied plugins, project profiles, Web/search access, MCP, updates, packages, filesystem paths, and network destinations.
- Provide Gate 8 with verified user-facing limitations and security behavior. Do not advertise support before activation.

## Constraints and Non-goals

- Do not install or run DSH directly on the user host.
- Do not grant DSH a Docker or Podman socket, OpenShell lifecycle credential, host administration, privileged post-start mutation, or provider credential.
- Do not treat DSH's inner filesystem sandbox, approval UI, Host check, or Origin check as the outer security boundary.
- Do not grant unrestricted network, filesystem, plugin, profile, project, MCP, package-installation, or update access.
- Do not trust repository-provided executable configuration by default.
- Do not let snapshots or backups restore executable trust or managed configuration authority.
- Do not store credential-bearing, browser-authentication, or prohibited identity state in images, backups, logs, diagnostics, or public evidence.
- Do not duplicate compute-runtime policy or add a DSH-specific lifecycle implementation.
- Do not expand the Gate 1 product surface while implementing policy.

## Acceptance Criteria

- [ ] Gate 1's exact DSH preset, tool roster, approval behavior, configuration precedence, and enabled-feature matrix are versioned and enforced.
- [ ] A DSH-specific deny-by-default network policy permits only accepted destinations.
- [ ] Filesystem policy permits only declared runtime, workspace, attachment, and persistent-state operations.
- [ ] The outer sandbox policy remains authoritative and any enabled DSH inner restriction is qualified as defense in depth.
- [ ] User, Web, project, profile, skill, plugin, MCP, environment, and restored inputs cannot expand managed inference or policy authority.
- [ ] Every feature disabled by Gate 1 is unavailable with stable fail-closed behavior.
- [ ] DSH cannot access host control, container-runtime sockets, OpenShell lifecycle authority, or upstream provider credentials.
- [ ] Browser negative tests prove the exact Gate 3 authentication or loopback-only boundary and make no Host/Origin-only authentication claim.
- [ ] Cancellation, timeout, disconnect, restart, and destroy leave no ungoverned DSH child process.
- [ ] Telemetry, feedback export, anonymous identity, direct search, package installation, and self-update follow the accepted policy and cannot reappear through restore.
- [ ] Logs, status, diagnostics, snapshots, backups, and evidence redact credential- and token-bearing content.
- [ ] Adversarial positive and negative tests cover every source listed in the required fixture.
- [ ] Evidence binds the exact runtime, image, trust matrix, configuration, and policy identities to every test result.
- [ ] Contributor documentation defines the authority split and Gate 8 has verified security limitations to publish.

## Category

Feature

## Checklist

- [x] I searched existing issues and this is not a duplicate.
- [x] I described the problem and desired behavior.

Start by reading the parent epic #9328 and dependencies #9329-#9333 to establish the accepted runtime, user surfaces, state, and inference boundaries. Use the required adversarial fixture and numbered security tests as the first validation map; done means the Gate 1 matrix and Gate 6 policy are enforced, fail closed, and produce the specified secret-free evidence and documentation.

Written by the indexing model from the issue text.