agent-command-approval-gatelisted

# Agent command approval gates How to decide that a command an agent is about to run needs a human. Built and re-built across two hosts over five days; every failure mode below is one that actually shipped. The config-and-hook side of gating lives in `openclaw-deployment` (Gotcha 2, `tools.exec.security` vs `ask`) and `hermes-agent-deployment` (`DANGEROUS_PATTERNS`, `approvals.mode`). **This skill is about the part those don't cover: matching.** Getting the hook to fire is easy. Deciding *which* commands it fires on is where every real bug was. ## Why matching is the hard part An approval gate has exactly two ways to fail: - **Under-gate** — a privileged command runs with no prompt. Silent. Presents as "no prompt fired", indistinguishable from the gate not being installed. This is the failure that matters. - **Over-gate** — a harmless command prompts. Noisy, fail-safe, and *not* free: an approval the human clicks through without reading is worth less than no approval at all. Both implementations here carry that reasoning in their own headers. So the target is not "match aggressively." It is **match exactly the invocations, and nothing that merely mentions them.** That turns out to be a parsing problem, not a pattern problem. ## The three designs, in the order they get invented Every implementation walks this path. Skip to design 3. ### 1. Substring — over-gates ```ts re: /\bhey\s+compose\b/ ``` `grep hey compose`, `cat` of a script containing the string, `ls