Secrets Management & Key Rotation: The 2026 Reference

Secrets management is the discipline of keeping the credentials that unlock your systems — API keys, database passwords, signing secrets, OAuth tokens — out of source code, off developer laptops, and unusable the moment they leak. In 2026 it stopped being a nice-to-have. GitGuardian's own dataset counted roughly 29 million hardcoded secrets added to public GitHub in 2025, and the credential you forgot to rotate is now the credential an attacker most reliably finds.

What's changed is not the threat — leaked credentials have been a top breach vector for years — but the texture of it. AI coding assistants ship code faster and, per GitGuardian's measurement, leak secrets at a higher rate while doing so. A brand-new attack surface opened up in Model Context Protocol (MCP) configuration files. And, paradoxically, the leaks that hurt most are the ones nobody ever cleaned up: the same dataset found that 64% of credentials valid and leaked in 2022 were still active in January 2026.

This reference walks the full lifecycle: how big the 2026 leak problem actually is, why AI tooling amplifies it, the OWASP-defined stages every secret moves through, a comparison of where to store secrets in a serverless-first stack, the zero-downtime rotation patterns that genuinely work, why OIDC federation lets you skip rotation entirely for some credentials, and the scanning and incident-response steps that catch the leaks you didn't prevent. Every figure below is attributed to its primary or stated source.

Start with the volume. GitGuardian's State of Secrets Sprawl 2026 — the firm's annual scan of public GitHub activity — reported 28,649,024 hardcoded secrets added in 2025, a 34% increase year over year and, per GitGuardian, the largest single-year jump in its reporting history. These figures come from GitGuardian's own detection dataset, not a neutral industry benchmark; read them as a credible vendor measurement of the leaks its scanners can see, which skews toward public repositories.

The more uncomfortable finding is what happens after a secret leaks. GitGuardian reported that 64% of credentials that were valid and leaked in 2022 were still active and exploitable in January 2026. Separately, it found that long-lived secrets dominate the policy-breach pattern: around 60% of the violations it tracks involve credentials with no expiry configured at all. The throughline is governance, not technology. Rotation works; the problem is that most teams have no repeatable path to actually do it when a leak is discovered.

Two structural findings reframe where you should look. First, private repositories are not safer: GitGuardian reports internal repos are roughly six times more likely to contain a hardcoded secret than public ones — the perceived safety of a private repo breeds carelessness. Second, a meaningful share of incidents originate outside repositories entirely. About 28% of the credential incidents GitGuardian tracked came from collaboration tools — Slack, Jira, Confluence — and those were, in its data, 13 percentage points more likely to be classified as critical than repository leaks. Your scanning coverage probably stops at the repo; the leaks don't.

Here is the angle most coverage misses. AI coding tools do two things at once: they write more code, faster, and — per GitGuardian's dataset — that code leaks secrets at a higher rate than human-baseline commits. GitGuardian reported that AI-assisted commits leaked secrets at roughly twice the baseline rate. We are deliberately not printing the precise per-tool percentages as if they were a neutral benchmark: these come from GitGuardian's own measurement and methodology, they have not been independently replicated, and the honest framing is "roughly double, per GitGuardian," not a hard universal constant.

The category-level trend is the durable signal. GitGuardian reported that AI-service credential leaks surged about 81% year over year in 2025, with eight of its ten fastest-growing detector categories tied to AI services. As a single illustration, it counted roughly 113,000 leaked DeepSeek API keys on public GitHub. The mechanism is intuitive: developers wiring up new AI providers paste keys into quick-start scripts, commit the scaffolding, and move on. More providers plus faster scaffolding equals more exposed keys.

The takeaway is not "stop using AI tools." It is to treat AI-generated code as a higher-risk source for hardcoded secrets and adjust your guardrails accordingly: a pre-commit secret scanner is no longer optional when an assistant can generate fifty lines of integration boilerplate in a keystroke. The same automation that creates the risk can close it — push protection and pre-commit hooks run just as fast against AI output as human output.

Model Context Protocol configuration files are where AI agents are told which tools and services they may call — and, too often, the credentials to call them with. GitGuardian's 2026 report is the first large-scale measurement of this surface: it found 24,008 unique secrets exposed in MCP configuration files on public GitHub, of which 2,117 (8.8%) were confirmed validcredentials. That validity rate matters — these aren't expired placeholders, they are live keys an attacker could use.

The leak mechanism is depressingly familiar: developers copy an MCP server config from a tutorial, drop their real API key into the example, get it working, and commit the whole file. Because MCP tooling is new, most teams haven't added these file patterns to their scanner allowlists or pre-commit checks yet. If you're building agentic workflows — and on a custom-AI-build stack you probably are — add MCP config paths to your secret-scanning scope today, and prefer referencing credentials by environment variable inside those files rather than inlining them.

The OWASP Secrets Management Cheat Sheet is the industry-standard reference here, and it frames every secret as moving through four lifecycle stages. Getting the lifecycle right is what turns secrets management from a pile of one-off env vars into a governable system. OWASP also classifies hardcoded and improperly stored secrets under the A04:2025 — Cryptographic Failures category in the current OWASP Top 10, with continuous secret scanning recommended as a compensating control.

OWASP's recommended order of preference for CI/CD secrets is, in descending order: a dedicated secrets-management system (Vault, AWS Secrets Manager); the CI/CD native store (GitHub Secrets, GitLab Variables) for short-lived, non-critical credentials; and runtime-only retrieval, where the running service fetches the credential at runtime and the CI/CD pipeline never touches it at all. Most leaks live below that hierarchy — in plain env vars and committed config — so the first move is simply climbing it.

The table below is our consolidated comparison for a serverless-first stack. We have not seen an existing comparison that puts OIDC workload identity and open-source self-hosted options alongside the managed services in one view; most stop at three tools. Cells are drawn from the vendor documentation and comparison sources cited throughout this guide.

The core pattern is the same everywhere, and it is dead simple: generate the new credential, deploy it everywhere, verify, and only then revoke the old one. The critical constraint — the one that causes most rotation outages — is the overlap window. Both old and new credentials must be valid simultaneously until every consumer has picked up the new one. Invalidate the old credential too early and anything that hasn't redeployed yet breaks.

Vercel documents this precisely for environment variables: generate the new credential at the provider, update the Vercel environment variable, redeploy the affected project(s), verify, and finally invalidate the old credential — and it warns explicitly that invalidating the old credential before all projects have redeployed will break those projects. AWS Secrets Manager encodes the same idea with staging labels: AWSCURRENT and AWSPENDING track the two versions through a four-step Lambda flow (createSecret → setSecret → testSecret → finishSecret), with both credentials active during the transition window.

One forward-looking note on operationalizing rollouts: the safest way to cut traffic over to a freshly rotated credential is to gate it. Rather than flipping every consumer at once, route a small slice of traffic to the new credential, confirm health, then ramp — exactly the discipline described in our guide to feature-flagging credential rollouts. A flag lets you abort instantly if the new credential misbehaves, without a redeploy, and it makes the overlap window an observable, controllable thing instead of a race.

The most consequential shift for serverless and CI engineers is also the least adopted, because most tutorials still show a long-lived API key pasted into an environment variable. OIDC federation removes the stored credential entirely. Vercel's OIDC federation issues short-lived, non-persistent tokens signed by Vercel's identity provider; AWS, GCP, and Azure can exchange those tokens for scoped, short-lived cloud credentials. Per Vercel's docs, the token TTL is 60 minutes and Vercel caches it for up to 45 minutes to ensure validity within a function's execution lifecycle. The net effect: no long-lived cloud key ever lives in your environment variables, so there is nothing to leak and nothing to rotate.

The same principle applies to databases through Vault dynamic secrets. Instead of a static database password sitting in an env var, the service requests a credential from Vault at runtime; Vault generates one scoped to a configurable TTL and automatically revokes it when the lease expires. We deliberately avoid quoting a single default TTL — the actual value depends on the secret engine and your configuration — but the pattern is the point: short-lived by construction, revoked automatically, never committed anywhere.

If you take one architectural decision from this reference, make it this: for any credential where the provider supports short-lived, federated, or dynamically-issued access, prefer that over a stored long-lived key. It is the only approach that defeats the 64% never-revoked statistic structurally, because there is no persistent secret for anyone to forget to rotate.

Federation and rotation reduce how many long-lived secrets exist; scanning catches the ones that still slip through. The production-grade strategy layers two open-source tools with platform push protection. Gitleaks covers 150+ secret patterns and is fast enough to run as a pre-commit hook, blocking a push in milliseconds before the secret ever reaches the remote. TruffleHog covers 800+ secret types across git repos, S3, Docker images, Slack, and Jenkins — and, crucially, actively verifies whether a detected credential is still live, which cuts the noise of expired-placeholder false positives. The recommended combination: Gitleaks pre-commit plus TruffleHog in CI.

Platform-level push protection is the third layer. GitHub's secret scanning blocks known credential patterns at push time; per GitHub's changelog, it added base64-encoded secret detection with push protection by default in November 2025 and shipped extended metadata (owner, email, creation and expiry dates) for leaked secrets in February 2026. GitHub also reports that a Copilot-assisted scanning improvement achieved a 94% reduction in false positives. We are reporting only the figures GitHub states; treat broader "total secrets blocked" claims with caution unless you can confirm them against the primary changelog.

Detection is worthless without a rehearsed response. OWASP's incident-response playbook for a leaked secret is four ordered steps, and the order matters: Revoke the credential immediately to de-authorize it; Rotate in a replacement, preferably through automation; Delete the secret from all systems and from commit history; and Logthe access patterns prior to exposure so you can assess blast radius. Revoke comes first for a reason — removing the secret from git history without first revoking it leaves a live credential in anyone's existing clone.

OWASP also requires that the whole lifecycle be auditable: who requested each secret, what approvals were granted, when it was used, and every rotation and revocation event. That audit trail is what turns a one-off scramble into the repeatable remediation path whose absence drives the 64% never-revoked figure. The discipline is the deliverable — a documented, drilled runbook beats a clever tool every time.

For teams building on a custom-AI stack, this is exactly the kind of governance we wire into delivery from day one rather than bolting on after an incident. If you want a second set of senior eyes on your secrets posture — scanning coverage, rotation automation, OIDC adoption, and an incident runbook — our AI transformation engagements and custom development work start with precisely this kind of review.