GitGuardian published its State of Secrets Sprawl report for 2026 today, covering last year's data, and I want to react to it while it's fresh because a few of the specific numbers land differently than the general "secrets get leaked sometimes" framing usually does.
The headline numbers
A 34% jump in leaked secrets is a real, measurable increase, not a rounding difference. And it's happening against a backdrop of commit volume also rising sharply, which on its own would predict more leaks just from more code being written. The secrets number rising even faster than commit volume is the part worth actually sitting with.
The detail that stood out most
The report notes that commits assisted by Claude Code showed a secret-leak rate of 3.2%, compared to a 1.5% baseline across all public GitHub commits, and that leaked secrets tied to AI services specifically surged 81% year over year. I want to be careful with this one: it's GitGuardian's own self-reported figure, and I haven't seen it independently re-verified elsewhere, so I'd treat the exact multiplier with some caution rather than repeating it as an airtight fact. The general direction it points at, AI-assisted commits leaking secrets somewhat more often than average, lines up with everything else I've written about this year, even without leaning on that one specific number.
Why this direction makes intuitive sense
AI coding tools make it fast to wire up a new integration, and wiring up an integration usually means a key needs to go somewhere. The path of least resistance, paste the key directly into a config file or a client-side variable, works immediately and gets the feature running. The extra step, moving it to a proper environment variable or secret manager, takes a little longer and doesn't change whether the demo works. Faster iteration on more integrations, with the same shortcut available every time, is a reasonable enough explanation for a leak rate ticking up, independent of any specific number in this particular report.
What to actually do with this, beyond noting it
- If you've committed a key to git history at any point, even one you later removed from the current file, treat it as compromised and rotate it. Deleting the line doesn't delete the history.
- Run a secrets scan across your own repositories, not just your current files. Several free tools do exactly this, checking full commit history, not just the latest snapshot.
- Build the habit of a quick scan before every push becomes routine, the same way linting or testing already is, rather than a one-time cleanup you do once and consider solved.
The specific numbers in any one report will shift year to year, and some individual figures deserve a second look before being repeated as gospel. The underlying pattern, more code shipping faster, with the same easy shortcut for handling secrets available every time, is the part that doesn't need a single report to be true. It's the same story this blog has been telling all year, just with a bigger number attached to it this month.