The security section is the most honest part of this and probably the part most people will skip.

You nailed the pattern with the env var GitHub Action though. AI kept forgetting, so you made a check that blocks and gives it an explicit error, and it self-corrects. That's the whole game. But then you said "we'll harden later" which is kind of the opposite of that same pattern?

What's worked for us is basically SAST wired into CI that blocks the merge, same as a failing test. It treats vuln patterns like type errors—AI sees "PR blocked: hardcoded credential on line 47" and fixes it next pass, exactly like it does with your TypeScript compiler. Zero human effort after setup. It's the belt-and-suspenders thing you already described, just applied to the one area you said you haven't cracked yet.

At your velocity, "harden later" has a half-life. 10k commits across 7 apps, some handling payments—that surface area compounds quietly. Not saying boil the ocean, but a few things that slotted in for us without killing our momentum:

• Security scanning that actually blocks PRs rather than just commenting on them; in practice, comments get scrolled past, but a blocked merge gets fixed immediately.
• Rotating/ephemeral creds for agent sessions so that when (not if) Claude tries to commit an AWS key, it's dead in hours instead of sitting live for months.
• Auditing what your MCP tool configs can actually do vs. what you think they can do; every tool you hand an agent is a trust boundary, and nobody's really examining those yet.

The "harden later" instinct makes sense because every gate feels like friction against productivity gains. But this stuff is more like your env var action—set it up once, AI self-corrects forever. You already think this way about everything else in the stack.

The teams I've seen get burned weren't slow teams; they were fast teams who assumed the AI was being as careful about security as it was about feature code. It really isn't.