Add blackwall-guard example — BLACK_WALL pre-action risk gate for OpenClaw agents

[bluetieroperations-create]

What this adds

examples/blackwall-guard/ — a community integration that adds a pre-action risk gate to an OpenClaw agent running under NemoClaw. It hooks before_tool_call and screens every tool call through the external BLACK_WALL forecast() service before it runs — returning GO / CAUTION / STOP, a risk score, named red flags, and an Ed25519-signed, offline-verifiable receipt.

• observe mode (default): logs the verdict, never blocks — safe to trial.
• enforce mode: STOP blocks; CAUTION blocks by default (this runtime has no interactive approval surface), carrying the red-flag detail in the block reason. Configurable via cautionAction.
• Defense-in-depth against destructive commands, irreversible writes, exfiltration, or fund movement a compromised / prompt-injected agent might attempt — independent of the model's own judgment.

Contents

index.ts (plugin), openclaw.plugin.json (manifest), skills/blackwall-policy + skills/blackwall-verify, and index.test.ts — a Vitest suite covering the before_tool_call decision state machine, the HTTPS-only credential guard, and the proxy CONNECT-header size cap.

Context

This began as a nemoclaw-blueprint plugin PR on the main repo (NVIDIA/NemoClaw#4692). Per the maintainer's guidance there — that an independent third-party runtime integration belongs in nemoclaw-community rather than core — I've moved it here, as I offered on that PR. The code is unchanged from the version reviewed there (including the security fixes from that review). The README frames it clearly as an independent third-party integration calling an external service, not a NemoClaw-supported surface.

Checks

• DCO: commit is signed off.
• License Headers: scripts/check_license_headers.py --check passes locally (.ts files carry SPDX headers).
• No new dependencies; nothing added to THIRD-PARTY-NOTICES.

Co-Authored-By: Claude Opus 4.8 noreply@anthropic.com

[slopp]

Thanks @bluetieroperations-create; apologies for the delay in review. Could you please add an entry in the top-level README table? Also left a few minor comments

[slopp]

It would be better if the credential was never in the sandbox at all. Is it possible to create an openshell provider and openshell policy that allows the blackwall API requests explicitly, and performs the cred injection at the openshell proxy egress?

[slopp]

Please make it clear in this note who a user would contact for support and that this PR requires a paid API key

[bluetieroperations-create]

Thanks @slopp — addressed all three:

• Top-level README table: added a BLACK_WALL Preflight Guardrail row to the Reference Examples table.
• Support + key: the intro note now states it requires a BLACK_WALL API key (free tier, with usage-based pricing above it) and that support is provided by BlueTier Operations, not NVIDIA (contact + link included).
• Credential injection at egress: great call — keeping the secret out of the agent's reach is Black_Wall's own thesis, so I've made it the recommended deployment. Added providers/blackwall.yaml (auth_style: bearer) + policy.yaml scoping egress to just POST /api/v1/forecast and .../outcome, mirroring the personal-community-sentiment-triage provider/policy pattern. BLACKWALL_API_KEY is only an OpenShell placeholder inside the sandbox; the L7 proxy injects the real key on egress, so it never enters the sandbox. The plugin needs no change. Happy to tweak the exact placeholder/injection wiring if your current OpenShell schema differs from the example I mirrored.

Appreciate the thorough review.