Notifications
Clear all
Topic starter
25/06/2026 3:17 pm
TL;DR: An exposed API key used to access 52 xAI models, including Grok, stayed active after the GitHub repository was removed, illustrating how hardcoded credentials, once leaked, can outlive the incident that exposed them, according to Aembit. Static secrets reduce friction but not trust exposure; workload identity and conditional access change the control model.
NHIMG editorial — based on content published by Aembit: Secure secrets and workload identity after an exposed API key leak
Questions worth separating out
Q: What breaks when an exposed API key is still active after being removed from GitHub?
A: The incident response window collapses if the credential remains valid after repository takedown.
Q: Why do static secrets create more risk than secrets managers alone can eliminate?
A: Secrets managers improve storage, but they still leave a workflow where credentials are fetched, handled, and sometimes logged by people or applications.
Q: How can security teams reduce the impact of leaked machine credentials?
A: They should reduce credential lifetime, bind access to workload identity, and require context-aware checks before tokens are issued or accepted.
Practitioner guidance
- Inventory every static machine credential Find API keys, tokens, and certificates stored in source code, local config, build variables, and shared documentation, then map who can create, retrieve, and revoke each one.
- Federate access for workloads wherever possible Replace long-lived keys with short-lived, scoped credentials issued to known workloads through identity federation so the application does not depend on a copied secret.
- Add context checks to machine access Require verified environment, workload identity, and posture before issuing access so a leaked credential alone is not enough to authenticate from outside the approved context.
What's in the full article
Aembit's full analysis covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of how secrets managers, federation, and workload IAM differ in implementation.
- Practical comparisons of long-lived keys versus short-lived workload credentials in machine access flows.
- Detailed discussion of conditional access policies for non-human identities and workload posture checks.
- Operational guidance on reducing developer handling of credentials without breaking application access.
👉 Read Aembit's analysis of exposed API keys and workload identity controls →
Exposed API keys and workload identity: what IAM teams need now?
Explore further
25/06/2026 4:43 pm
Static credentials are a trust debt, not just a hygiene issue. Once an API key is embedded in code, the organisation inherits an exposure window that depends on discovery, revocation, and downstream propagation, not just repository cleanup. That is why secret handling must be treated as lifecycle governance for machine identities, not as a developer training problem. The practitioner conclusion is simple: every static credential creates residual trust that must be retired deliberately.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to The State of Secrets Sprawl 2026.
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
A question worth separating out:
Q: When should organisations replace API keys with federated workload access?
A: They should do it whenever the workload repeatedly accesses sensitive services, crosses environments, or depends on credentials that developers might handle manually. Those are the conditions where static keys become a recurring exposure point. Federation is especially appropriate when the application can authenticate as itself instead of borrowing a human-managed secret.
👉 Read our full editorial: Secrets managers are not enough for exposed API key risk
