Component

• Product: NemoClaw / NemoHermes integration
• Area: Hermes gateway startup env validation (runtime secrets guard)

Environment

• Host: DGX Spark
• NemoClaw / NemoHermes version: v0.0.60
• Hermes container: openshell-hermes-… (ID from docker ps)
• Inside container:
  • Hermes CLI: /usr/local/bin/hermes
  • Hermes source: /opt/hermes (no /opt/hermes/start.sh present)

Summary

The NemoHermes security test plan expects Hermes gateway startup to refuse raw secret-shaped env vars (e.g. SLACK_BOT_TOKEN=xoxb-real-1234567890) with a [SECURITY] message and non-zero exit. In the current NemoHermes sandbox, starting the gateway via hermes gateway run with such an env var produces no security warnings or rejections; the process starts normally, and /tmp/hermes-runtime.log contains no [SECURITY] lines.

Steps to Reproduce

1. Identify the Hermes container:

HERMES_CONTAINER=$(docker ps -q --filter name=openshell-hermes)
echo "$HERMES_CONTAINER"
# Example: 160da56dc993

2. Ensure Hermes gateway is not currently running:

docker exec -u sandbox "$HERMES_CONTAINER" pgrep -fl 'hermes gateway' || echo "no hermes gateway"

3. Start Hermes gateway inside the container with a raw Slack-shaped token in the environment (no real token required):

docker exec -u sandbox \
  -e HOME=/sandbox \
  -e SLACK_BOT_TOKEN=xoxb-real-1234567890 \
  "$HERMES_CONTAINER" \
  hermes gateway run 2>&1 | head -40 | tee /tmp/hermes-runtime.log

Let it print some output, then interrupt with Ctrl+C.

4. Inspect the captured log for security messages:

cat /tmp/hermes-runtime.log
grep -F "[SECURITY]" /tmp/hermes-runtime.log || echo "no SECURITY rejection found"

Result:

no SECURITY rejection found

No [SECURITY] lines and no mention of SLACK_BOT_TOKEN in the log, despite the env containing a secret-shaped value.

Expected Behavior

When launching hermes gateway with a raw token like SLACK_BOT_TOKEN=xoxb-real-1234567890 in the environment:

• Startup should be refused with a clear [SECURITY] message, e.g.:

  [SECURITY] Refusing Hermes startup because raw secret-shaped values are present in the runtime environment
  [SECURITY] SLACK_BOT_TOKEN
  

• Hermes gateway should exit with a non-zero status and must not bind its port.
• Only allow-listed keys (such as OPENCLAW_GATEWAY_TOKEN) and placeholder forms (xoxb-OPENSHELL-RESOLVE-ENV-*) should be accepted without security warnings.

Actual Behavior

Running hermes gateway run with SLACK_BOT_TOKEN=xoxb-real-1234567890 and HOME=/sandbox:

docker exec -u sandbox \
  -e HOME=/sandbox \
  -e SLACK_BOT_TOKEN=xoxb-real-1234567890 \
  "$HERMES_CONTAINER" \
  hermes gateway run 2>&1 | head -40 | tee /tmp/hermes-runtime.log
grep -F "[SECURITY]" /tmp/hermes-runtime.log || echo "no SECURITY rejection found"

Yields:

no SECURITY rejection found

The gateway starts (or attempts to start) with the raw, secret-shaped env var. There is no [SECURITY] message and no mention of SLACK_BOT_TOKEN in the startup output. This contradicts the test specification that raw secret-shaped values in the runtime environment should cause Hermes startup to be refused and logged as a security event.

Notes / Related Gaps

• The original NemoHermes test steps reference /opt/hermes/start.sh and --dry-validate-only, but this NemoHermes image does not provide that script, and hermes gateway does not support --dry-run. Only the hermes CLI and its gateway subcommand are available.
• Earlier attempts using hermes gateway without HOME=/sandbox failed with a PermissionError on /root/.hermes/.env, which is not mentioned in the test plan (it assumes a different HOME/ownership layout for Hermes state).
• These discrepancies suggest the current NemoHermes integration and Hermes build do not yet implement the documented "runtime env secret guard" path, or implement it only for a different entrypoint.