openclaw-guardian

# OpenClaw Guardian

> The missing safety layer for AI agents.

## Why?

OpenClaw gives agents direct access to shell, files, email, browser, and more.
99% of that is harmless. Guardian catches the 1% that isn't — without slowing
down the rest.

## How It Works

```
Tool Call → Blacklist Matcher (regex rules, 0ms)
              ↓
   No match     → Pass instantly (99% of calls)
   Warning hit  → 1 LLM vote ("did the user ask for this?")
   Critical hit → 3 LLM votes (all must confirm user intent)
```

### Two Blacklist Levels

| Level | LLM Votes | Latency | Examples |
|-------|-----------|---------|---------|
| No match | 0 | ~0ms | Reading files, git, normal ops |
| Warning | 1 | ~1-2s | `rm -rf /tmp/cache`, `chmod 777`, `sudo apt` |
| Critical | 3 (unanimous) | ~2-4s | `rm -rf ~/`, `mkfs`, `dd of=/dev/`, `shutdown` |

### What Gets Checked

Only three tool types are inspected:

- `exec` → command string matched against exec blacklist
- `write` / `edit` → file path canonicalized and matched against path blacklist
- Everything else passes through instantly

### LLM Intent Verification

When a blacklist rule matches, Guardian asks a lightweight LLM: "Did the user
explicitly request this?" It reads recent conversation context to prevent
false positives.

- Warning: 1 LLM call. Confirmed → proceed.
- Critical: 3 parallel LLM calls. All 3 must confirm. Any "no" → block.

Auto-discovers a cheap/fast model from your existing OpenClaw provider config
(prefers Haiku). No separate API key needed.

### LLM Fallback

- Critical + LLM down → blocked (fail-safe)
- Warning + LLM down → asks user for manual confirmation

## Blacklist Rules

### Critical (exec)
- `rm -rf` on system paths (excludes `/tmp/` and workspace)
- `mkfs`, `dd` to block devices, redirects to `/dev/sd*`
- Writes to `/etc/passwd`, `/etc/shadow`, `/etc/sudoers`
- `shutdown`, `reboot`, disable SSH
- Bypass: `eval`, absolute-path rm, interpreter-based (`python -c`, `node -e`)
- Pipe attacks: `curl | sh`, `wget |...