canary

扫描您的 OpenClaw 环境中是否存在泄露的秘密 - API 密钥、令牌、凭据 .env 文件、已安装的技能和 shell 历史记录。启动时静默运行，深度扫描 按需。经您许可修复问题。

## 概述（中文）

扫描您的 OpenClaw 环境中是否存在泄露的秘密 - API 密钥、令牌、凭据
.env 文件、已安装的技能和 shell 历史记录。启动时静默运行，深度扫描
按需。经您许可修复问题。

## 原文

# 🐦 Canary

**Your agent's early warning system for exposed secrets.**

Canary watches for leaked API keys, tokens, passwords, and credentials hiding in your OpenClaw environment. It explains what it finds in plain language — no security jargon — and offers to fix problems for you with a single confirmation.

---

## How It Works

Canary operates in two modes:

### 🔅 Light Scan (runs automatically on startup)

Every time OpenClaw starts, Canary performs a quick, silent check of the most critical locations:

- `~/.openclaw/.env` and `~/.clawdbot/.env` for plaintext credentials
- File permissions on config files containing secrets (world-readable = bad)
- Any `.env` files in the active workspace

**If everything is clean**: Canary stays silent.
**If something is found**: Canary shows a short alert with the option to fix it or get more detail.

### 🔍 Deep Scan (runs when you ask)

Ask for a full security check whenever you want. The deep scan covers everything in the light scan **plus**:

- All installed skill directories for hardcoded secrets
- Session/chat history files for accidentally pasted credentials
- Git repositories in the workspace for committed secrets
- SSH keys and config (`~/.ssh/`) for weak permissions
- Shell history files for commands containing tokens or passwords
- Known credential file paths (`.netrc`, `.npmrc`, `.pypirc`, Docker config, AWS credentials, etc.)

---

## What Canary Looks For

Canary uses pattern matching and heuristic checks to detect:

| Secret Type | Examples | Where It Looks |
|---|---|---|
| **API Keys** | Shodan, VirusTotal, OpenAI, Anthropic, AWS, GCP, Stripe, GitHub tokens | `.env` files, skill configs, shell history, git repos |
| **Passwords** | Plaintext passwords in configs, database connection strings with embedded passwords | Config files, `.env`, `.netrc`, skill directories |
| **Private Keys** | SSH private keys, PEM files, JWTs with embedded secrets | `~/.ssh/`, workspace, skill directories |
| **Cloud Credentials** | AWS access keys, GCP service account JSON, Azure tokens | `~/.aws/`, `~/.config/gcloud/`, env vars, configs |
| **Tokens & Sessions** | OAuth tokens, bearer tokens, session cookies, webhook URLs | Chat history, shell history, `.env` files |
| **Local System Files** | Credential exports, service account JSONs, PEM/key files, password manager CSV exports, Kubernetes tokens, Terraform state secrets, database passwords | `~/Downloads/`, `~/Desktop/`, `~/Documents/`, `~/.kube/config`, `*.tfstate`, `~/.config/`, `~/Library/Application Support/`, `~/.my.cnf`, `~/.pgpass`, browser password export CSVs, Redis/MongoDB configs |

### Severity Levels

Each finding gets a clear severity:

- 🔴 **Action needed** — Real exposure right now. Example: *"Your AWS secret key is in a world-readable file. Anyone logged into this computer can see it."*
- 🟡 **Heads up** — Moderate risk, should fix when convenient. Example: *"Your SSH key file permissions are a bit loose. It works fine, but tightening them is good practice."*
- 🟢 **Good** — Checked and clean. Example: *"Your .env files are locked down properly."*

---

## Auto-Fix

⚠️ **Canary will never change, move, or delete anything on your system without asking you first.** Every fix is shown to you in full before it happens. You can always say no, and Canary will give you a step-by-step guide to do it yourself instead.

| Issue | What Canary Will Do (with your OK) | You'll See |
|---|---|---|
| Your .env file can be read by other users on this machine | Make the file private to your account only | *"Your API keys are visible to others on this computer. Mind if I make this file private?"* |
| Secret pasted in your shell history | Remove that one line from your history | *"Your Stripe key is in your command history. OK to remove just that line?"* |
| SSH key file isn't locked down | Restrict the key file to your account only | *"Your SSH key is a little too open. OK if I tighten it up?"* |
| API key hardcoded inside a skill | Move the key to your .env file and reference it from there | *"Found an API key written directly in a skill. Want me to move it somewhere safer?"* |
| Secret committed to a git repo | Add the file to .gitignore so it won't be shared again | *"A secret got saved in your git history. I can stop it from spreading — but you'll also want to get a fresh key."* |
| Credential file sitting in Downloads/Desktop/Documents | Move the file to a secure location with private permissions | *"There's a key file just sitting in your Downloads. Want me to tuck it somewhere safe?"* |
| Kubernetes config with embedded tokens is too open | Make the config file private to your account | *"Your Kubernetes config has tokens in it and it's a bit exposed. OK to lock it down?"* |
| Terraform state file with plaintext secrets | Flag and restrict file permissions | *"Your Terraform state has passwords in plain text. Mind if I restrict who can read it?"* |
| Database config with embedded password | Restrict the config file to your account only | *"Your database config has a password that others can see. OK to make it private?"* |
| Browser password export CSV left unprotected | Move to a secure location or securely delete | *"There's an exported password file out in the open. Want me to move it somewhere private, or just delete it?"* |

**If you say no to any fix**, Canary will walk you through doing it yourself — plain language, step by step, no jargon.

**Before every fix**, Canary creates a backup of the affected file at `<workspace>/.canary/backups/` with a timestamp (e.g., `.env.2026-02-07T14:30:00.bak`). If anything goes wrong, you can ask Canary to roll back:

- *"Canary, undo that last fix"*
- *"Restore my .env file"*

Backups are stored with owner-only permissions and automatically deleted after 7 days. Canary will never back up files in a way that creates additional copies of secrets in less-secure locations.

**Backup security:**
- Backups are encrypted at rest using a key derived from the machine's unique identifier. They cannot be read by simply opening the file — only Canary's rollback process can decrypt them.
- Canary **never scans its own backup directory**. The path `<workspace>/.canary/backups/` is permanently excluded from all scans to avoid false feedback loops where Canary re-flags the secrets it just backed up.
- The backup directory is created with owner-only permissions (`700`). If another process changes these permissions, Canary will alert the user on the next startup.
- Backups older than 7 days are securely deleted (overwritten before removal) rather than simply unlinked.

---

## Instructions for the Agent

You are the Canary security skill. Your job is to protect the user's secrets and credentials.

### On Startup (Light Scan)

1. Silently check these locations:
   - `~/.openclaw/.env`, `~/.clawdbot/.env`, and any `.env` in the current workspace
   - File permissions on all config files found above
2. If **no issues found**:
   - **First time Canary runs**: show a brief all-clear so the user knows it's active. Example: *"🐦 Canary checked your environment — everything looks clean."*
   - **Every startup after that**: stay silent. No news is good news.
3. If **issues found**: display a single line with the total count and the most critical issue, plus an offer to fix. Example: *"🐦 Canary found 2 issues — your OpenAI key is in a file others on this computer can read. Want me to fix this?"*
   Do NOT dump a full report unprompted. Wait for the user to ask for details on the rest.
4. **Suppress repeated alerts.** If the same issue was flagged on the previous startup and the user has not addressed it, do not alert again. Instead, track it silently. If the same issue persists for 3+ consecutive startups, surface it one more time with gentler framing: *"🐦 Reminder: that .env permi