API Credential Storage and Rotation Strategies

Hardcoding a secret directly into source code is the classic mistake. Everyone knows not to do it. People keep doing it anyway because it works immediately and the consequences are invisible until they aren't.

The deeper problem is that version control remembers. Delete the key from your current codebase all you want. It's still sitting in the commit history, accessible to anyone who can clone the repo.

And if you're thinking "well, our repos are private" (that's not the protection it sounds like). Internal repositories were actually six times more likely than public ones to contain hardcoded secrets, per GitGuardian research. Private repos create a false sense of safety that makes people less careful. You end up with a perfectly locked front door and every window wide open.

But here's the part that gets missed most often: 43% of all exposed secrets don't live in code repositories at all. They live in:

• Slack, Jira, Confluence, and similar collaboration tools. Someone posted a connection string to debug a production problem three years ago. It's still there. Nobody went back to delete it.
• CI/CD runner machines. In GitGuardian's 2026 report, 59% of compromised machines were CI/CD runners. Not personal laptops. The build infrastructure. And on average, each live secret appeared in eight different locations on the same machine.
• URL query parameters. When you include an API key in a URL, it shows up in server logs, proxy logs, and browser history. Google's own guidance recommends header-based delivery for exactly this reason, though plenty of codebases I've seen ignore it.

Storage hygiene isn't a one-time decision you make at setup. It's a set of habits that have to hold across every environment and every tool your team actually touches, including the ones that don't feel like "real" infrastructure.

AI-assisted development as an accelerating leak vector

AI tooling has introduced a problem the industry hasn't fully caught up to. In 2025, GitGuardian detected over 1.27 million leaked secrets tied to AI services. That's an 81% increase from the year before. Eight of the ten fastest-growing categories of leaked secrets year-over-year are AI-service credentials.

Two behaviors are driving most of this.

The first is debugging through LLMs. A developer hits a connection error, copies the full config block including the API key, pastes it into ChatGPT or Claude, and asks what's wrong. That secret just traveled somewhere it was never supposed to go. It felt like a reasonable shortcut. It happened so fast there was no moment to second-guess it.

The second is MCP configuration files. The Model Context Protocol is still relatively new. In its first year of mainstream use, GitGuardian found over 24,000 unique secrets exposed in MCP configuration files. That's not surprising. New tooling always creates new surfaces before anyone has figured out the norms around it. The security habits haven't had time to form yet.

There's also a concrete number worth sitting with. Commits using Claude Code showed a 3.2% secret leak rate in 2025, compared to a 1.5% baseline. That's not a reason to stop using AI coding tools. Those tools are genuinely useful and the productivity gains are real. It's a reason to put guardrails in place before the AI step, rather than scrambling to apply them after.

The storage hierarchy. From environment variables to hardware-backed vaults

Think of this as a stack. Each level adds more protection and more control, usually at more setup cost. The right level for any given credential depends on what it unlocks and what actually happens if it leaks.

Environment variables are the minimum floor. They keep secrets out of source code, which is better than nothing. The rules are simple: never commit your .env file, use separate credential sets for dev, test, and production environments. A compromise in a lower environment should not be able to reach production. Treat this as a starting point, because it is one.

Dedicated secrets managers are the practical standard for any team past the early startup phase. Tools in this category give you encrypted storage, granular access controls, audit logging, and integration with your existing auth systems. AES-256 at rest, TLS 1.3 in transit. Honestly, the audit log alone is worth the setup cost. When something does go wrong, you want to know who accessed what and when, and without that log you're guessing.

Hardware Security Modules and cloud KMS are for high-value or compliance-sensitive credentials. The key material is physically separated and tamper-resistant, per UK NCSC guidance. Most teams don't need this for every credential. Some teams absolutely need it for a handful of specific ones. The distinction matters.

Platform-native secure storage handles mobile and desktop: Android Keystore, iOS and macOS Keychain Services, Windows Credential Locker. When a token needs to live on a device, these are the right containers for it. A local config file is the wrong choice. So is a hardcoded string.

Running through all of these is least privilege. Each application or service should only reach the credentials it actually needs right now, not the ones it might need someday. Unused OAuth clients with valid credentials sitting dormant are a quiet, patient risk. Audit them. Delete them.

Not every credential needs an HSM. But every credential needs a decision.

Why rotation matters and where teams underestimate it

The logic is simple. A compromised secret that rotates every 24 hours has at most 24 hours of usefulness to an attacker. A secret that never rotates stays useful indefinitely. Those 64% of 2022 leaks that are still valid today? They never got rotated. They just kept sitting there, quietly exploitable.

Rotation also matters for compliance. SOC 2, PCI DSS, and NIST frameworks all treat credential management as a named control, per Doppler.

The commonly cited baseline is rotating API keys at least every 90 days. AWS Security Hub and most major providers align to this interval. Worth knowing as of mid-2025: OpenAI and Anthropic have no automatic expiry on their keys. Manual rotation every 90 days is your only option. Google Cloud lets you set expiry dates directly in the console, which is a genuinely nice feature.

Scheduled rotation and event-triggered rotation are different things, and conflating them is where teams get into trouble. A developer leaving the company, a credential showing up in a log file, a supply chain incident. All of these require immediate rotation regardless of where you are in the 90-day cycle. The March 2025 tj-actions/changed-files incident is the clearest recent example: a malicious version silently exfiltrated CI/CD secrets into build logs. No scheduled rotation cadence would have caught that. You rotate the moment you know, not when the calendar says to.

Here's where most teams underestimate the problem, though. Rotation doesn't protect you in the window between compromise and detection. That gap is still enough for an attacker to spin up infrastructure, exfiltrate data, or pivot deeper into your systems. Rotation shrinks the window. It does not close it.

And then there's the messy human reality. Fear of downtime and increasing operational complexity prevent a lot of teams from rotating consistently, per Doppler. The rotation process itself becomes the vulnerability, which is a genuinely frustrating place to end up.

Running a zero-downtime rotation in practice

Rotation breaks things when it's treated like a light switch: old secret off, new secret on, fingers crossed that everything picks it up in time. That's the version that causes 3am incidents and makes people avoid rotation altogether.

HashiCorp's well-architected framework describes a blue/green approach. Think of it like a deployment, not a cut-over:

1. Store the current credential at one path. Generate the new credential at a second path.
2. Validate the new credential in a non-production context first.
3. Deploy the new credential to consuming applications.
4. Run both credentials active simultaneously for a defined grace period. The old one stays alive until your traffic confirms the new one is working.
5. Monitor logs for any continued use of the old credential.
6. Revoke the old credential once you're confident the new one has fully taken over.

The dual-active grace period is not a security compromise. It's what makes zero-downtime rotation actually achievable without turning every credential change into a production incident.

A few failure modes make rotation dangerous instead of protective, and I've seen all of them:

• Hardcoded copies downstream. If a credential is baked into a container image or committed to a repo, rotating the entry in your secrets manager does nothing. The old copy still works. You rotated in your vault and nowhere that matters.
• Silent rotation failures. The rotation runs. The application never picks up the new credential. No alert fires. You find out when something breaks in production at the worst possible time.
• The rotation system itself going down. If your vault loses availability mid-rotation, you get an outage, not a security win.

The only real fix is automation. A process that depends on a human to execute it every 90 days will eventually get skipped. Because someone is on vacation, or there's a big launch, or it just quietly falls off the list. Tooling that handles generation, deployment, validation, and revocation removes that dependency entirely.

Secrets detection as the gap-filler between rotation cycles

Rotation runs on a schedule. Compromise doesn't wait for the schedule.

The March 2025 tj-actions supply chain incident makes this concrete. Credentials were exfiltrated before any scheduled rotation would have fired. The calendar was irrelevant. What mattered was whether anyone was watching.

Secrets detection adds continuous scanning across commits, pull requests, CI logs, and collaboration platforms. It watches for credential patterns and flags them as they appear, not after the next rotation cycle fires.

The earliest possible intervention point is the pre-commit hook. A secret gets caught before it ever enters version control. That's a fundamentally different outcome from catching it after it's already in the commit history and potentially synced to a remote.

The full picture:

• Detection catches accidental exposure at the moment it happens.
• Storage controls limit who and what can reach a credential at rest.
• Rotation limits how long a compromised credential stays useful.
• Each layer covers the gaps in the others. None of them work alone, and anyone selling you a single-layer solution is leaving out the inconvenient parts.

For teams managing credentials across many third-party APIs, the operational weight of running this stack manually is real. Per-provider rotation schedules, per-platform detection rules, credential propagation to every consuming service. That complexity isn't just annoying to deal with. It's where the gaps form. The gaps attackers find. The more manual the process, the more likely something gets skipped, forgotten, or silently broken while everyone assumes someone else is handling it.

Automation doesn't make secrets management exciting. It just makes it something you can actually sustain.