One-prompt security audit: 47 checks, no paid tools

TL;DR

• Point a coding agent at one Markdown file and it audits a repository — no paid tools, no accounts, no frameworks.
• The catalog is 47 vulnerability checks in four groups: injection, auth and session, crypto and infrastructure, logic and integrity.
• Every phase writes its state into audit-workspace/, so an interrupted audit is resumable and auditable.
• The agent presents findings and waits for your decision; fixes are applied only after approval and committed one by one so any of them can be reverted.

What it is and who it is for

One Prompt Security Audit is a prompt system, not a scanner binary. The README describes it as a way to turn any coding agent — Claude Code, Codex, Cursor and the rest — into a security auditor for your codebase, using only what the agent already has: file reading, grep and git.

It is for the person who wants a first real security pass on a repository without buying a tool or wiring a framework, and for anyone who already pays for an agent subscription and would rather use it. It is a first audit, not a penetration test: nothing in the README claims it replaces a human security review of a production system.

What it does

The catalog is the substance. The README groups 47 checks into four scan groups:

Each check combines a grep-style search with semantic verification, which is why an agent rather than a regex list does the work: the grep finds candidates, the agent decides whether the candidate is a real defect. The full catalog with detection guidance lives in VULNERABILITY_CATALOG.md.

Before the scan groups run, preflight covers git hygiene: .env exposure, secrets committed to history, and repository visibility. That last one matters because a private-looking repo that is actually public is itself the finding.

The orchestrated flow

The entry point is ORCHESTRATOR_PROMPT.md, and it runs five stages:

1. Phase 0 — preflight: git hygiene, .env exposure, secrets in history, repo visibility.
2. Phase 1 — ingestion: the agent maps the codebase and writes a manifest.
3. Phase 2 — scan groups A/B/C/D: parallel when the agent can spawn sub-agents, sequential otherwise.
4. Phase 3 — merge and report: findings presented in plain language, then a stop for your decisions.
5. Phase 4 — apply approved fixes: only the approved ones, committed individually to git.

The README's diagram makes the decision gate explicit: the flow branches on user decision, and the "no fixes" branch ends the audit without touching code. Every phase writes its output into audit-workspace/ — progress.json, repo-manifest.json, findings/GROUP-*.json, output/report.md — which is what makes the run resumable.

How to use it

The shortest path is one instruction to the agent:

Read ORCHESTRATOR_PROMPT.md and audit: [repo URL or local folder path]

To let the agent clone the system itself:

Clone https://github.com/artificialguybr/one-prompt-security-audit, read its
ORCHESTRATOR_PROMPT.md, and audit: [your repo URL or local path]

Nothing else is needed: the agent reads the prompt files and knows what to do. The repository also ships SCANNING_PROMPT.md for the scanning instructions, REPORT_PROMPT.md for report generation, FIX_PROMPT.md for git-backed fix application, SYSTEM_SPEC.md as architecture reference, plus schema/ for the JSON schemas of generated files and examples/ for example outputs.

Why "no fixes without permission" is the interesting rule

Most automated security tooling mixes detection and change, which is how a scan ends up rewriting code you did not ask it to touch. Here the split is explicit: detection produces a report, and the fix phase only runs after you approve specific findings. Committing each fix individually to git means a bad fix is one git revert away rather than a bisect through a mega-commit — the same principle as making an editing change reversible.

When to use it, when not to

Use it before opening a repository to the public, before handing a codebase to a contractor, or as a periodic first pass on a project whose security was never reviewed. The preflight alone is worth the run if you have ever committed a .env.

Do not treat the output as a penetration test. The README is a prompt for code review of your own repository, and it says nothing about runtime exploitation, infrastructure configuration outside the repo, or a real attacker's patience. And do not run the fix phase blind: review the findings first, because the agent's judgment about what constitutes a defect is exactly what the approval gate is for.

Sources

1. One Prompt Security Audit — repository — architecture diagram, 47-check table, file map and the five phases quoted above.
2. README.md — quick start, coverage table, artifact list.

Project page: One Prompt Security Audit

FAQ

Does it need any paid tool or account? No. The README states no paid tools, no accounts and no frameworks: the agent uses the file reading, grep and git it already has.

How many checks does it run? 47 vulnerability checks across four groups — injection, auth and session, crypto and infrastructure, logic and integrity — plus a preflight on git hygiene and secrets.

Does the agent change code on its own? No. It presents findings and waits for your decision; fixes run only after you approve them, and each is committed individually so it can be reverted.

Can an interrupted audit be resumed? Yes. Each phase writes its state into audit-workspace/, including progress, the manifest, per-group findings and the report.