Topic starter
22/09/2026 3:43 pm
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.
NHIMG editorial — based on content published by Akeyless: AI-driven secret hunting and the path from exposed credential to enterprise compromise
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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.
👉 Read Akeyless' analysis of AI-driven secret hunting and credential abuse →
Hardcoded secrets at machine speed: what IAM teams need to know?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
22/09/2026 3:43 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AI-driven secret hunting is shrinking the time to enterprise compromise
