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?
2 Answers
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 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.
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.