AI-Assisted Commits Leak Secrets at Twice the Baseline Rate — Why Your PaaS Should Scan Every Push

In 2025, developers pushed 28.65 million new hardcoded secrets to public GitHub — a 34% year-over-year increase and the largest single-year jump GitGuardian has ever recorded. Buried in that number is the finding that should change how every git-push platform thinks about its push path: commits assisted by AI coding tools leaked secrets at a 3.2% rate, versus a 1.5% baseline across all public commits. The moment an AI tool enters the loop, the leak rate roughly doubles.

Here is the verdict up front, with the evidence to follow: secret scanning belongs in a git-push PaaS's push path as a default-on gate, not an opt-in tenant integration. The platform's build layer ingests a tenant's repo on every deploy, which makes the push the last moment anyone can stop a credential from entering history. And history is the whole problem — no runtime secrets manager, however well run, can un-leak a key that is already committed. Vault, OpenBao, and Infisical protect secrets at injection time; they never see the git history where the exposure actually happened.

Why AI-assisted commits leak more​

The doubled rate is not mysterious once you look at the mechanism. A human writing a commit typically pauses at the diff — that review moment, however cursory, is where a pasted key gets noticed. AI-assisted workflows systematically remove it: the agent generates the code, stages it, and in auto-commit setups pushes it, with the human approving a summary rather than reading the diff. The leak still happens through a human workflow — someone clicks approve — but the approval covers intent ("add Stripe webhooks"), not content ("and also commit the live secret key the agent copied from your shell history into .env").

Three concrete patterns drive most of the gap:

• Agents write config files with real values. Ask an agent to "make auth work" and it will happily scaffold the .env, the config file, or the docker-compose override — populated with the working credentials it found in your environment so it can verify the feature end to end. That file then rides along in the next commit.
• MCP configs embed tokens. Model Context Protocol server configs routinely carry API keys inline, and GitGuardian found over 24,000 unique secrets in MCP config files on public GitHub, more than 2,000 of them live at scan time. Agent infrastructure is minting a brand-new secret-bearing file format faster than ignore-file conventions can cover it.
• AI-service keys are the fastest-growing leak category. Exposed AI API keys, agent tokens, and LLM service credentials surged 81% to 1.275 million in 2025 — eight of the ten fastest-growing detector categories are AI-service related. The tools that write the code need keys of their own, and those keys leak through the same channel.

Walk through the typical failure end to end: a developer asks their agent to integrate an AI API. The agent drops the key into a config file to test the integration, marks the task complete, and the developer — reviewing ten agent-produced diffs that afternoon — approves without opening the config. CI is green because the key is valid.

The push lands, the key enters history, and automated secret-harvesting bots, which scan public push events within seconds, now hold a live credential. Nothing in this chain malfunctioned. Every step did exactly what it was designed to do.

What your secrets manager never sees​

The standard advice — "use a secrets manager" — is correct and completely beside the point for this failure mode. Vault, OpenBao (the Linux Foundation's MPL-licensed Vault fork), and Infisical all solve the same problem: getting the right secret into a running workload without baking it into an image or an env file. That is a runtime-injection problem. A git-history leak is a source-control problem that happens hours, days, or weeks before the app ever runs. By the time the workload starts and the secrets manager does its job, the credential has been sitting in a public commit — indexed, cloned, and harvested — the entire time.

Only the last row acts before the secret becomes permanent, and permanence is the operative word: GitGuardian found that 64% of valid secrets leaked back in 2022 were still valid and exploitable years later. Rotation discipline is bad enough that a leaked credential should be treated as compromised indefinitely. "We'll rotate it after the CI scan flags it" is a remediation plan for a secret that harvesting bots grabbed the second the push event fired.

The platform answer: scan the push, not just the repo​

GitHub already proved this gate works at planetary scale. Push protection — server-side scanning that blocks a push containing a known secret pattern before it lands — has been measured in secrets blocked per minute, and GitHub's own accounting put total prevented leaks in the tens of thousands within the first beta year alone. The design insight is that the server is the one enforcement point the developer cannot skip: no local hook to forget installing, no --no-verify escape hatch, no "I'll enable it next sprint."

For a self-hosted git-push PaaS, the equivalent gate sits in the platform's receive path — wherever git-receive-pack (or the API endpoint that accepts the push) runs — and it needs four properties:

1. Scan the incoming diff, not the whole repo. Only new blobs need checking, which keeps the gate fast enough to run synchronously on every push. gitleaks and ggshield both support this mode; the gate should cover provider patterns plus high-entropy generic detection, since custom-format keys are exactly what platform-level pattern lists miss.
2. Reject with a message that teaches. A bare "push rejected" trains developers to route around the gate. The rejection should name the file and line, identify the secret type, and link rotation guidance — the developer's next action must be obvious.
3. Ship default-on with a scoped bypass. Tenants that genuinely need to push test fixtures get an allowlist they configure explicitly (path-scoped, committed in-repo like .gitleaks.toml), not a global off switch. Default-on with friction to disable beats opt-in every time — the 3.2% leak rate is disproportionately produced by developers who never got around to enabling anything.
4. Log every block and bypass centrally. The platform sees push traffic across all tenants, which means it can measure its own leak-interception rate the way GitHub does — and spot tenants whose bypass rate suggests the gate is being treated as noise.

One honest scoping note: a push gate stops new leaks; it does nothing for the secrets already sitting in history. Pair it with a one-time full-history scan at tenant onboarding (gitleaks detect over all refs), with findings reported as "rotate these now" rather than push-blockers. And keep the runtime secrets manager — defense in depth still applies. The point is only that injection-time protection was never a substitute for push-time prevention, and the 2026 numbers make the cost of that confusion concrete.

What to do Monday morning​

If you deploy apps (app-team checklist):

• Turn on push protection wherever your code lives (GitHub: Settings → Code security → Secret scanning → Push protection). It is the single highest-leverage control in this post.
• Add gitleaks protect --staged as a pre-commit hook and a gitleaks-action CI job — local for speed, CI for the --no-verify case. Pin the gitleaks version so the oracle cannot drift silently.
• Assume every secret that ever touched git history is compromised: rotate it, then purge it from history (BFG or git-filter-repo), in that order.
• Move agent and MCP configs to short-lived credentials or local-only references; never commit an MCP server config containing a live token.

If you run the platform (operator checklist):

• Put a pre-receive secret scan in the push path, default-on for every tenant, with path-scoped allowlists instead of a global disable.
• Run a full-history scan at onboarding and hand the tenant a rotation list on day one.
• Back the push gate with a self-hosted secrets store (OpenBao or Infisical, synced into the cluster via External Secrets Operator) so tenants have somewhere safe to put the keys the gate refuses to accept in git. A gate with no alternative is just a wall.
• Track blocked pushes per tenant per week. A tenant with zero blocks and heavy AI-assisted commits is either exemplary or bypassing — the metric tells you which conversation to have.

Secrets now leak at machine speed; defenses must live at machine checkpoints​

The 2026 report's deeper story is not that developers got sloppier — it is that the commit pipeline got faster than the human review step it depended on. Agents write, stage, and push at a cadence where "someone will notice the key in the diff" is no longer a control; it is a hope. The defenses that still work are the ones that do not require noticing: a server-side gate that inspects every push, rejects the bad ones with instructions, and cannot be skipped with a flag. Platforms that build that gate into the push path by default will absorb the AI-commit era safely. Platforms that leave it as a tenant opt-in will spend 2027 rotating other people's keys.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.