Cybersecurity

A local-only MCP server that audits your own project for the security mistakes AI-generated apps ship with, before you deploy. It runs on your machine over stdio, reads the local path you point it at, and never probes remote targets. That makes it a pre-deploy safety net, not a recon tool.

Trust note: this tool is designed to be pointed at your most sensitive code. It runs entirely locally, sends no telemetry, and the only network call it makes is to OSV.dev, and only to look up your dependencies' published CVEs by name and version. See SECURITY.md for details. The source is open so you can verify all of that.

Why this in addition to /security-review?

Claude Code ships /security-review and it's good, for people who already speak security. security-audit is built for the other audience: people shipping AI-generated apps who don't know what RLS, CSRF, or a service-role key are, and whose agent needs to fix the issue without a human translator.

	/security-review	security-audit
Audience	Devs comfortable with security	Non-technical people shipping AI apps
How it judges	LLM read of the diff	Deterministic rules + the OSV CVE database
False-positive rate	Variable (LLM noise)	Tight (curated, suppressible by fingerprint)
Tells you the same thing twice?	Yes (re-run = re-flag)	No, dismissals stick across edits
Dependency CVEs	No	Yes
Knows AI-build failure modes specifically	Generic	Yes: Supabase RLS, public-env leakage, etc. is the doctrine
Available where	Inside Claude Code	Any MCP-capable agent (Claude Code, Cursor, etc.)

Use both. /security-review catches the broader long tail; security-audit catches the specific failures AI-build tools ship with by default, in language the human can act on without help, with a suppression model that survives edits, and it adds dependency CVEs that /security-review doesn't do.

What it checks (v0)

#	Check	Catches
1	Exposed secrets / public-env leakage	Hardcoded API keys, and the high-value case: a secret behind NEXT_PUBLIC_ / VITE_ / PUBLIC_ that gets inlined into the browser bundle.
2	Supabase RLS + service-role	Tables with Row-Level Security disabled or never enabled, and service-role keys (decoded from JWTs) used in client-reachable code. The signature vibecoded breach.
3	Dependency CVEs	npm, pnpm, PyPI (requirements / pyproject / uv.lock / Pipfile) manifests and lockfiles checked against OSV.dev (free, no key), with fixed versions.

Every finding returns severity, confidence, a CWE id + standard references, file:line, a plain-language reason, a concrete fix, an optional "this might be intentional" note, and a stable fingerprint, written for a non-technical user and structured so an agent can remediate in the same loop.

By default the scan returns critical/high findings in full and collapses medium/low to a count. Pass detail=true (CLI: --all) to see everything.

Tools

• audit_project(path, detail=False): run all three checks (the orchestrator).
• scan_secrets(path, detail=False): secrets / public-env leakage only.
• scan_dependencies(path, detail=False): OSV dependency check only.
• check_supabase(path, detail=False): Supabase RLS / service-role only.
• suppress_finding(path, fingerprint, reason=""): dismiss a reviewed finding.
• list_suppressions(path): show what's currently dismissed.
• install_pre_deploy_guard(path) / uninstall_pre_deploy_guard(path): see below.

Get it into the agent's hands, not yours (pre-deploy guard)

The hardest part of any security tool is remembering to run it. So don't. Run this once per project:

uv run security-audit setup            # writes the guard to ./CLAUDE.md
uv run security-audit setup --uninstall  # removes only our managed block

It appends a short directive to your project's CLAUDE.md that tells the agent, any agent that reads CLAUDE.md (Claude Code, Cursor, etc.), to call audit_project before any deploy-intent command (git push to main, vercel deploy, npm run deploy, supabase db push, etc.) and to stop on any critical/high finding rather than letting the deploy proceed. Idempotent; delimited so uninstall is exact. The agent does the work; you don't have to remember.

Dismissing findings (suppression)

If a finding is intentional, dismiss it by its fingerprint (the id shown on each finding). That writes the fingerprint to a committed .security-ignore file at the project root, so the dismissal is shared with your team and survives edits elsewhere in the file (it's keyed on a content fingerprint, not a line number). Commit that file. Don't add it to .gitignore.

Quick start

uv sync

# One-shot CLI against the bundled vulnerable demo:
uv run security-audit scan examples/vulnerable-app

Register with Claude Code

claude mcp add security-audit -- uv run --directory "C:/Users/colli/Cybersecurity MCP" security-audit

Then ask Claude: "audit this project with security-audit before I deploy."

The demo

Point it at the bundled examples/vulnerable-app (or any AI-generated repo you have locally) and watch it surface, in seconds: a service-role key shipped to the browser, a public Supabase table with RLS off, and vulnerable dependencies. The bundled .env.local also includes an anon key as a negative control, and security-audit leaves it alone, because the anon key is public by design.

For contributors: examples/vulnerable-app/ is a fixture and is deliberately insecure. Don't "fix" it. The demo and tests depend on it. Its "secrets" are public Supabase demo keys and obviously-fake Stripe values, not real credentials.

Scope & ethics

security-audit audits the local project you point it at. It does not scan, probe, or send requests to third-party targets. The only network call it makes is to OSV.dev to look up published CVEs for your declared dependencies.