STRIPE_SECRET_KEY=sk_live_... in a .env.production that .gitignore does not cover goes into the repository with the next git add ., and a Hugging Face or OpenAI key pasted into a training script ends up in every fork and backup. This skill finds those and the other ways secrets get written into files, and tells you how to fix each one.

Your agent runs a scanner on every text file in the project (code, .env files, YAML, JSON, notebooks, docs and key files). It matches each provider's published format (prefix, length and characters), checks that a -----BEGIN PRIVATE KEY----- line is followed by real key data, reads database URLs and connection strings, and looks at settings whose names say they hold a secret. It skips plain placeholders (your_key_here, xxxx, ${VAR}, the AWS documentation key), lines marked fake in test files, and heuristic rules in docs, lock files and minified bundles, and it honors gitleaks:allow and pragma: allowlist secret. It then reads your .gitignore files: secrets in files git ignores stay out of the verdict and are counted in one closing line, and a secrets file git would commit is reported. It never calls a provider and never prints a secret. It returns BLOCK, REVIEW, or NOT FLAGGED, with the file, line, reason, and a safer approach.

What it checks

BLOCK (fix before shipping)

• H01: AWS access keys and secret keys (also in access-key CSVs and aws configure), Google API keys in server code (Gemini), Google OAuth client secrets, Azure Storage account keys, Supabase secret and service_role keys

• H02: GitHub, GitLab, npm (including .npmrc _authToken) and PyPI tokens

• H03: OpenAI, Anthropic, OpenRouter and Hugging Face keys

• H04: Stripe live keys and webhook secrets, Slack, Discord and Telegram bot tokens and webhooks, Twilio Auth Tokens, SendGrid keys

• H05: private keys (PEM, OpenSSH, PGP, PuTTY, age) that contain key data

• H06: passwords in database URLs and connection strings to remote hosts

REVIEW (check before release)

• H11: Stripe test keys and TestPyPI tokens

• H12: secret-named settings with random-looking values (including Laravel APP_KEY and similar *_KEY values), literal Authorization headers, passwords for container hosts

• H13: JWTs (Supabase anon keys and the jwt.io sample are skipped)

• H14: .env, .npmrc, *.pem and similar files with a secret that no .gitignore rule covers

• H15: Google API keys in Firebase, Android, iOS or Maps client configs that need API and app restrictions

What's included

• The scanner (Python 3.9+, standard library only)

• A rules guide with the reason, the key formats and the safer approach for each rule

• A risky and a safe example project (Django, Express, Firebase, npm and deploy files), and the real report the scanner produces on the risky one

Limits

It reads the files as they are now: git history, other branches and CI logs are not searched, and it cannot tell whether a key still works. Ignore status comes from .gitignore files only, and files with more than 50 hits for one rule list the first 50. Binary key stores (.p12, .jks), short or word-like passwords, secrets split across lines and providers not listed above are not reported. NOT FLAGGED is not a guarantee.

Contents

One ZIP file with 25 files: SKILL.md, the scanner in scripts/ (4 Python files), references/rules.md (every rule with its reason and safer approach), and examples/ (18 example files plus report.md, the real scanner output on the risky example).

How to use: This is an agent skill: a folder with a SKILL.md file and Python scripts that an AI coding agent such as Claude Code, Cursor, or Codex CLI can run. Unzip it into your agent's skills folder (for Claude Code: ~/.claude/skills/), then ask your agent to check your project. The scripts also run on their own with Python 3.9 or newer, with nothing to install. They read your files only: no network access, and nothing is sent anywhere.