security-review
Skill2 starsChanged 3 months agoMITView on GitHub
Run a phased security audit of Claude or OpenAI configuration and a target project (Google Gemini surfaces: scoping and a not-covered report only). Use when the user asks to: review security, audit Claude Code setup, check for exposed credentials, set up security hooks, harden their Claude environment, scan a project for secrets, or anything like "check if my setup is secure", "audit my Claude config", "set up security hooks", "scan for credentials". Accepts an optional project path argument (e.g. `/security-review /path/to/project`) to scope project-level checks; defaults to the current working directory if omitted.
- Reads credentials
192 other projects use a version of this.
Adopted by
Most recently taken up by
- AOSSIE-Org/Resonate-Websitetheir own version, first seen Nov 9, 2026
- dimastriann/odoo-erp-mcptheir own version, first seen Nov 8, 2026
- ksprashu/agent-skill-forgetheir own version, first seen Nov 8, 2026
- enes-alatas/spooltheir own version, first seen Nov 8, 2026
- sgaabdu4/appwrite-backendtheir own version, first seen Nov 8, 2026
- AndersonAndrad/skillstheir own version, first seen Nov 8, 2026
Used with
Projects with it also use linkerd-patterns, dependency-cve-sweep and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
xfstudioSkilllinkerd-patterns
Implement Linkerd service mesh patterns for lightweight, security-focused service mesh deployments. Use when setting up Linkerd, configuring traffic policies, or implementing zero-trust networking with minimal overhead.
Also in 5 projects that use this
berntpoppSkilldependency-cve-sweep
Use when handling Dependabot PRs, CodeQL/Trivy alerts, or doing a routine dependency/CVE sweep for this repo.
Also in 12 projects that use this
berntpoppSkillfleet-standard-adoption
Use when bringing this repo into compliance with a GeneFoundry fleet standard (tool-naming, response-envelope, container-hardening, versioning, MCP transport, or logging) or closing its tracking issue.
Also in 12 projects that use this
HABUBUSSSkillproject-guidelines-example
Also in 16 projects that use this
niloykumarbarmanSkillagent-sort
Build an evidence-backed ECC install plan for a specific repo by sorting skills, commands, rules, hooks, and extras into DAILY vs LIBRARY buckets using parallel repo-aware review passes. Use when ECC should be trimmed to what a project actually needs instead of loading the full bundle.
Also in 13 projects that use this
royaluniondesign-sysSkillconfigure-ecc
Interactive installer for Everything Claude Code — guides users through selecting and installing skills and rules to user-level or project-level directories, verifies paths, and optionally optimizes installed files.
Also in 11 projects that use this
- +2 more from berntpopp
Other versions192 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 192
- affaan-m/ECC★ 246ksame name
- github/awesome-copilot★ 41ksame name
- langfuse/langfuse★ 37ksame name
- nearai/ironclaw★ 13ksame name
- joe-bell/cva★ 6.9ksame name
- doorkeeper-gem/doorkeeper★ 5.5ksame name
- github/squad★ 3.4ksame name
- compozy/compozy★ 2.9ksame name
- getsentry/sentry-python★ 2.2ksame name
- trycompai/comp★ 2.1ksame name
182 more not listed
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.
In this repository10 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- ai-assistant-setupSkill
- cowork-optimizerSkill
- dispatchSkill
- git-guruSkill
- policies-validatorSkill
- prompt-improverSkill
- review-protocolSkill
- template-exporterSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
13 rules. 0 are common, 9 are distinctive, and 4 are very specific to this project.
0
Common
Most of the 167 edited versions we read keep these.
9
Distinctive
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 41
If the user provided a path argument (e.g.
- Distinctive: line 56
Run these three checks immediately — they catch the highest-risk issues first.
- Distinctive: line 57
Do not wait for Phase 1.
- Distinctive: line 103
If no issues found, say "Phase 0: No immediate flags found."
- Distinctive: line 109
Run all checks, then produce a consolidated risk table.
- Very specific: line 123
Read ~/.claude.json, any $PROJECT/.mcp.json, and (if present) ~/Library/Application Support/Claude/claude_desktop_config.json.
- Distinctive: line 142
Run in a subshell so the working directory does not leak into later phases:
- Distinctive: line 189
Ask before each, with the available question tool or chat, and act only on an explicit yes.
- Very specific: line 255
If $PROJECT is not a git repository: skip .env tracking check (0b) and .gitignore coverage (1f).
- Distinctive: line 256
If the user declines all APPROVAL REQUIRED phases: produce the Phase 0 + Phase 1 read-only report and the Phase 7 governance doc.
- Distinctive: line 257
If a scanning tool (Socket CLI, ClamAV, pip-audit) fails to install: log the failure, skip that specific check, and continue with remaining …
- Very specific: line 258
If ~/.claude/hooks/ already contains a security-precheck.sh: read it, compare to "$SKILL_DIR/references/hook-security-precheck.sh", and use …
- Distinctive: line 265
After all selected phases, run:
“Common” is measured: kept by at least 6 in 10 of the 167 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.
Files
Assistant Security Review
First identify the surface. For Codex or ChatGPT, read references/openai-review.md, execute that route, and stop: the Claude phases below do not apply. For Google surfaces (Antigravity, Jules, the Gemini app) this skill has no route yet: record the scope as in step 1 of the OpenAI route, list Antigravity's permission rules and hooks.json as unaudited, and say plainly that no Google controls were checked. Do not run the Claude phases or install the Claude hooks there. For a multi-platform audit, assess each surface independently and combine the findings without treating any control set as portable.
For Claude Code, conduct the structured review below. Its bundled shell hooks and configuration examples are Claude-specific.
Which machine are you auditing? Every check below reads the home directory of the shell it runs in. A session that runs in the cloud (Cowork or claude.ai cloud sessions, Claude Code on the web) has a home directory of its own, and whatever ~/.claude.json or ~/.claude/ it holds is the container's, not the user's configuration. Do not decide where you are from what those files contain. Before Phase 0, establish where the target configuration lives:
- The shell is on the target machine (Claude Code in a local terminal, or a desktop session running locally): proceed.
- The session reaches the computer through a device bridge (a tool such as
device_bash): run every check through that tool, set$PROJECTto a path on that computer (a connected folder), and treat$SKILL_DIRas a container path the bridge cannot see. For the install phases, put each hook file onto the computer with the bridge's file-copy tool (such asdevice_commit_files) first, then run the install commands there against that copy. A file you cannot read through the bridge is unverified, not absent: never conclude "not configured" from a partial stage. - No route to the computer: stop before Phase 0 and say that the user's machine was not audited. Offer only what can run: the project checks (0b, 1f) on a git repository cloned into this session, or the content checks of 1f on files the user attaches (0b and the
.gitignorecheck need a git repository). Never report a cloud container's configuration as theirs.
Name the machine that was audited in the first row of the Phase 1 table and in the Phase 7 report. Work through phases sequentially. Read-only phases run automatically. Mutating phases (marked APPROVAL REQUIRED) must pause and ask the user before creating any files, installing software, or modifying configuration.
At the end of each phase, print a summary and use the current surface’s question tool (or chat if unavailable): Proceed to Phase N+1 / Skip / Stop
Clarifying questions: For any step with a fixed set of options, use the current surface’s question tool when available, otherwise ask a concise question in chat.
OS scope: The commands in this skill are macOS-first (
sw_vers, Homebrew paths). On Linux, adapt package installs (e.g. apt/dnf instead of brew) and paths; Phases 1a and 4 are macOS-specific as written.
Setup
Determine the target project path:
- If the user provided a path argument (e.g.
/security-review /path/to/project), use that path - Otherwise, use the current working directory
Store this as $PROJECT for use throughout.
Also store $SKILL_DIR — the directory containing this SKILL.md. Every references/… path in
this skill and in references/phases-2-5-install.md must be written as "$SKILL_DIR/references/…".
Phase 1f changes the working directory to $PROJECT, so a bare references/… afterwards resolves
against the target project, where it either finds nothing or — worse for the drift check in Phase
5b — silently compares against the wrong file.
Phase 0: Immediate Flags (read-only)
Run these three checks immediately — they catch the highest-risk issues first. Do not wait for Phase 1.
0a. Plaintext credentials in MCP configs
MCP servers live in ~/.claude.json and .mcp.json (Claude Code) or claude_desktop_config.json (Cowork/Desktop) — not settings.json. Scan all that exist:
python3 -c "
import json, os
home = os.path.expanduser('~')
configs = [
home + '/.claude.json',
os.environ.get('PROJECT', '.') + '/.mcp.json',
home + '/Library/Application Support/Claude/claude_desktop_config.json',
]
def scan(d, src):
for name, srv in d.get('mcpServers', {}).items():
for k in srv.get('env', {}):
if any(kw in k.upper() for kw in ['PASSWORD','SECRET','TOKEN','KEY','CREDENTIAL']):
print(f' HIGH: MCP server [{name}] has plaintext {k} in {src}')
for path in configs:
try:
d = json.load(open(path))
scan(d, os.path.basename(path))
for proj in d.get('projects', {}).values(): # ~/.claude.json nests per-project servers
scan(proj, os.path.basename(path))
except Exception: pass
"0b. Sensitive files tracked by git in $PROJECT
cd "$PROJECT" && git ls-files 2>/dev/null | grep -iE '\.env|secret|credential|key|token'Any result is HIGH risk — .env and credential files should never be committed. (Review matches: some may be false positives, e.g. keyboard.js.)
0c. Shell history credential patterns
grep -E "(PASSWORD|SECRET|API_KEY|TOKEN)\s*=" ~/.zsh_history ~/.bash_history 2>/dev/null | head -5Print findings as a table:
| Location | Finding | Risk |
|-----------------------|--------------------------------------|--------|
| ~/.claude.json | Plaintext PASSWORD for [server name] | HIGH |If no issues found, say "Phase 0: No immediate flags found."
Phase 1: Full Posture Assessment (read-only)
Run all checks, then produce a consolidated risk table.
1a. OS and privilege
sw_vers && whoami && groups $(whoami) | grep -q admin && echo "IS ADMIN" || echo "not admin"1b. Running Claude Code processes
ps aux | grep -i "claude" | grep -v grepFlag any process with 0% CPU running >2h as a zombie.
1c. MCP server inventory
Read ~/.claude.json, any $PROJECT/.mcp.json, and (if present) ~/Library/Application Support/Claude/claude_desktop_config.json. For each server, note:
- Transport type (stdio vs HTTP)
- Whether env block contains secrets (flag if so)
- Whether version is pinned
1d. Current hooks
ls ~/.claude/hooks/ 2>/dev/null && cat ~/.claude/hooks/*.sh 2>/dev/null || echo "No hooks configured"Note which of PreToolUse / PostToolUse hooks are missing.
1e. Permission mode
cat ~/.claude/settings.local.json 2>/dev/null || echo "No settings.local.json"Check for permissions.defaultMode set to "bypassPermissions", or stale permission entries. "auto" is the built-in starting mode for interactive sessions when none is configured (every plan and provider on current Claude Code) and is not a finding; "dontAsk" in a settings file that is not a CI or unattended setup is worth asking the user about.
1f. Project-specific checks (if $PROJECT is set)
Run in a subshell so the working directory does not leak into later phases:
( cd "$PROJECT"
find . -name '.env*' -not -path './.git/*' | head -20
grep -rn --include="*.js" --include="*.ts" --include="*.py" --include="*.sh" \
-E "(API_KEY|SECRET|PASSWORD|TOKEN)\s*=\s*['\"][^'\"]{8,}" . \
--exclude-dir=node_modules --exclude-dir=.git 2>/dev/null | head -20
cat .gitignore 2>/dev/null | grep -E "\.env|secret|credential" || echo ".gitignore: no secret patterns found" )1g. Shell snapshots
ls -la ~/.claude/shell-snapshots/ 2>/dev/null | wc -l && \
du -sh ~/.claude/shell-snapshots/ 2>/dev/nullReport count and size; flag if >100 snapshots.
Print consolidated risk table:
| Area | Finding | Risk |
|-----------------------|--------------------------------------------|--------|
| Machine audited | [hostname] — local shell / device bridge | — |
| ~/.claude.json | Plaintext PASSWORD ([server-name] MCP) | HIGH |
| PreToolUse hook | Not configured — no execution guard | MEDIUM |
| Shell snapshots | 47 snapshots, 230MB | LOW |
| MCP transport | stdio only — no network exposure | LOW |Phases 2-5: the mutating phases (APPROVAL REQUIRED)
These four install software, write hook files, or modify ~/.claude/settings.json. Their
procedures live in references/phases-2-5-install.md — read it when the user opts into one,
not before. A user who declines all four still gets a complete audit from Phases 0, 1, 6 and 7,
so do not treat declining as a failed run.
| Phase | What it does | Reads/writes |
| 2 | PreToolUse execution guard — installs security-precheck.sh and merges it into settings.json | ~/.claude/hooks/, ~/.claude/settings.json |
| 3 | Supply chain — Socket CLI and pip-audit, plus an npm-install check appended to the Phase 2 hook | global npm/pipx, the Phase 2 hook |
| 4 | File-level malware scanning — ClamAV and a PostToolUse scan hook | Homebrew, ~/.claude/hooks/, ~/.claude/settings.json |
| 5 | Credential hygiene in transcripts (5a, read-only scan) and the session cleanup script (5b) | ~/.claude/projects/ (read), ~/.claude/hooks/ |
Phase numbers are a cited surface. 12_SECURITY.md points readers at Phases 0b, 2, 3, 5 and 6
by number. Moving a phase into a reference file is fine; renumbering one is not.
Ask before each, with the available question tool or chat, and act only on an explicit yes.
Phase 6: MCP Server Audit (read-only)
For each MCP server in ~/.claude.json, $PROJECT/.mcp.json, and (if present) claude_desktop_config.json, assess and report:
| Field | What to check |
| Transport | stdio (local) = LOW risk; HTTP = MEDIUM/HIGH depending on auth |
| Source | Official/known = LOW; unknown GitHub = HIGH |
| Version pinning | Pinned = LOW; latest or no pin = MEDIUM |
| Secrets in env | Any plaintext secret = HIGH |
| Network exposure | Accessible over network? Rate as HIGH |
Print a per-server risk card:
### MCP: [server-name]
- Transport: stdio (local process)
- Source: local file (/Users/.../dist/index.js)
- Version pinning: not applicable (local build)
- Secrets in env: YES — [SERVER]_PASSWORD in plaintext → HIGH RISK
- Recommendation: Move credential to system keychain or password manager CLI, and launch the
server via a wrapper script that exports it, e.g.
`MY_TOKEN="$(op read 'op://vault/[server-name]/password')" exec npx ...`
(Note: `$(...)` inside the JSON env block is NOT expanded — the literal text becomes the value.)Phase 7: Governance & Documentation (read-only — outputs a report)
Generate a security documentation file at $PROJECT/SECURITY_AUDIT.md (or ~/CLAUDE_SECURITY_AUDIT.md if no project):
# Claude Code Security Audit
Generated: [date]
Machine audited: [hostname — local shell / via device bridge]
## Attack Surface
| Area | Risk | Notes |
|------|------|-------|
| MCP server credentials | HIGH | Plaintext secrets in MCP config files |
| PreToolUse hook | [ACTIVE/MISSING] | Execution guard status |
| PostToolUse scan | [ACTIVE/MISSING] | Malware scan status |
| Shell snapshots | LOW | Auto-pruned at 7 days (verify current behavior) |
| Session transcripts | MEDIUM | Manual review recommended |
## Maintenance Schedule
| Task | Frequency | Method |
|------|-----------|--------|
| ClamAV signature update | Daily | freshclam (auto via launchd) |
| Shell snapshot prune | Per session | session-cleanup.sh hook |
| Transcript credential scan | Quarterly | Manual run of Phase 5a |
| MCP server review | When adding new server | Run Phase 6 |
| Full re-audit | Quarterly | Re-run /security-review |Edge Cases
- If
~/.claude/settings.jsondoes not exist: first confirm you are on the target machine and could read the file (see "Which machine are you auditing?"); a container's home directory or a partial stage proves nothing. Then skip the hook checks and note "No global settings file found — Claude Code may not be configured yet." (Credential checks in 0a use the MCP config files, not settings.json.) - If
$PROJECTis not a git repository: skip.envtracking check (0b) and.gitignorecoverage (1f); note "Not a git repo — git-based checks skipped." - If the user declines all APPROVAL REQUIRED phases: produce the Phase 0 + Phase 1 read-only report and the Phase 7 governance doc. Do not treat declining as an error.
- If a scanning tool (Socket CLI, ClamAV, pip-audit) fails to install: log the failure, skip that specific check, and continue with remaining phases. Do not abort the entire audit.
- If
~/.claude/hooks/already contains asecurity-precheck.sh: read it, compare to"$SKILL_DIR/references/hook-security-precheck.sh", and use the current surface’s question tool (or chat if unavailable): "An existing hook is already installed."Buttons:
Replace with updated version/Keep current/Show diff
Final Verification
After all selected phases, run:
ls -la ~/.claude/hooks/*.sh 2>/dev/null || echo "No hooks installed"
python3 -c "
import json, pathlib
p = pathlib.Path.home() / '.claude' / 'settings.json'
hooks = json.loads(p.read_text()).get('hooks', {}) if p.exists() else {}
print('PreToolUse:', 'configured' if 'PreToolUse' in hooks else 'MISSING')
print('PostToolUse:', 'configured' if 'PostToolUse' in hooks else 'MISSING')
"Print a final summary: which phases ran, which were skipped, top 3 remaining risks to address.
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
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.

