I Posted My AI Code Security Gate on r/devops. The Pushback Taught Me More Than the Build Did.

I posted my AI code security gate on r/devops.

The downvotes taught me less than the two comments underneath them did.

Here's how it started. I caught a live Stripe key about to get committed. stripe.api_key = "sk_live_...", sitting in a file an AI coding agent had just written while I was testing a billing flow. Tests passed. Nobody looked twice, because a passing test doesn't tell you a key is live.

A few days later, same root cause, different shape. A raw SQL query built from an f-string, user input going straight into the WHERE clause. Also worked. Also would have shipped.

My first fix was the obvious one. I told the model, in the system prompt, to watch for secrets and parameterize queries.

It worked. For exactly one session.

New chat the next day, same shortcuts came right back. The model has no memory of the lecture I gave it yesterday. A prompt-level fix never compounds. It resets every time.

So I built something that doesn't reset: a gate that runs on every diff before commit, not a scan that happens later in CI once the code is already out of my head. Five passes. Secret scan first, then a control-flow read for injection patterns, a regex check for ReDoS, a drop-in patch instead of just a line number, and a flat pass or fail at the end. That gate eventually turned into the Codebase Security & Vulnerability Auditor, the version I actually use now.

I posted it to r/devops. No links, no pitch, just the two incidents and the five phases.

The post sank to zero. One reply was a single word.

"Slop."

That one stung a little. Not going to pretend otherwise.

But two other replies were worth more than any upvote would have been.

One commenter pointed out the five phases don't cover half of OWASP Top 10, and they'd rather run Snyk or Sonarqube. Fair. I'd never claimed full coverage, that was explicit in the post. This isn't a SAST replacement, it's the five seconds of friction that didn't exist before. If you're already running a real scanner in CI, this sits earlier in the pipeline, not instead of it.

The sharper one came from another commenter.

He asked the question I should have answered up front. How does a live key even get into a position to be committed? Why isn't it injected at runtime through a secrets manager?

Then he pushed further. Agents reading .env files at all is a design mistake. Dev keys should be restricted, not full production secrets. And anything that touched an AI's context should be treated as compromised and rotated, whether or not it ever left the machine.

I answered him straight instead of getting defensive. .env was never committed, gitignored from day one. The actual leak path was the value getting typed inline into a test script the agent was assembling, while it had file access to the working directory for a completely unrelated task.

He came back with the fix I hadn't fully internalized. Restricted keys over live ones. Rotate anything that touched an agent's context. Don't let agents anywhere near .env in the first place.

I told him his answer was better than mine.

Because it was.

The gate I built catches the symptom fast. His answer closes the actual door.

The tool still does what it was built to do. But the boundary I'd drawn was one layer too late, and I only found that out because someone on Reddit was willing to argue with a post that already had zero upvotes.

Ever built something, put it out there, and had the pushback teach you more than the building did?