ProdGuard

v0.5.0
0 dependencies · Node ≥18
MIT

Your AI agent can write code. It should not be able to quietly turn off your paywall and deploy it.

A read-only command that scans your repo in about a second and fails the build on twelve ways an AI agent quietly breaks production — across Supabase, Firebase and Stripe.

What it actually prints

Run against the app it happened to

$ npx prodguard check ~/my-app
  ProdGuard  ·  80 files scanned  ·  ~/my-app

  🔴 CRITICAL  Paid features are unlocked for everyone  paywall-disabled

     Your paywall is hardcoded open. Every visitor gets the paid product for
     free, and your Stripe subscriptions stop meaning anything.

     src/pages/Dashboard.jsx:20
       const locked = false
       → `locked` is pinned to `false` instead of being derived from the user's
       → subscription.
     src/pages/QuoteDetail.jsx:169
       const locked = false
       → `locked` is pinned to `false` instead of being derived from the user's
       → subscription.

  Result: 2 critical

  ✗ Blocking. Fix these before shipping, or add an allow entry to .prodguardrc.json.

The complete, unedited output from the app this happened to; only the path is anonymised. Exit code 1, so CI stops.

Blocking · exit 1

An audit of this tool found that an email-verification finding it used to report here was a false positive — supabase/config.toml configures the local dev stack and ships that setting disabled in every project, so it was removed. Settings that live in a hosted dashboard rather than the repository are outside what any repo scanner can see.

What check does, locally, in under a second:

Reads source and .env files in the directory you point it at, and nothing outside it. It does not follow symlinks.
Writes nothing. The one exception is init, which writes a config file and a GitHub Action — and tells you what it wrote.
Zero network requests. No telemetry, no uploads, no account, no sign-up.
Never executes your code. It matches patterns in text; it does not import or run your app.
Zero dependencies — there is no transitive supply chain to audit.

source on GitHub · package on npm

$npx prodguard check

Not ready to point it at your own code? npx prodguard check --demo runs all twelve against a deliberately broken example app.

Getting started

If you have never run a terminal command

This takes about two minutes and installs nothing permanently.

Check you have Node. Open Terminal (on a Mac press ⌘Space, type terminal, hit enter; on Windows open PowerShell from the Start menu). Paste this and press enter:
```
node --version
```
If you see a number like v20.11.0, you're set. If it says command not found, install Node from nodejs.org — take the button on the left — then close Terminal and reopen it.
See what it does, without touching your code.
```
npx prodguard check --demo
```
It will ask Ok to proceed? (y) the first time — press enter. This runs against a broken example app that lives inside the tool. Your files are not read at all.
Point it at your own project. Type cd and a space, then drag your project folder onto the Terminal window — that pastes the path for you — and press enter. Then:
```
npx prodguard check
```
Read what comes back. Every finding names the file and the line number, like src/pages/Dashboard.jsx:20. Open that file, go to that line, and decide for yourself whether it's a real problem. A finding is a prompt to look, not a verdict. Nothing dangerous found? That means these twelve checks didn't fire — not that your app is perfect.
Optional: make it run automatically.
```
npx prodguard init
```
This writes two small files into your project. Commit them, and from then on GitHub runs the check on every pull request — including the ones your AI agent opens — and blocks the merge if something critical shows up.

Stuck on any of this? Open an issue and say where you got lost — that's useful feedback, not a bother.

Twelve checks

Only things that cost money or leak data

Every one of these is a way an AI agent has actually broken a real app. One of them exists because I nearly saved my own npm recovery codes into this repository.

Severity	What it catches
Critical	Your paid features are unlocked for everyone `paywall-disabled`
Critical	Anyone can POST a fake payment and unlock an account `stripe-webhook-unverified`
Critical	Your admin database key can reach the browser `service-role-key-exposed`
Critical	Row Level Security is off — users can read each other's rows `rls-disabled`
Critical	A live Stripe or API key is sitting in your source tree `live-secret-committed`
Critical	A recovery-codes or credentials file is sitting in the repo `credential-file-committed`
High	A table was created and RLS was never turned on for it `rls-never-enabled`
High	Accounts go live without proving they own the email `email-verification-disabled`
Critical	Login tokens are read without checking the signature `jwt-not-verified`
Critical	Firebase rules allow anyone to read or write `firebase-rules-open`
High	Any website can call your API with your users' cookies `cors-wildcard-credentials`
High	A migration drops or empties a table `destructive-migration`

Put it in front of the agent

One command wires it into CI

$ npx prodguard init

  ✓ wrote .prodguardrc.json
  ✓ wrote .github/workflows/prodguard.yml

That workflow runs on every pull request — including the ones your agent opens. Dangerous changes stop merging instead of stopping your revenue.

Want it earlier, before a commit even exists:

# .husky/pre-commit
npx prodguard check

Reports for humans

No CWE numbers

Every finding is written so that someone who can build an app can act on it. Not CWE-862: Missing Authorization — instead: “Row Level Security is off — any logged-in user can read and modify every other user's rows.”

The people breaking production with agents right now are frequently not senior engineers. A warning they can't decode is a warning they'll skip.

Honest limits

What it is not

Not a linter. It ignores style entirely and only looks for changes that cost money or leak data.
Not a dashboard. Nothing to sign up for. No data leaves your machine.
Not a guarantee. A clean run means these specific checks didn't fire — not that your app is secure.
Guides, not just findings. If a check fires and you want to understand it rather than silence it: how to tell whether an agent broke something, how to check RLS on every Supabase table, and how to confirm your Stripe webhook verifies signatures.
Deliberately narrow. Twelve patterns, tuned to stay quiet so that a green build means something. It reads text, it does not parse your program, so an unusual way of writing the same bug can still walk past it. Findings are a prompt to look, not proof of a vulnerability. Treat a finding as a prompt to look, not proof of a vulnerability — and if one is genuinely fine in your codebase, allow-list it by rule and path.