Feature Request: Execution Guardrails for Tool Safety

Summary

Add configurable guardrails that intercept and validate tool executions (especially exec) before they run, with optional human-in-the-loop escalation for critical actions.

Problem

Currently, an AI agent can execute any command via the exec tool without any safety layer. This has caused real incidents:

• Agent deleted OAuth credentials trying to "fix" an auth issue
• No mechanism to block dangerous commands (rm, DROP, etc.)
• No automatic escalation for critical actions

The agent's "judgment" depends entirely on prompt engineering, which can fail.

Proposed Solution

1. Configurable Execution Guards

# openclaw.yaml
guardrails:
  exec:
    enabled: true
    
    # Block these patterns entirely
    block:
      - pattern: "rm -rf"
        message: "Recursive delete is blocked"
      - pattern: "DROP TABLE"
        message: "SQL DROP is blocked"
    
    # Require escalation for these patterns
    escalate:
      - pattern: "rm|delete|unlink"
        reason: "File deletion requires approval"
      - pattern: "token|credential|secret|password"
        reason: "Credential access requires approval"
      - pattern: "transfer|swap|send.*eth|send.*btc"
        reason: "Financial action requires approval"
    
    # Escalation settings
    escalation:
      channel: discord  # or telegram, slack, etc.
      timeout: 300      # seconds to wait for approval
      default: deny     # if timeout, deny the action

2. Escalation Flow

Agent wants to execute: rm /path/to/file
           ↓
Guardrail intercepts
           ↓
Pattern matches "rm" → escalation required
           ↓
Send message to configured channel:
  "⚠️ ESCALATION: Agent wants to delete /path/to/file
   Reply 'approve' or 'deny'"
           ↓
Wait for human response (with timeout)
           ↓
If approved → execute
If denied/timeout → block and return error to agent

3. Integration Options

Option A: Native Implementation

• Add guardrails logic directly to OpenClaw's exec handler
• Lightweight, no external dependencies
• Pattern matching + escalation channel integration

Option B: NeMo Guardrails Integration

• NVIDIA's open-source guardrails framework
• Already has "Execution Rails" concept
• More powerful but adds dependency
• https://github.com/NVIDIA/NeMo-Guardrails

4. Example User Experience

Agent: I'll clean up that corrupted token file...
       [Attempting: rm ~/.config/gcloud/credentials.json]

OpenClaw: ⚠️ Execution blocked - escalation required
          Sent approval request to Discord

Discord: 
  🚨 ESCALATION REQUIRED
  Agent: main
  Action: rm ~/.config/gcloud/credentials.json
  Reason: File deletion requires approval
  Reply: "approve abc123" or "deny abc123"

User: deny abc123

Agent: The deletion was denied. I'll find another solution.

Benefits

1. Safety: Prevents catastrophic mistakes even if agent judgment fails
2. Auditability: All escalations are logged
3. Flexibility: Users configure what needs approval
4. Human-in-the-loop: Critical actions require explicit approval
5. Trust: Users can give agents more autonomy knowing guardrails exist

Implementation Considerations

• Should work with all channels (Discord, Telegram, Slack, etc.)
• Needs timeout handling (what if user doesn't respond?)
• Should log all blocked/escalated actions
• Config should be hot-reloadable
• Consider "learning mode" that suggests patterns based on actual usage

Related Work

• NeMo Guardrails - NVIDIA's framework
• Guardrails AI - Output validation (less relevant)
• LangChain Tool Validators

Who Would Use This

• Anyone running autonomous agents that interact with filesystem/APIs
• Enterprise deployments requiring audit trails
• Developers who want to give agents autonomy safely
• Anyone who's been burned by an agent deleting something it shouldn't 😅

I'm happy to help implement this if there's interest!

/cc @openclaw/maintainers