[Bug]: `security.otp.gated_actions` silently accepts unknown action names

Affected component

security/sandbox

Severity

S2 - degraded behavior (security-visible: config can appear to protect actions it does not)

Current behavior

security.otp.gated_actions accepts any arbitrary string without validation. Example:

[security.otp]
enabled = true
gated_actions = ["kubectl_write"]

Loads cleanly. kubectl_write does not correspond to any registered tool or action in the runtime — grep -r kubectl_write crates/ returns zero hits. There is no warning at config-load time and no runtime log indicating the entry is a no-op.

Expected behavior

The config loader should either:

1. Reject unknown gated_actions entries with a clear error listing the known action names, or
2. Warn at daemon start, emitting a log line for each gated_actions entry that does not correspond to a known action/tool identifier.

Either path prevents operators from believing they have a gate configured for an action that cannot possibly be gated.

Steps to reproduce

# ~/.zeroclaw/config.toml
[security.otp]
enabled = true
gated_actions = ["this_is_not_a_real_action", "kubectl_write"]

systemctl --user restart zeroclaw
journalctl --user -u zeroclaw --since "1m ago" --no-pager | grep -i otp
# => no warning about unknown actions

The daemon starts cleanly, no warning, no log line acknowledging that both entries are non-matching.

Impact

Silent failure mode with security implications. Operators configuring gated_actions often believe they are adding a defensive layer on destructive actions. If they typo an action name, use an outdated name, or invent a name (as in the kubectl_write example), zeroclaw accepts it without feedback. The operator then believes the action is TOTP-gated; it is not.

This is particularly sharp given the broader enforcement gap tracked in #3767 (ex-#1159), where the OTP tool-execution enforcement pipeline is not wired through at all — any gated_actions entry is currently a no-op regardless of whether the name is valid. The lack of name validation on top of that compounds the false-sense-of-security risk.

Even once enforcement is implemented per #3767, name validation remains a separately valuable, smaller, orthogonal fix.

Related

• #3767 — Cross-channel TOTP gate for critical tool execution (OPEN, open feature request)
• #1159 — OTP Phase 2: Tool Execution Pipeline Integration (CLOSED-completed, but the integration does not appear in current source)

Suggested fix

At config load (crates/zeroclaw-config/src/schema.rs validation pass), cross-check each gated_actions entry against a central registry of known action/tool identifiers. For unknown entries, either return a config error listing the valid options, or at minimum emit a warn! log line at daemon start.

The registry can be populated by the same mechanism that registers tools at runtime, or kept as a static list adjacent to the existing default_otp_gated_actions() function.

Version

zeroclaw 0.6.9, source at commit bf5873c (2026-04-15).