Docs

Security guardrails

The teammate who says "don't commit that key" before you do. Plain-language checks for the classic footguns in a tracked repo's working tree, each paired with the exact fix. The checks: a .env-family file tracked by git, a key or token committed in a tracked file, the same in an untracked-not-ignored file, a server bound to 0.0.0.0, wildcard CORS, and a .env present but not in .gitignore.

Where to find it

  • Localhost: /security-guardrails.html
  • API: GET /api/security-guardrails (add ?fresh=1 to re-scan)
  • Navigation: AI Security in the sidebar, then Guardrails under All tools, in the Vulnerabilities group

What it does for you

Catches the high-frequency footguns with the fix attached.Each check runs over the repo's working tree and git path lists, and every finding carries the exact command or edit that resolves it. Two are marked critical (a .env-family file tracked by git, a secret committed in a tracked file); the rest are high or warn. The scanner is tuned so its own source and the test fixtures never self-match.
Honest about its scope.A clean result means none of these checks fired, not that the app is fully secure. The scan does not cover cloud config (public S3 buckets, IAM) and does not rewrite git history for you; the fixes point you at the right command instead.

Built vs. planned

All six checks, the plain-language fixes, and the on-demand re-scan (?fresh=1) ship today, backed by lib/security-guardrails.mjs (pure detection over already-read content) and its git plus filesystem wrapper. A non-git path degrades to an honest error rather than throwing. Results are cached per repo, the same pattern as the file-integrity scan.

Last updated