Secrets Management in 2026: 29 Million Leaked Credentials and What Actually Stops It

28.65 million new hardcoded secrets were added to public GitHub commits in 2025 alone — a 34% year-over-year increase and the largest single-year jump on record (GitGuardian). This isn't a slowly improving problem; it's accelerating, and AI-assisted coding is a documented accelerant, not a bystander.

The scale of the problem, in numbers

GitGuardian's 2026 State of Secrets Sprawl report is the most detailed dataset available on this, and the numbers are worth sitting with:

That 64% figure deserves particular attention: a secret leaked in 2022 and never rotated is, as of 2026, still a live credential an attacker can use today. Detection without remediation isn't a fix — it's a false sense of security.

Why AI coding tools make this worse, specifically

AI-assisted commits leak credentials at roughly twice the baseline rate of manually written commits (GitGuardian). The mechanism isn't mysterious: an AI coding assistant given a task like "connect this to the Stripe API" will often produce working code fastest by hardcoding a key inline rather than wiring up environment variable retrieval — because it optimizes for a demonstrably working snippet, and the human reviewing a fast-generated diff is less likely to scrutinize it line-by-line than code they wrote themselves. AI-service secret detections specifically — API keys for OpenAI, Anthropic, and similar providers — rose 81% year over year, reflecting both the growth in AI tool adoption and this same pattern repeating across a new category of credential (GitGuardian).

Choosing a secrets platform: cloud-native vs. Vault

The core architectural decision most teams face: use your cloud provider's native secrets manager, or adopt a cloud-agnostic platform like HashiCorp Vault (or open-source alternatives like Infisical/OpenBao).

The practical guidance is straightforward: if your infrastructure lives on a single cloud provider, use that provider's native secret manager — AWS Secrets Manager, for instance, excels in AWS-native deployments with built-in automatic rotation (Cycode). If the platform spans multiple clouds, or needs dynamic database credentials issued on-demand rather than static long-lived ones, Vault is worth the added operational investment (Cycode).

Rotation: the practice most teams skip

Automated rotation — no long-lived static credentials surviving in production — is the core best practice, but the specific guidance is concrete: rotate static keys every 90 days maximum, and prioritize migrating to dynamic secrets or short-lived tokens wherever possible to eliminate the manual rotation burden entirely (Wiz).

Rotation policy in practice:
  Static API keys:        rotate every 90 days (hard maximum)
  Database credentials:   migrate to Vault dynamic secrets
                           (issued per-session, auto-expire)
  SSH credentials:        short-lived certificates over static keys
  TLS certificates:       automated renewal (e.g., cert-manager),
                           never manually tracked expiry dates

When a rotation policy requires 90-day cycles across thousands of credentials — which is the reality at any team past a handful of services — automation stops being optional. The platform needs to rotate database passwords, API keys, SSH credentials, and certificates on a defined schedule or in direct response to a security event, because manual rotation at that scale simply doesn't happen reliably (Wiz).

Beyond code: the 28% you're not scanning

Most secrets-management effort focuses on source code — pre-commit hooks, CI scanning, GitHub secret scanning. But roughly 28% of incidents originate from leaks in collaboration and productivity tools — Slack messages, shared docs, ticket descriptions — not repositories (GitGuardian). A credential pasted into a Slack thread for debugging, then forgotten, is exposed to every current and future member of that channel, and increasingly to AI agents with workspace access that can retrieve and act on it. Scanning coverage that stops at the git repo boundary misses over a quarter of real incidents.

What GitHub itself is doing

GitHub expanded secret scanning in 2026 to watch all public repositories for leaked enterprise keys, not just repos where the owner has opted in — a response to the scale of the 28.65-million-secret figure making opt-in scanning insufficient (TechTimes). This is a useful safety net but not a substitute for internal controls — it catches secrets after they've already been committed to a public repo, not before.

Actionable takeaway

Three changes address the highest-leverage gaps the data points to: first, add pre-commit secret scanning (not just CI-stage scanning) so leaks are caught before a push, not after — this matters more with AI-assisted coding specifically, since that's where the 2x leak rate originates. Second, treat the 64%-still-active statistic as a mandate to audit and rotate every credential older than 90 days, not just to add scanning going forward. Third, extend secret-scanning coverage to Slack, docs, and ticketing systems, since roughly 28% of real incidents originate outside your codebase entirely.

Sources: GitGuardian — State of Secrets Sprawl 2026, Cycode, Wiz, CloudOptimo, TechTimes