TL;DR: Anthropic’s September 2026 Threat Intelligence Report shows threat actors using AI to compress credential discovery, token abuse, and exfiltration, including a campaign that scanned 1.8 million Android apps for hardcoded secrets, according to Akeyless. Static secrets remain the weak point because discovery now scales faster than manual remediation. The problem is no longer finding leaks, but eliminating persistent credentials before they are weaponized.
At a glance
What this is: The article argues that AI has industrialized secret hunting, turning exposed credentials in code and Git history into a faster path to compromise.
Why it matters: This matters because IAM, NHI, and PAM teams now have to assume static secrets will be found quickly and govern for rotation, revocation, and short-lived access instead.
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
👉 Read Akeyless' analysis of AI-driven secret hunting and credential abuse
Context
AI-driven secret hunting changes the basic economics of credential exposure. What once required manual triage can now be run at scale across repositories, app packages, and leaked artifacts, which means exposed secrets in code are no longer a theoretical risk but a likely target for automated discovery.
For NHI governance, the key issue is not whether a secret was intended to be temporary. It is whether the organisation can inventory it, revoke it, rotate it, and prove that standing credentials are being removed before they become an easy entry point into cloud, source code, and identity systems.
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 AI coding tools increase governance risk for IAM and NHI teams?
A: AI coding tools increase governance risk because they obscure who created the logic, which identities executed it, and whether the resulting automation has the right access scope. That creates blind spots in auditability, approval authority, and secret handling. IAM and NHI teams need controls that can prove both the actor and the action.
Q: What are the signs that secret scanning is finding exposure but not actually reducing risk?
A: A common warning sign is when exposed secrets are detected repeatedly but remain valid for days or weeks. Another indicator is when teams can identify the leak but cannot confirm revocation, ownership, or scope quickly. If detection is outpacing remediation, the organisation is cataloguing risk instead of shrinking it.
Q: How should organisations reduce the chance that a stolen token becomes full cloud compromise?
A: Limit the token’s scope, reduce standing privileges, and move high-risk access to short-lived or just-in-time credentials. Stolen tokens become dangerous when they can pivot from one service into broader administrative access. The goal is to make the credential useless outside the exact task for which it was issued.
Technical breakdown
Why hardcoded secrets become high-value attack fuel
Hardcoded secrets are credentials embedded in code, build files, or artifacts where they can survive long after the original developer session ends. Once exposed, they create a durable authentication path that scanners, malware, and human attackers can all harvest. The technical problem is persistence: the secret remains valid even when the surrounding application changes, so the exposure window is measured in months or years, not minutes. In practice, this makes Git history, public repositories, and decompiled packages equivalent hunting grounds.
Practical implication: Treat code and Git history as credential-bearing surfaces, not just source-control records.
How AI changes secret discovery and token abuse
AI does not create the credential exposure, but it removes many of the bottlenecks in finding and exploiting it. Large-scale scanning can now classify repositories, parse unfamiliar environments, and accelerate the shift from discovery to exploitation by automating the steps between a found token and a usable session. In the article’s example, the attack chain moved from secret discovery to token creation, API use, and exfiltration quickly enough to outpace traditional manual review. That changes the defender’s timeline from days to hours.
Practical implication: Shorten detection and revocation workflows to match machine-speed credential abuse.
Why secret scanning alone does not close the exposure gap
Scanning tells you that a credential exists, but it does not invalidate the credential or remove the privilege attached to it. That distinction matters because a leaked token can still grant cloud, source-code, or CI/CD access after it is found. The control gap is operational closure: the environment needs rotation, revocation, replacement with short-lived access, and proof that the old credential can no longer authenticate. Without those steps, discovery merely produces a cleaner breach list.
Practical implication: Connect discovery to revocation and rotation, or the finding remains exploitable.
Threat narrative
Attacker objective: The attacker objective was to turn exposed credentials into privileged enterprise access quickly enough to steal data and expand control before defenders could react.
- Entry began with exposed hardcoded credentials, API keys, and authentication tokens discovered in code and app packages at scale.
- Escalation followed when stolen GitHub personal access tokens and other secrets were used to reach source code, CI/CD pipelines, cloud consoles, and privileged APIs.
- Impact came from rapid token abuse and exfiltration, including full cloud administrative control and large-scale data theft across multiple tenants and organisations.
Breaches seen in the wild
- MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
- Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Static secret persistence is now the core governance failure, not just a hygiene issue. The article shows that a secret embedded in code can remain usable long after deployment, which means the control failure is not discovery alone but prolonged credential validity. This is a classic NHI problem because the identity exists outside the human login flow and outlives the event that created it. Practitioners should treat secret lifetime as a governed risk, not an incidental implementation detail.
AI-driven secret hunting exposes an identity blast radius problem. Once one credential is found, the attacker can chain it into source code, CI/CD, cloud access, and then broader administrative control. That means the real governance question is not where the secret was stored, but how far it can travel once abused. The stronger the linkage between discovery and privilege scope, the smaller the blast radius practitioners can tolerate.
96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools. The implication is that the default enterprise state still assumes secrets will be scattered, which is exactly the condition automated attackers exploit. That statistic is not a niche outlier but an industry baseline for exposure. It confirms that governance programmes need inventory, rotation, and offboarding discipline across every place a secret can appear, not just inside a vault.
Persistent credentials are becoming incompatible with machine-speed attack paths. The campaign’s three-hour token-to-admin escalation shows that review cadences built for human-paced incidents are too slow when attackers can validate and weaponize a secret almost immediately. That does not just raise urgency, it breaks the assumption that defenders can react after discovery. Practitioners should design for short-lived access and rapid invalidation as the default operating model.
GitHub, app packages, and CI/CD are identity systems whether teams label them that way or not. The article demonstrates that these environments carry authentication material, privilege relationships, and downstream access paths. That makes them part of identity governance scope, not just software engineering scope. Security teams need to bring NHI controls into developer platforms before exposed credentials become a reusable attack primitive.
From our research:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which helps explain why exposed credentials so often go untracked.
- Use the NHI Lifecycle Management Guide to align discovery, rotation, and offboarding into one governed process.
What this signals
Identity blast radius: the practical challenge is no longer whether a secret exists, but how far a stolen credential can travel before it is invalidated. That makes exposure management a lifecycle problem, not a one-time detection problem.
The article also signals that GitHub, CI/CD, and app packages must be treated as governed identity surfaces. Teams that still separate developer tooling from identity control will keep discovering secrets after attackers have already operationalised them.
For practitioners
- Inventory exposed credentials across code and Git history Scan repositories, commit history, and packaged artifacts for API keys, tokens, service passwords, and certificates, then assign ownership for every finding before remediation begins.
- Rotate and revoke leaked secrets immediately Use automated rotation and revocation workflows for any exposed credential that can still authenticate, and verify that the old value no longer works across all connected systems.
- Replace persistent credentials with short-lived access Move cloud, database, and CI/CD access toward ephemeral credentials and identity-based authentication so there is less static material for attackers to steal from code.
- Tighten least-privilege on developer and automation identities Review the scope attached to GitHub Apps, PATs, service accounts, and pipeline identities, then reduce standing permissions that let a stolen token reach cloud administration paths.
- Link detection to proof of closure Track every secret finding through rotation, revocation, and revalidation, so the team can prove the credential was invalidated rather than merely discovered.
Key takeaways
- The article shows that AI is accelerating a familiar NHI failure mode, which is exposed credentials surviving long enough to be abused.
- The evidence points to a narrow defender window, because attackers can move from found secret to administrative access in hours rather than days.
- The control that changes outcomes is not scanning alone, but rapid revocation, rotation, and replacement with short-lived access.
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 CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Identity Inventory and Ownership | The article centres on exposed secrets and identity sprawl across repositories and tooling. |
| NHI-03 — Secrets and Credential Management | Hardcoded secrets and leaked tokens are the central attack surface in this article. | |
| NHI-05 — Overprivileged Non-Human Identities | The article shows stolen tokens becoming cloud admin access through excessive privilege. | |
| Recommendation — Inventory all machine identities and secret locations, then assign ownership before remediation closes. Eliminate hardcoded credentials and enforce rotation for every exposed secret. Reduce standing privilege on tokens and service identities so a stolen credential cannot escalate broadly. | ||
| MITRE ATT&CK | TA0006; TA0010 — Credential Access; Exfiltration | The attack chain is built on harvesting credentials and using them for data theft. |
| Recommendation — Map secret-harvesting activity to credential access and exfiltration techniques in detection and hunting. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorisations | The article focuses on narrowing what a stolen token can do once discovered. |
| Recommendation — Review access permissions for developer and automation identities and remove unnecessary authorisations. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Rotation, revocation, and authenticator lifecycle are central to the remediation model here. |
| Recommendation — Apply authenticator management controls to rotate, revoke, and replace exposed secrets quickly. | ||
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.
- 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.
- Secrets Rotation: Secrets rotation is the practice of replacing credentials on a schedule or after an event so exposed values stop working quickly. In NHI programmes, rotation must be tied to ownership and automation, otherwise credentials remain valid long after teams believe the risk has been addressed.
- Just-in-time tool access: Just-in-time tool access means granting a testing agent only the permissions it needs for a specific task and only for the time required. In offensive AI workflows, this limits the blast radius if the system behaves unexpectedly or reaches beyond its intended scope.
What's in the full article
Akeyless' full article covers the operational detail this post intentionally leaves for the source:
- How the GitHub Scanner is configured to inspect repositories, Git history, and identity relationships.
- How Akeyless connects discovery to rotation, Dynamic Secrets, and audit logging in one workflow.
- How the platform handles GitHub Apps, GitHub Targets, and policy-evaluated findings in the console.
- How SecretlessAI and Agentic Runtime Authority are positioned for AI agents that should not hold static credentials.
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on September 22, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
