I built a small open-source scanner for API-key mistakes in vibe-coded projects

A developer built Wardrail, an open-source scanner that checks for API-key leaks and security risks in vibe-coded projects. The tool scans Git history, MCP configuration, and Agent instruction files for exposed secrets and risky patterns, running locally without uploading code.

I started this project because vibe coding makes it possible to get an app working before a beginner has learned how secrets, frontend bundles, or Git history behave. A value being in .env does not always mean it stays private. Variables such as VITE , NEXT PUBLIC , and REACT APP can reach browser code. And if an API key was committed, deleting it from the current file does not remove it from Git history. So I built Wardrail , a small open-source safety check: npx wardrail scan --history It scans the current project and a bounded part of Git history. It also checks MCP configuration and Agent instruction files for risky commands, credential access, and safety-bypass patterns. Wardrail runs locally by default. It does not upload source code and does not execute the project being scanned. wardrail@0.3.0 AI coding tools can help someone ship a useful application very quickly. But speed can hide security assumptions: .env is treated as automatically privateWardrail is meant to be an early warning before a push or release. It explains the matched evidence and suggests a fix instead of returning only a risk score. This is still an early project, and I do not have external users to point to yet. It can produce false positives and miss risks. It is not a penetration test, and a clean report does not mean an application is secure. It does not currently test authentication, authorization, database policies, dependency vulnerabilities, deployment settings, or runtime behavior. Gitleaks and TruffleHog are still mature choices for broader secret discovery. Repository and CLI demo: https://github.com/3196973848/wardrail https://github.com/3196973848/wardrail The feedback that would help most is: Please share only a rule ID and a redacted example—never post a live credential. If a real key may have been exposed, revoke or rotate it first. Even a short report about what failed is more useful to me than a polite "looks cool."