Hook a Permission Layer onto Dangerous Tools

The route

4 steps to Done

1. 01

   Define the danger rule set

   Enumerate what must never run silently - concretely.

   Preview prompt + verify gate ▾ Hide ▴

   Write the danger rules as data. COMMAND PATTERNS (normalized before matching: resolve quoting, collapse whitespace): recursive deletion (rm -rf and equivalents on any path), git destructive ops (force-push, hard reset on shared branches, clean -fdx), bulk data ops (DROP/TRUNCATE, mass UPDATE without WHERE), package/system mutations (global installs, chmod -R 777, curl piped to shell). PROTECTED PATHS for writes and deletes: .env* and secret/key files, .git internals, paths outside the workspace root, CI and infra configs (approval, not block). Assign each rule a verdict (approval vs block) and a reason string. Store as a versioned config file. Review the list against my actual toolset and add tool-specific rules where needed.

   • ✓ Patterns match normalized commands
   • ✓ Protected paths cover secrets and workspace escape
   • ✓ Every rule has a verdict and reason
2. 02

   Implement the hook point

   One interception point, running before anything executes.

   Preview prompt + verify gate ▾ Hide ▴

   Build the pre-tool-use hook into the dispatch path. Mechanics: after schema validation and before handler execution, run the hook chain with {tool, arguments, session context}; each hook returns allow / require-approval(reason) / block(reason); the strictest verdict wins; require-approval routes to the approval UX with full call details; block short-circuits with a structured refusal to the model ('blocked by policy: [reason]'). Hooks are ordinary functions loaded from harness config plus project config (next step). Failure containment: a hook that throws counts as block-with-error, never as allow. Implement the danger rules from step 1 as the first hook and unit-test verdicts across a matrix of calls.

   • ✓ Hooks run before every execution
   • ✓ Strictest verdict wins
   • ✓ Hook exceptions fail closed
3. 03

   Harden the patterns against evasion

   The gap between a pattern and its intent is where accidents live.

   Preview prompt + verify gate ▾ Hide ▴

   Red-team the rules. Try the evasions: path tricks (rm -rf ./, rm -rf $HOME, cd /important && rm -rf .), quoting and splitting ('r''m' -rf, echo rm -rf | sh), indirection (writing a script with the dangerous command then executing it, invoking via xargs/find -delete), and interpreter smuggling (python -c os.system(...)). For each evasion that passes: fix by strengthening normalization (argument resolution, working-directory awareness) or adding rules (script-write-then-execute detection: flag executing a file the agent just wrote, requiring approval). Accept and document the residual risk that patterns cannot be complete - which is why approval tiers and sandboxing exist as the next layers. Record the evasion suite as permanent tests.

   • ✓ Path, quoting, and indirection evasions tested
   • ✓ Just-written-script execution flagged
   • ✓ Residual risk documented, not denied
4. 04

   Make it extensible and drill it

   Projects have their own dragons - let them add rules.

   Preview prompt + verify gate ▾ Hide ▴

   Add project extensibility and run the live drill. EXTENSIBILITY: the harness loads additional hooks/rules from a project config file (e.g. .agent/hooks with pattern rules in config plus optional script hooks); document the format with two examples (protect a data/ directory; require approval for migrations). Validate project hooks on load. DRILL: on a real task, script the agent into attempting a blocked command, an approval-tier command, and a protected-path write; verify each verdict, the model's adaptation after refusal, and the decision log entries. Confirm a project rule added mid-session takes effect on next dispatch.

   • ✓ Project hook format documented with examples
   • ✓ Drill covers block, approve, and protected write
   • ✓ Model adapts after refusals instead of stalling

Research-backed

Sources behind this flow