Production Security Mode: DefenseClaw, Sandboxing, and Fail-Closed Design

NetClaw's Production Mode, tracked internally as Feature 057, is the point where the system stops describing risk and starts enforcing against it. Activated by setting N2N_RISK_MODE=production, it composes four layered controls — kernel-level member confinement, an LLM guardrail proxy, an immutable Git audit trail, and honest posture reporting — into a single fail-closed policy. The organizing principle, stated directly in the README, is that production mode "never lies" about its own security gaps: it either enforces a control, or it reports precisely which control is missing and blocks accordingly. This section walks through each layer, why NetClaw chose kernel confinement over containers for live-infrastructure members, and how its asymmetric degradation model decides what blocks and what merely runs flagged.

Feature 057: Four Layered, Fail-Closed Controls

Production mode is deliberately not a single toggle guarding a single chokepoint. It stacks independent controls so that a failure in one does not silently collapse the others. The Member Sandbox provides host-level kernel confinement for each running member. Model-Guard routes all model I/O through the DefenseClaw proxy for prompt and response inspection. The Audit Trail (GAIT) commits every delegation, enrollment, removal, and quarantine to an append-only Git store at ~/.openclaw/n2n/gait/, cross-referenced to a SQLite database on both Border and member sides. Least privilege is enforced by construction: each member receives only its integration's .env slice, while the sandbox hides the operator's master .env entirely. The stdio-first MCP transport (JSON-RPC 2.0, via scripts/mcp-call.py) is what makes this composition practical — because members talk over stdio rather than network sockets, they can be wrapped in a systemd unit with no container runtime in the path.

systemd Kernel Confinement — and Why Containers Were Rejected

Each member runs as a hardened systemd unit; on-demand members cold-start in transient systemd-run units. Confinement is built from native Linux kernel primitives applied before the process starts, so the entire process tree inherits the sandbox. NoNewPrivileges=true sets the kernel's no_new_privs flag, blocking privilege escalation through setuid binaries or file capabilities — an exploited member cannot invoke sudo to reach root. ProtectSystem=strict places the service in its own mount namespace with /usr and /etc read-only and writes denied everywhere except paths named in ReadWritePaths=. ProtectHome=yes masks /home, /root, and /run/user, hiding SSH and GPG keys, and PrivateTmp=true gives the member a private /tmp to prevent temp-file snooping. Critically, none of this requires code changes and it re-applies on every start.

[Service]
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=true
SystemCallFilter=@system-service
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
ReadWritePaths=/var/lib/netclaw /var/log/netclaw

The design rationale is explicit and pointed. OpenShell containers were evaluated and rejected for live-infrastructure members because they produce "empty, egress-denied sandboxes" — useless for a member whose entire job is to touch real network devices and real APIs. As the README puts it, "host confinement is what actually works": the member keeps its real tools and network access but is kernel-confined against the operator's own machine. Container isolation solves the wrong problem for live infra; systemd hardening constrains what a compromised member can do to the host without stripping the tooling that makes it functional.

DefenseClaw Guardrail Proxy and the OpenShell Sandbox

Model I/O in production mode routes through DefenseClaw, a Go guardrail proxy (from Cisco AI Defense) listening on :4000. It implements the industry-standard "sandwich" pattern of an AI firewall: an input guardrail inspects prompts and retrieved context before they reach the model, and an output guardrail inspects responses before they return or trigger downstream tool calls. This catches prompt injection, jailbreaks, and data exfiltration at a single audited chokepoint, and its runtime guardrails span six rule categories. Skills and MCP sets are component-scanned before execution, and CodeGuard analysis flags hardcoded credentials, eval, raw shell commands, and SQL injection. Audit output is SQLite-backed with SIEM export (Splunk HEC, OTLP).

flowchart LR
    A["Member delegation"] --> B["DefenseClaw input guard (:4000)"]
    B -->|"clean"| C["LLM provider"]
    B -.->|"prompt injection / secret / policy"| X["Block: fail closed"]
    C --> D["DefenseClaw output guard (:4000)"]
    D -->|"clean"| E["Response to member"]
    D -.->|"DLP / prompt leak / bad tool args"| X
    B -.->|"guard unavailable"| X
    D -.->|"guard unavailable"| X

Where DefenseClaw does use container-grade isolation is the optional OpenShell sandbox for command execution, which layers kernel-level confinement — Landlock, seccomp, and namespaces — around individual command runs. This is the appropriate place for empty-sandbox isolation, precisely because it wraps discrete commands rather than a live-infrastructure member.

Honest Posture Reporting and Asymmetric Degradation

Production mode reports one of three states and refuses to overstate any of them: testing, production — enforced, or production — DEGRADED (<controls> missing). No false "enforced" claim is ever made when a control is absent — degradation is explicit, never silent. This directly implements the fail-closed principle that failure must be visible and contained rather than passing unnoticed until a breach.

The degradation model is deliberately asymmetric, drawing a line between containment and audit. Containment gaps — a missing Member Sandbox or an unavailable Model-Guard — block. Concretely, if the DefenseClaw guard is down, delegations fail closed: there is no silent fallback to a direct LLM provider API, closing the exact bypass an attacker would try to induce. Audit-only gaps behave differently: if the GAIT trail is unavailable, the system runs flagged as audit-degraded rather than halting, on the reasoning that losing the record is serious but not an active containment breach. An operator who rejects even that leniency sets N2N_STRICT_ALL=1, which blocks on any gap, containment or audit alike.

stateDiagram-v2
    [*] --> Testing
    Testing --> Enforced: "all controls present"
    Enforced --> Blocked: "containment gap (sandbox or Model-Guard missing)"
    Enforced --> Degraded: "audit gap (GAIT unavailable)"
    Degraded --> Blocked: "N2N_STRICT_ALL=1"
    Blocked --> Enforced: "control restored"
    Degraded --> Enforced: "audit restored"

    note right of Blocked
        "Delegations fail closed, no direct-provider fallback"
    end note
    note right of Degraded
        "Runs flagged as audit-degraded"
    end note

# Enable DefenseClaw + OpenShell on an existing install
./scripts/defenseclaw-enable.sh

# Start NetClaw with production controls enforced
export N2N_RISK_MODE=production
./scripts/netclaw-secure-start.sh

# Optional: block on any gap, including audit-only degradation
export N2N_STRICT_ALL=1

DefenseClaw can also be enabled at install time by answering y to the "Enable DefenseClaw (recommended)?" prompt during ./scripts/install.sh. Whichever path is taken, the enforcement posture is what NetClaw treats as non-negotiable: the system's report of its own security state is honest, and the controls that matter for containment fail closed.

References