TL;DR: Akeyless says Anthropic’s September 2026 Threat Intelligence Report shows AI compressing the path from exposed credential to enterprise compromise, including a suspected ShinyHunters affiliate scanning 1.8 million Android apps for hardcoded secrets. Static secrets now fail faster than manual remediation can respond.
At a glance
What this is: This analysis says AI-assisted secret hunting is turning hardcoded credentials into a faster, more scalable compromise path.
Why it matters: IAM and NHI teams need to treat secret exposure as a time-to-compromise problem, not just a discovery problem, because persistent credentials can now be found and weaponized at machine speed.
👉 Read Akeyless's analysis of AI-driven secret hunting and hardcoded secret exposure
Context
AI-assisted secret hunting is the use of automation and model-driven tooling to discover exposed credentials at scale and then exploit them quickly. In this article’s framing, the core governance gap is not whether secrets exist, but whether organisations can invalidate them before they become active compromise paths.
For IAM, NHI, and secrets programmes, the issue is structural: persistent credentials embedded in code, tokens, and app packages remain usable long after exposure. The article argues that discovery alone is no longer enough because adversaries can now move from finding to using secrets within hours.
The source treats hardcoded secrets as the primary fuel for the attack cycle, with AI compressing reconnaissance, token abuse, and exfiltration. That makes static credential management a lifecycle problem, not a point-in-time scanning problem.
Key questions
Q: What should security teams do first when hardcoded secrets are discovered in code or Git history?
A: The first step is to identify every place the secret appears, assign ownership, and revoke or rotate it before treating the finding as closed. Discovery without invalidation leaves the credential usable. Teams should also check dependent systems, because one leaked secret may authenticate to cloud, source control, CI/CD, or other downstream services.
Q: Why do hardcoded secrets create such a large security risk?
A: Hardcoded secrets turn source code, build output, and configuration files into credential repositories, which makes exposure easy to repeat and difficult to contain. Once a secret is copied into multiple systems, revocation becomes slow and incomplete, and the attack window stays open far longer than most teams expect. That is why hardcoded credentials are a governance failure, not just a code smell.
Q: How do security teams measure whether secret scanning is actually reducing exposure?
A: Security teams should measure the time from secret creation to detection, the percentage of repositories and build artifacts scanned, and the time from detection to rotation or revocation. Strong programmes also track how many exposed secrets remain valid after discovery. Those signals show whether scanning is finding risk early or only after exposure has spread.
Q: When should organisations replace static secrets with ephemeral credentials?
A: Use ephemeral credentials whenever a workload can tolerate short-lived access and the secret would otherwise persist across deploys, environments, or teams. That is especially important for CI/CD pipelines, privileged APIs, and automation that touches sensitive data. Ephemeral access reduces exposure, but only if the organisation also enforces revocation and monitoring.
Technical breakdown
How AI changes hardcoded secret discovery
The technical shift is in scale and selectivity. Traditional secret hunting was bounded by human time, so defenders could assume some exposed credentials would remain undiscovered for a while. AI-assisted hunting changes that by automating repository scraping, code decompilation, token extraction, and validation across huge artifact sets. The result is not merely more scanning, but a lower cost of discovery and a shorter interval between exposure and exploitation. Once the attacker can cheaply enumerate large code bases and app packages, the weak point becomes the credential itself, not the search process.
Practical implication: assume exposed secrets in source, history, and packaged artifacts will be found quickly and design controls around rapid invalidation.
Why static credentials create an enterprise blast radius
A hardcoded secret is dangerous because it is usually a bearer of trust, not a single-use proof. If the credential maps to a developer token, cloud key, or service password, it can provide access to code, CI/CD systems, or downstream cloud resources. The article’s examples show that one stolen token can become the bridge from a narrow foothold to broader administrative access. That makes the real issue credential reuse and persistence, not just where the secret was initially stored. The longer the credential remains valid, the more room attackers have to pivot.
Practical implication: tie every exposed credential to its reachable systems so blast radius can be reduced before revocation.
Why discovery must connect to revocation and dynamic issuance
Scanning without control integration creates a prioritised breach list, not remediation. The article contrasts finding secrets with actually eliminating them, which requires rotation, revocation, and where possible replacement with short-lived credentials. Dynamic issuance changes the problem because there is no persistent secret to leak from code or history. That is why the governance model shifts from after-the-fact detection to issuance-time control. In NHI terms, the identity should authenticate by who or what it is, then receive scoped, ephemeral access only for the task at hand.
Practical implication: connect secret discovery to rotation and ephemeral credential issuance so remediation happens immediately after exposure is detected.
Threat narrative
Attacker objective: The attacker aims to turn a single exposed credential into broad operational access and rapid data theft before defenders can revoke it.
- Entry begins with exposed credentials, API keys, or authentication tokens embedded in code, app packages, or Git history.
- Credential harvesting scales through automated decompilation and secret scanning across large artifact sets, making discovery fast and exhaustive.
- Escalation follows when stolen tokens are converted into broader access, including source code, CI/CD systems, and cloud administration.
- Impact occurs when the compromised access is used for data collection, exfiltration, and enterprise-wide compromise within hours.
Breaches seen in the wild
- 12,000 secrets in LLM training data: Truffle Security found 11,908 live API keys and passwords hard-coded in web pages captured by Common Crawl, a dataset used to train LLMs.
- PyPI admin GitHub token leak 2024: A PyPI admin's GitHub token with admin rights over Python and PyPI repos sat in public Docker images for 15 months before JFrog found it.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
AI has industrialised secret hunting, but it has not changed the underlying weakness: persistent credentials are still the easiest path to compromise. The difference is speed and scale, not root cause. When discovery is automated across public, private, and packaged code, the time between exposure and exploitation collapses to a window that manual teams cannot reliably police. The practitioner conclusion is simple: treat hardcoded secrets as a time-bound liability, not a static finding.
Static secrets create an identity blast radius that exceeds the original leak. A single developer token can open source code, pipeline systems, and downstream cloud authority if the credential is reused across environments. That is why the problem is really about trust propagation through the credential estate. The practitioner conclusion is to measure not just whether a secret exists, but what systems it can still reach.
Hardcoded secret exposure is a lifecycle failure, not a scanning failure. Secret discovery programmes were designed for a condition in which exposed credentials could be reviewed before use. That assumption fails when attackers can validate and weaponise secrets in hours. The implication is that governance must move from periodic detection to rapid invalidation and shorter credential lifetime.
Ephemeral credential trust debt: organisations that keep static secrets in code accumulate a growing gap between exposure and revocation, and AI simply makes that debt mature faster. The operational consequence is that every unrotated secret becomes more valuable to the attacker over time. The practitioner conclusion is to reduce the stock of persistent credentials wherever possible.
Runtime enforcement is now part of secrets governance, not an optional control layer. Once attackers can use AI to accelerate reconnaissance, token conversion, and exfiltration, discovery alone cannot close the loop. The field needs joined-up governance across inventory, rotation, least privilege, and issuance patterns. The practitioner conclusion is to align secrets programmes with identity lifecycle control, not just scanning coverage.
From our research library:
- 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, according to the State of Secrets Sprawl 2026.
- Read next: Secrets Management Guide
What this signals
Ephemeral secret management is now a time-to-invalidation problem. Teams should assume exposed credentials in code, history, and packaged artifacts will be found faster than manual review cycles can react. That shifts the control point from after discovery to issuance and revocation, especially where CI/CD and cloud access are involved.
Persistent credentials are creating identity blast radius across the software supply chain. When a developer token can open source, pipeline, and cloud control planes, the organisation is no longer protecting a single secret. It is protecting every downstream system that secret can still reach, which is why least privilege and short-lived issuance now belong in the same programme conversation.
For practitioners
- Audit hardcoded secrets across code and history Search repositories, commit history, build artefacts, and packaged application assets for API keys, cloud tokens, and service passwords. Prioritise repositories that feed production systems or CI/CD pipelines.
- Rotate and revoke exposed credentials immediately Treat every confirmed exposure as active until proven otherwise. Revoke the credential, rotate dependent secrets, and verify that downstream services have switched to the replacement value.
- Replace persistent secrets with dynamic credentials Move cloud, database, and pipeline authentication toward short-lived credentials minted on demand so there is no reusable secret to leak from code or Git history.
- Map credential reach before compromise spreads Document which identities, tenants, and platforms each secret can reach, including GitHub Apps, cloud consoles, and CI/CD systems, so revocation priority reflects blast radius.
- Enforce least privilege for developer and machine access Reduce the permissions attached to tokens, keys, and service accounts so a stolen credential cannot become administrative control across unrelated systems.
Key takeaways
- AI-assisted secret hunting turns exposed credentials into a faster compromise path, which means discovery and revocation now need to operate as one control loop.
- The largest risk is not the leaked secret alone but the systems it can still reach, especially when one token exposes code, pipelines, and cloud administration.
- Organisations that still depend on persistent credentials should expect shorter exploitation windows and redesign around dynamic issuance and rapid invalidation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centers on exposed hardcoded secrets being discovered and exploited at scale. |
| NHI-07 — Long-Lived Secrets | Persistent credentials are the core weakness that AI-assisted hunting exploits. | |
| NHI-05 — Overprivileged NHI | The article shows one stolen token escalating into broad administrative access. | |
| Recommendation — Scan code, history, and packaged artifacts for leaked secrets and revoke exposed credentials immediately. Replace long-lived secrets with short-lived credentials wherever reuse or storage in code is possible. Reduce privilege on machine credentials so a stolen secret cannot become administrative control. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The campaign uses credential harvesting followed by pivoting into wider access. |
| Recommendation — Map secret-hunting activity to credential access and lateral movement indicators in threat detection. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential rotation and revocation are central to limiting the exposure window described in the article. |
| Recommendation — Apply authenticator lifecycle controls to rotate and revoke exposed credentials without delay. | ||
Key terms
- Hardcoded Secret: A hardcoded secret is a credential written directly into source code, scripts, configuration files, or build assets. It is convenient for development but dangerous in production because it can be copied, indexed, propagated, and reused outside the intended control boundary.
- Secrets Scanning: Automated tooling that scans source code repositories, CI/CD pipelines, and cloud environments to detect exposed secrets such as API keys, tokens, and passwords before they are exploited.
- Dynamic Secret: A secret generated on-demand for a specific task and automatically revoked after use or expiry. Dynamic secrets dramatically reduce the risk of credential exposure compared to static, long-lived secrets and are considered best practice.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
What's in the full article
Akeyless's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step setup for the GitHub Scanner inside Akeyless Identity & Secrets Intelligence
- Control-plane details for automated rotation, revocation, and audit logging after discovery
- Implementation notes for Dynamic Secrets, Universal Secrets Connector, and GitHub history coverage
- Runtime governance detail for AI agents that should not hold static credentials
👉 Akeyless's full post covers scanner setup, remediation flow, and runtime credential controls.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on September 22, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org