An AI coding assistant can produce code that works while still introducing serious security problems. I recently caught a live Stripe key about to be committed and later found a raw SQL query that inserted user input directly into an f-string. Both examples passed normal testing because functionality wasn't the issue.
My first attempt was to add reminders about secrets, injection, and secure coding to the assistant's instructions. That helped for one session, but the next conversation repeated the same shortcuts. Prompt-level guidance doesn't compound because the model doesn't retain the warning.
What worked better was adding a pre-commit gate that examines every diff before it gets committed. It runs five checks in order:
1. Scan for high-entropy secrets and known Stripe, OpenAI, AWS, GitHub, and .env value patterns.
2. Trace user-controlled data through the code for SQL injection, command injection, BOLA/IDOR, and similar issues instead of relying only on regexes.
3. Check for regex patterns vulnerable to catastrophic backtracking and ReDoS.
4. Generate a drop-in fix rather than only reporting a line number.
5. Return a simple pass, warn, or fail verdict.
This isn't intended to replace SAST tools, CI scanning, or security reviews. It simply adds a few seconds of friction before code leaves the developer's machine. The challenge is keeping the checks current as new providers, token formats, and attack patterns appear. How are others maintaining gates like this without letting them quietly become outdated?
3 Answers
This is useful as an early guardrail, but it shouldn't be presented as broad OWASP coverage. Tools such as Snyk, Aikido, or SonarQube can provide deeper analysis in CI. A lightweight pre-commit check makes sense alongside those tools, especially for hardcoded secrets, obvious injection paths, and common ReDoS patterns.
The maintenance loop should be treated like a small security product: keep provider-specific detectors in versioned rules, add regression tests whenever a new token format is reported, refresh the rule set on a schedule, and track false positives. Generic entropy checks are helpful, but they need allowlists and contextual checks so they don't become noisy enough for people to bypass.
A shared test corpus would help too. Include real-looking but non-sensitive examples for each provider, plus intentionally tricky cases such as encoded values, multiline credentials, and renamed environment variables. That makes updates measurable instead of relying on whether the scanner merely feels current.
A secrets manager protects deployed applications, but it doesn't solve the local-development problem. If a decrypted value is present in a .env file that a developer or coding agent can read, it can still be copied into source code. Scanning the diff is a useful backstop, though it should be combined with secret-manager practices, least-privilege credentials, and key rotation.
That's the gap I ran into. The deployed app uses managed secrets, but the local environment still had a readable value so the application could run. The pre-commit check is meant to catch that exposure, not replace proper secret storage or access controls.
Exactly—that's the distinction I was aiming for. The gate isn't a replacement for a full security pipeline; it catches a small, high-value set of issues before the diff leaves the developer's machine. It also runs independently of the coding model, so the model can't simply ignore an instruction or approve its own output.