Notifications
Clear all
Topic starter
25/06/2026 1:30 am
TL;DR: Static API keys remain a primary breach entry point because they are bearer credentials with no native expiry, identity binding, or revocation signalling, while GitGuardian found 28,649,024 new secrets exposed on public GitHub in 2025 and 70% of leaked 2022 secrets still active. The real issue is not storage hygiene but the persistence of static trust in environments where AI agents and service sprawl have already broken that assumption.
NHIMG editorial — based on content published by Akeyless: API key management guidance for modern service and AI agent environments
By the numbers:
- 70% of secrets leaked in 2022 are still valid and exploitable today.
Questions worth separating out
Q: How should security teams replace API keys in service-to-service authentication?
A: Prefer workload identity, OAuth 2.0 client credentials, or short-lived tokens over static API keys.
Q: Why do API keys create more risk in cloud and AI agent environments?
A: API keys travel poorly in environments that generate many tool calls, logs, and temporary contexts.
Q: What breaks when API keys are stored and rotated manually?
A: Manual management breaks at scale because each key must be updated everywhere it is used, then revoked without disrupting dependent services.
Practitioner guidance
- Replace static keys on new service paths first Start with integrations that already support workload identity, OAuth 2.0 client credentials, or short-lived tokens.
- Move secrets out of application runtime context Issue credentials through a vault or secrets proxy so the application receives a time-limited token instead of a reusable key.
- Tighten key scope at issuance time Assign each key to one service, one environment, and the narrowest endpoint set possible.
What's in the full article
Akeyless's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance for choosing between API keys, OAuth 2.0 client credentials, and workload identity in different deployment models.
- Practical rotation patterns for teams that still depend on static keys across multiple services and environments.
- Examples of where secrets are leaking beyond source code, including CI/CD outputs, collaboration tools, and agent runtimes.
- A comparison of vault-backed handling versus dynamic credential issuance for service and AI agent access.
👉 Read Akeyless's guide to API key management and AI agent risk →
API keys, AI agents, and the governance gap teams are missing?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
25/06/2026 10:57 am
Static API keys are a governance failure, not just a secrets hygiene issue. The problem is that the credential model itself assumes the bearer string can be protected, rotated, and revoked faster than it can be copied. Once API keys spread into code, logs, and collaboration systems, that assumption no longer holds. Practitioners should read this as an IAM design flaw, not a storage mistake.
A few things that frame the scale:
- 28,649,024 new secrets were exposed on public GitHub in 2025, a 34% year-over-year increase and the largest single-year jump ever recorded, according to Guide to the Secret Sprawl Challenge.
- 64% of valid secrets leaked in 2022 are still valid today, which shows that exposure and revocation remain decoupled in many environments.
A question worth separating out:
Q: Who is accountable when a leaked machine credential is abused?
A: Accountability sits with the team that issued the credential, defined its scope, and failed to enforce lifecycle controls. If the key was broad, long-lived, or left in places it should not have been stored, the governance failure is upstream of the attack and should be treated as an IAM ownership issue.
👉 Read our full editorial: API key management fails when static credentials outgrow IAM
