agentleFS
Cat-tjCat-tj/secret-scanner/SKILL.md

secret-scanner

Skill0 starsChanged 7 months agoMITView on GitHub

Offline secret and credential scanner powered by TruffleHog. Scans git repos, filesystems, and Docker images for leaked API keys, passwords, tokens, and 800+ secret types. ZERO outbound network calls — all detection is local. Use for security audits, pre-commit checks, or periodic scans of your codebase.

  • Reads credentials

5 other projects use a version of this.

Adopted by

Most recently taken up by

  • Other versions5 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

The file

We split this skill into the rules it gives an agent

4 rules. 0 are common, 3 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 5 edited versions we read keep these.

  • 3

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    When asked to scan for secrets:

    line 81
  2. Distinctive:

    Before any deployment, scan the target directory:

    line 107
  3. Distinctive:

    NEVER log, print, or include vault values in chat/memory

    line 151
  4. Very specific:

    NEVER commit .vault/ to git

    line 152

“Common” is measured: kept by at least 6 in 10 of the 5 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Secret Scanner (Offline)

Detect leaked credentials in your code and files using TruffleHog — completely offline. No data ever leaves your machine.

⚠️ CRITICAL SAFETY RULES

  1. ALWAYS use --no-verification — this prevents TruffleHog from making ANY outbound API calls
  2. NEVER run without --no-verification — verification mode sends your secrets to external APIs to check if they're valid, which IS the leak
  3. NEVER use trufflehog github, trufflehog s3, or any remote source — only filesystem and git file://
  4. Results contain secrets — NEVER paste raw results into chat, logs, or shared channels. Summarize only (e.g. "Found 3 AWS keys in server.js")

Binary Location

~/bin/trufflehog

Usage

Scan a directory (filesystem)

bash ~/.openclaw/workspace/skills/secret-scanner/scripts/scan.sh /path/to/directory

Scan a git repo (local only)

bash ~/.openclaw/workspace/skills/secret-scanner/scripts/scan.sh /path/to/repo --git

Scan with JSON output (for parsing)

bash ~/.openclaw/workspace/skills/secret-scanner/scripts/scan.sh /path/to/directory --json

Quick scan of all our repos

bash ~/.openclaw/workspace/skills/secret-scanner/scripts/scan-all.sh

What It Detects

800+ secret types including:

  • AWS keys (AKIA...)
  • Google Cloud credentials
  • GitHub/GitLab tokens
  • Stripe keys
  • Database connection strings
  • SSH private keys
  • JWT tokens
  • Telegram bot tokens
  • Slack webhooks
  • Generic high-entropy strings
  • And 790+ more...

How It Works

  1. TruffleHog scans files byte-by-byte using regex patterns + entropy analysis
  2. Matches against 800+ known credential patterns
  3. Reports: detector type, file, line number, raw match (redacted in our output)
  4. --no-verification ensures ZERO network traffic

Interpreting Results

Results are categorized as:

  • Unverified — pattern matches a known secret format (most results with --no-verification)
  • Filtered — low-confidence match filtered by entropy

What to Do With Results

  1. True positive — rotate the credential immediately, remove from code, add to .gitignore or .env
  2. False positive — test data, examples, already-revoked keys. Note and ignore.
  3. Historical (in git) — credential was in an old commit. Still rotate it — git history is permanent.

Agent Procedure

When asked to scan for secrets:

1. Determine target: specific path, repo, or "everything"
2. Run scan.sh with --no-verification (ALWAYS)
3. Parse results
4. Report SUMMARY ONLY:
   - Number of findings per type
   - Which files are affected
   - Severity assessment
   - DO NOT include actual secret values
5. Recommend remediation:
   - Which credentials to rotate
   - How to remove from git history (git filter-branch or BFG)
   - How to prevent future leaks (.gitignore, .env, pre-commit hooks)

Integration

Heartbeat check (weekly)

Add to HEARTBEAT.md:

- Weekly: Run secret scanner on key repos

Pre-deploy check

Before any deployment, scan the target directory:

bash skills/secret-scanner/scripts/scan.sh /path/to/deploy --json | jq '.DetectorName' | sort | uniq -c

Pipeline integration

The pipeline-orchestrator can call this in VERIFY stage to ensure no secrets leaked during implementation.

Excluded Paths

The scan script automatically excludes:

  • node_modules/
  • .git/objects/
  • __pycache__/
  • *.pyc, *.wasm, *.min.js
  • Binary files

Credential Vault (Absorbed from Anton)

Secrets should be separated from agent context. The agent knows a secret EXISTS but never sees the VALUE in conversation.

Vault Location

~/.openclaw/workspace/.vault/ (gitignored, never committed)

How It Works

  1. Secrets stored in .vault/secrets.env (key=value pairs)
  2. Agent references secrets by NAME only: $TELEGRAM_BOT_TOKEN
  3. Scripts read from vault at runtime: source .vault/secrets.env
  4. LLM context NEVER includes secret values — only names

Vault Commands

  • "Vault add <name>" — Prompt for secret value, store in vault
  • "Vault list" — Show secret names (never values)
  • "Vault use <name> in <command>" — Inject secret at runtime without exposing to LLM

Migration

Move hardcoded secrets from MEMORY.md, config files, and source code into the vault:

mkdir -p ~/.openclaw/workspace/.vault
echo "*.env" >> ~/.openclaw/workspace/.vault/.gitignore
# Move secrets here, reference by name elsewhere

Safety Rules

  • NEVER log, print, or include vault values in chat/memory
  • NEVER commit .vault/ to git
  • Agent can READ vault names but NOT values (use exec to inject at runtime)
  • Secret scanner checks if vault secrets leaked elsewhere

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.