AI-driven secrets sprawl is outpacing NHI governance controls

At a glance

What this is: AI-assisted development is multiplying machine credentials faster than security teams can govern them, with public and internal secrets exposure outpacing remediation.

Why it matters: IAM, IGA, PAM, and NHI teams now have to treat secrets sprawl as an identity governance problem, not just a developer hygiene issue.

By the numbers:

• 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.
• Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.

👉 Read SSH Communications Security's analysis of AI-driven secrets sprawl and NHI governance

Context

AI-assisted development is expanding the number of non-human identities faster than conventional governance models can track. Every API integration, AI workflow, cloud connection, and CI/CD pipeline introduces credentials that must be owned, scoped, monitored, rotated, and revoked.

The core failure is not visibility alone. It is the gap between discovery and remediation, where exposed secrets remain valid long after they are found and where private repositories and collaboration tools hide more exposure than many teams expect.

Key questions

Q: How should security teams handle leaked secrets once they are found?

A: They should treat detection as the start of response, not the end. The right sequence is to confirm whether the secret is valid, revoke or rotate it immediately, review where else it may have been copied, and verify that access paths tied to it are closed. Discovery without revocation leaves the identity usable and the risk intact.

Q: Why do private repositories still create secret exposure risk?

A: Private repositories still create risk because source files often contain reusable credentials, tokens, build artefacts, and internal package references. If a repository was public even briefly, those details may already be indexed or cached elsewhere. The governance problem is not only access control on GitHub, but whether any downstream system can still surface what was exposed.

Q: What do teams get wrong about secrets scanning at scale?

A: They treat scanning as the control instead of one input to lifecycle governance. At scale, the harder problems are ownership, rotation, revocation, and central inventory. A tool that finds secrets but cannot support remediation prioritisation still leaves governance gaps unresolved.

Q: How do organisations move from secrets management to identity-based authentication?

A: They replace embedded long-lived credentials with cryptographically verifiable workload identities that can obtain short-lived access on demand. That approach reduces dependence on static secrets, but it also requires tighter lifecycle governance for machine identities, including issuance, attestation, rotation, and retirement.

Technical breakdown

Why static secrets fail in AI-driven delivery

Static secrets are long-lived credentials that stay valid until someone rotates or revokes them. In modern software delivery, they are embedded in code, pipelines, chat tools, and configuration files, which makes them difficult to inventory and even harder to retire on time. AI-assisted development increases the number of places secrets can appear, while also increasing the number of machine identities that depend on them. The result is a control model built for low-change environments trying to govern high-churn identity populations.

Practical implication: map where static credentials exist before trying to improve rotation cadence.

Why discovery without revocation leaves exploitable identity residue

Secret scanning finds exposed credentials, but that does not change whether the secret still works. If the token, API key, or certificate remains valid, an attacker can reuse it long after the original exposure. This is why leaked secrets become identity residue: evidence of compromise that remains operational. In NHI governance terms, the problem is not just leakage. It is persistence of authority after exposure, which is exactly what makes these incidents difficult to contain.

Practical implication: treat revocation latency as a security control, not a cleanup metric.

Why identity-based authentication is replacing embedded secrets

Identity-based authentication shifts control from shared, static credentials to short-lived, verifiable workload identities. Standards such as SPIFFE and SPIRE support this pattern by issuing attestable identity to workloads so they can request credentials just in time rather than carrying long-lived secrets everywhere. This reduces the blast radius of exposure and makes access more policy-driven. It does not remove identity governance work, but it changes the object of control from the secret itself to the lifecycle of the machine identity.

Practical implication: prioritise workload identity patterns where systems can eliminate embedded secrets rather than rotate them forever.

Threat narrative

Attacker objective: The attacker objective is to reuse still-valid machine credentials to reach cloud, pipeline, or AI service access that defenders no longer actively control.

1. Entry occurs when hardcoded secrets are exposed in public GitHub commits, internal repositories, or collaboration tools such as Slack and Confluence.
2. Escalation follows when leaked credentials remain valid, allowing reuse of machine access across AI services, pipelines, and cloud workloads.
3. Impact is credential reuse at scale, with attackers gaining persistent access to systems that teams believe have already been remediated.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• CI/CD pipeline exploitation case study — full server takeover via exposed .git directory and mismanaged CI/CD pipeline secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI-assisted development is creating identity sprawl faster than secrets governance can absorb. The article's numbers show that the problem is not a single leak class but a rapidly expanding credential surface tied to AI services, orchestration layers, vector databases, and retrieval systems. That changes NHI governance from a repository hygiene problem into an enterprise identity inventory problem. Practitioners should stop treating machine credentials as incidental artefacts and start treating them as governed identities.

Secret discovery without revocation is an operational illusion. The report's finding that leaked secrets remain valid long after exposure exposes a broken assumption in many programs: that detection materially reduces risk on its own. It does not. When credential authority outlives exposure, the governance failure is persistence, not visibility, and the implication is that remediation latency is now a control measure in its own right.

Static secrets are the wrong control object for AI-era workloads. Traditional vault-centric thinking assumes credentials can be managed as durable assets, but AI workflows and cloud-native delivery now create machine identities that are too numerous and too dynamic for that model. Identity blast radius: the practical unit of control is no longer the secret, but the scope and lifetime of the machine identity behind it. Teams need to govern ownership, access scope, and expiry as first-class identity properties.

Private infrastructure is not a safe container for unmanaged credentials. The report shows internal repositories and collaboration platforms can hold more exposure than public code, which means the old boundary between development and enterprise governance has collapsed. NHI policy, developer workflows, and collaboration tooling now form one control plane. Security leaders need to align secrets governance with the actual places credentials move, not the places teams prefer to monitor.

Identity-based authentication is the direction of travel, but it is also a governance reset. Moving to cryptographically verifiable workload identity changes the problem from protecting a secret to managing a lifecycle. That affects IAM, PAM, and NHI programs alike because the control emphasis shifts to issuance, attestation, short-lived access, and revocation discipline. The practitioner implication is clear: the future control model governs identities that can prove themselves, not credentials that merely persist.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, 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, showing the exposure problem is accelerating rather than stabilising.
• That is why Guide to the Secret Sprawl Challenge is the right next resource for teams trying to move from discovery to containment.

What this signals

Identity sprawl is now a programme-level issue, not a point-in-time leakage problem. When AI services and cloud workflows create credentials faster than teams can own them, the operational question shifts from where secrets are stored to who is accountable for their lifecycle. That is a governance redesign problem, not a tool tuning problem.

Secret exposure outside code changes the control surface. If Slack, Confluence, and other collaboration systems are part of the exposure path, then secret discovery must extend beyond repositories and build systems. Teams that do not widen monitoring will keep undercounting risk and overestimating their containment capability.

Machine identity controls will increasingly be judged by how quickly they can remove authority after exposure, not by how many secrets they can inventory. That is where lifecycle discipline, short-lived credentials, and workload identity patterns become the practical measures of maturity.

For practitioners

• Inventory machine credential locations across all development surfaces Build a single view of secrets in source control, CI/CD, collaboration tools, and cloud configuration so the team can see where machine credentials actually live.
• Measure revocation latency as a core security metric Track the time between secret exposure and revocation, then report it alongside detection coverage so stale credentials are treated as an active risk rather than a housekeeping issue.
• Replace embedded secrets with workload identity where possible Prioritise systems that can use attested workload identity and short-lived credentials instead of long-lived shared secrets, especially in pipelines and AI infrastructure.
• Tighten ownership for every non-human identity Assign each API key, token, certificate, and service credential to a named system owner with explicit expiry, rotation, and offboarding responsibility.
• Expand scanning beyond code repositories Include Slack, Jira, Confluence, and similar collaboration systems in secret discovery because exposure outside code is both common and more likely to be critical.

Key takeaways

• AI-assisted development is amplifying non-human identity sprawl faster than most security programmes can govern it.
• Discovery is not containment when leaked credentials remain valid for months or years after exposure.
• Teams need lifecycle control, workload identity, and faster revocation if they want secrets risk to decline rather than accumulate.

Key terms

• Static Secret: A secret — such as an API key or password — that does not change automatically over time. Static secrets require manual or scheduled rotation and represent a higher security risk than dynamic secrets or managed identities.
• Workload Identity: The identity assigned to a software workload — such as a containerised application, serverless function, or microservice — enabling it to authenticate to other services without storing static credentials.
• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials — API keys, tokens, passwords, certificates — across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
• 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

SSH Communications Security's full article covers the operational detail this post intentionally leaves for the source:

• How the report breaks down secrets exposure by environment type, including public code, internal repositories, and collaboration tools.
• The detailed reasoning behind identity-based authentication and why static secrets no longer scale in AI-heavy delivery pipelines.
• Practical discussion of SPIFFE and SPIRE as workload identity building blocks for replacing embedded credentials.
• The vendor's own framing of how NHI governance changes when AI-assisted development expands the machine identity surface.

👉 SSH Communications Security's full article covers the exposure data, remediation framing, and identity-based authentication shift.

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.