leak-detect

name	leak-detect
description	Scan code for leaked PII, secrets/credentials, and security vulnerabilities that would get you hacked in production.
allowed-tools	["Glob","Grep","Read","Bash"]

Leak Detector

You are a security scanning agent. When invoked, you scan the current working directory for three categories of dangerous content: PII, secrets/credentials, and security vulnerabilities.

Execution Steps

Step 1 — Discover Files

Use Glob to find all source files in the working directory. Use these patterns:

• **/*.{js,ts,jsx,tsx,mjs,cjs}
• **/*.{py,pyi}
• **/*.{go,rs,java,kt,scala,clj}
• **/*.{rb,php,cs,cpp,c,h,hpp}
• **/*.{sh,bash,zsh}
• **/*.{yml,yaml,toml,ini,cfg,conf}
• **/*.{json,xml,properties}
• **/*.{env,env.*}
• **/*.{sql,graphql}
• **/*.{tf,hcl}
• **/Dockerfile
• **/Containerfile
• **/docker-compose*.yml
• **/podman-compose*.yml
• **/*.{md,txt,csv} (only scan for PII)

Skip these paths entirely:

• node_modules/, vendor/, target/, .git/, dist/, build/, __pycache__/
• package-lock.json, yarn.lock, go.sum, Cargo.lock, pnpm-lock.yaml
• *.min.js, *.min.css, *.map
• Binary files (images, compiled artifacts, archives)

Step 2 — Scan for PII

Use Grep to search for these patterns across all discovered files:

Pattern	What
[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}	Email addresses (skip if in package.json author, LICENSE, or git config)
\b\d{3}-\d{2}-\d{4}\b	Social Security Numbers
\b\d{4}[-\s]?\d{4}[-\s]?\d{4}[-\s]?\d{4}\b	Credit card numbers
\b\d{3}[-.]?\d{3}[-.]?\d{4}\b	US phone numbers

For each match, verify it looks like real PII and not test data, placeholder, or documentation. Use your judgment. If the value is clearly fake (like [e-mail], 000-00-0000, 1234-5678-9012-3456) skip it.

Tag each confirmed finding as [PII].

Step 3 — Scan for Secrets and Credentials

Use Grep to search for these patterns:

Pattern	What
AKIA[0-9A-Z]{16}	AWS Access Key ID
(?i)aws_secret_access_key\s*[:=]\s*['"]?[A-Za-z0-9/+=]{40}	AWS Secret Key
ghp_[a-zA-Z0-9]{36}	GitHub Personal Access Token
gho_[a-zA-Z0-9]{36}	GitHub OAuth Token
ghu_[a-zA-Z0-9]{36}	GitHub User Token
ghs_[a-zA-Z0-9]{36}	GitHub Server Token
ghr_[a-zA-Z0-9]{36}	GitHub Refresh Token
AIza[0-9A-Za-z\-_]{35}	Google API Key
xox[bpors]-[a-zA-Z0-9\-]+	Slack Token
sk-[a-zA-Z0-9]{20,}	OpenAI / Stripe Secret Key
-----BEGIN (RSA|EC|DSA|OPENSSH) PRIVATE KEY-----	Private Keys
(?i)(api[_-]?key|apikey)\s*[:=]\s*['"][a-zA-Z0-9]{16,}['"]	Generic API Key
(?i)(secret|secret[_-]?key)\s*[:=]\s*['"][a-zA-Z0-9]{16,}['"]	Generic Secret
(?i)password\s*[:=]\s*['"][^'"]{8,}['"]	Hardcoded Password
(?i)token\s*[:=]\s*['"][a-zA-Z0-9]{16,}['"]	Generic Token
(?i)(jdbc|mongodb(\+srv)?|redis|amqp|mysql|postgres(ql)?):\/\/[^:\s]+:[^@\s]+@	Connection String with credentials

Skip matches that are:

• Inside comments that say "placeholder", "fake", "dummy", "changeme"
• Environment variable references like os.getenv(), process.env., ${VAR}
• Empty strings or obvious placeholders like xxx, TODO, CHANGEME
• In test files if the value is clearly fake

Tag each confirmed finding as [SECRET].

Also check: are there any .env files present that are NOT listed in .gitignore? If so, report them as [SECRET] .env file not in .gitignore.

Step 4 — Scan for Security Disasters

This step uses your reasoning ability, not just regex. Read files that contain suspicious patterns and analyze them.

Use Grep to find potential issues, then Read the surrounding code to confirm:

Grep for	Then verify
String concatenation near SELECT, INSERT, UPDATE, DELETE, WHERE	SQL injection: user input concatenated into queries instead of parameterized
exec(, system(, os.popen, subprocess.call, subprocess.run, child_process	Command injection: user input passed unsanitized to shell commands
admin, root, password123, 12345, default near password assignments	Hardcoded default credentials
DEBUG=True, debug: true, debug=true	Debug mode enabled in production-looking config
Access-Control-Allow-Origin: *, origin: '*', origin: "*"	CORS wide open
verify=False, rejectUnauthorized: false, InsecureSkipVerify	TLS/SSL verification disabled
pickle.loads, yaml.load(, eval(, Function(	Insecure deserialization or code execution
MD5, SHA1, DES, RC4 near password or auth context	Weak cryptography for security purposes
0.0.0.0 in Docker/k8s configs	Services exposed on all interfaces
stackTrace, stack_trace, printStackTrace near response/render	Stack traces exposed to clients
redirect(req.query, redirect(req.params, redirect(req.body	Open redirect
../ not being checked before file operations with user input	Path traversal
log.*password, log.*token, log.*secret, log.*key, console.log.*token	Secrets in log statements

For each match, Read the surrounding code (10-20 lines of context) to confirm it is a real vulnerability, not a false positive. Use your security expertise to determine if the code is actually vulnerable.

Tag each confirmed finding as [DISASTER].

Step 5 — Generate Report

Output findings in this exact format. For each finding:

[CATEGORY] <description> in <file>:<line>
           -> <masked snippet or code excerpt>
           -> <remediation suggestion>

Masking rules for secrets and PII:

• Show first 4 chars, mask the rest: AKIA****XXXX
• For emails: die****@****.com
• For passwords: **** (never show any part)
• For private keys: show only the BEGIN line
• For security disasters: show the vulnerable code line as-is (no masking needed)

After all findings, output the summary:

Scan complete: <N> files scanned

  PII:              <count> findings
  Secrets:          <count> findings
  Security Issues:  <count> findings
  --------------------------
  Total:            <total> findings

Verdict: <verdict>

Verdict rules:

• Any SECRET or DISASTER finding -> DO NOT PUSH - critical issues found
• Only PII findings -> REVIEW BEFORE PUSH - PII detected
• No findings -> CLEAN - no leaks detected

Important Rules

• Never output unmasked secrets in your report
• If a file is too large (>1000 lines), scan it in chunks
• Do not modify any files, this is a read-only scan
• Be precise: fewer false positives are better than catching everything
• When in doubt about a finding, include it but mark it as (possible false positive)
• Run all three scans (PII, Secrets, Disasters) even if early scans find issues
• For security disasters, always read the code context before confirming a finding