AI-driven secrets sprawl is outpacing NHI governance controls

At a glance

What this is: NHI Mgmt Group's analysis, drawing on SSH Communications Security's blog post: AI development is accelerating secrets sprawl and exposing gaps in NHI governance, with GitGuardian data showing 28.65 million new hardcoded secrets in 2025.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern machine credential lifecycles across code, collaboration tools, AI services, and cloud workflows, not just hunt exposed secrets after the fact.

Context

AI-assisted development is expanding the number of machine credentials faster than traditional governance models can track them. A secrets problem becomes an identity problem when every AI service, workload, pipeline, and integration creates another credential that must be owned, rotated, revoked, and audited.

The control gap is not discovery alone. In this environment, secrets can surface in repositories, collaboration platforms, and operational tooling outside the places many teams still monitor first, which means lifecycle governance has to extend beyond code scanning and into the operational identity layer.

Key questions

Q: What breaks when secrets are allowed into AI development workflows?

A: Secrets stop behaving like isolated credentials and start behaving like replicated content. AI tools can copy them into prompts, histories, logs, and generated code, which multiplies the cleanup surface and extends exposure beyond the original system. The practical failure is propagation, not just disclosure.

Q: Why do leaked service credentials remain dangerous after they are discovered?

A: They remain dangerous because exposure and invalidation are separate events. If the secret still authenticates, an attacker can use it immediately, and the organisation’s delay in revocation determines how much access and lateral movement remains available.

Q: What happens when secrets and machine identities are left unmanaged in AI and cloud environments?

A: Unmanaged secrets expand the attack surface and make compromise harder to detect. When credentials remain valid for long periods, attackers can access sensitive data, abuse automation, and persist across environments. The operational consequence is slower incident response, broader blast radius, and higher chance that one exposed token becomes a multi-system security event.

Q: What is the difference between secrets detection and NHI governance?

A: Secrets detection finds exposed credentials, while NHI governance tracks how those credentials are issued, reused, rotated, and retired. Detection answers whether a secret is visible. Governance answers whether the identity behind that secret is controlled throughout its lifecycle. Mature programmes need both because exposure without lifecycle control leaves the same risk open.

Technical breakdown

Why secrets sprawl outgrows static credential models

Static secrets assume a relatively stable application estate, with credentials issued, stored, and rotated on a slow administrative cadence. AI-assisted development breaks that assumption by multiplying service accounts, API keys, and workload credentials across ephemeral projects and integrations. The result is not just more secrets, but more places where ownership, expiration, and revocation can fail. For NHI governance, the technical issue is that identity creation now happens faster than identity administration can reliably track. Practical implication: move from repository-centric secret hunting to inventory-driven control over machine identity lifecycle.

Practical implication: inventory machine identities first, then govern issuance, ownership, and revocation as a lifecycle problem.

Why secrets also appear outside source code

The article notes that a material share of secret exposure now sits in Slack, Confluence, and other collaboration systems rather than in code repositories alone. That matters because many detection programs still treat source code as the primary containment boundary, even though developers increasingly pass tokens, connection strings, and operational credentials through adjacent work tools. Once secrets travel through chat and documentation systems, simple repository scanning no longer captures the full exposure surface. Practical implication: extend monitoring and remediation workflows to collaboration platforms, not just Git platforms and CI/CD.

Practical implication: monitor collaboration tooling as part of the secrets estate, not as a separate communications problem.

Why identity-based authentication changes the control model

The article's shift toward cryptographically verifiable workload identities reflects a deeper architectural change. Instead of protecting long-lived shared secrets, identity-based authentication issues short-lived credentials to an attested machine identity at the point of need. Frameworks such as SPIFFE and SPIRE support that model by separating workload identity from reusable static credentials. This does not eliminate governance requirements, but it changes where control must live: at issuance, attestation, and policy enforcement rather than after storage. Practical implication: design controls around ephemeral credential issuance and workload attestation, not only secret vaulting.

Practical implication: place control at credential issuance and attestation, not only in vault storage.

Threat narrative

Attacker objective: The attacker wants durable access to AI, cloud, and development systems through secrets that still work after exposure.

1. Entry occurs when hardcoded secrets, API keys, or tokens are embedded in public commits, collaboration tools, or exposed internal repositories.
2. Credential access follows when attackers or opportunistic insiders obtain working secrets that have not been revoked or rotated after exposure.
3. Escalation happens when those credentials authorize AI services, cloud workloads, or CI/CD systems with more access than the original leak implied.
4. Impact is persistent access to cloud and AI environments through credentials that remain valid long after the initial disclosure.

Breaches seen in the wild

• PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.
• Twitch breach 2021: A server misconfiguration leaked Twitch source code and payouts; the repositories held nearly 6,600 secrets, including 194 AWS keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI development is turning secrets sprawl into an identity governance problem, not just a detection problem. The article's central finding is that machine credential creation is accelerating as teams build faster with AI services, cloud integrations, and ephemeral workflows. That changes the control objective from finding secrets to governing the lifecycle of the identities behind them. Practitioners should treat secrets volume as a symptom of deeper identity sprawl.

Secrets exposed outside code repositories are a governance failure, not an edge case. When credentials move into Slack, Confluence, and similar collaboration systems, the security model has already expanded beyond source control. That breaks the assumption that repository scanning captures the full risk surface. The practical lesson is that secrets governance must follow the workflow, not the codebase.

Identity-based authentication is becoming the default answer to machine credential overload. Short-lived credentials issued to attested workloads reduce the need for static secrets in the first place. That does not remove governance, but it shifts it toward ownership, attestation, and policy enforcement at the point of access. Practitioners should expect secrets management to become a narrower control inside a broader NHI governance programme.

Static secrets are no longer compatible with AI-scale software delivery. Traditional vault-centric models were built for slower application change and clearer asset ownership. AI-assisted development creates many more machine identities than those models were designed to absorb, which means review cycles, rotation workflows, and offboarding practices all become backlog items rather than safeguards. The implication is a programme redesign, not a tooling tweak.

Ephemeral credential trust debt is the right way to describe this trend. Every hardcoded secret or long-lived token creates deferred risk that persists after the initial exposure event. The longer organisations wait to revoke or replace those credentials, the more they accumulate trust debt across development, AI, and cloud operations. Practitioners should measure exposure as outstanding access, not as discovered secrets alone.

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.
• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks, according to the State of Secrets Sprawl 2026.
• Read next: Ultimate Guide to NHIs

What this signals

Ephemeral credential trust debt: every leaked or long-lived machine credential creates residual access risk that persists until ownership, rotation, and revocation are proven, not assumed. In AI-heavy environments, that debt accumulates faster than the traditional secrets workflow can retire it.

Governance teams should stop treating secrets as isolated developer mistakes. The operational question is whether machine identities have a lifecycle at all, because without one, detection only documents the blast radius after access has already escaped normal control.

The shift toward attested workload identities is less about replacing one tool with another and more about changing the control point. If access is issued just in time and tied to verified workload identity, the programme can reduce the pool of reusable secrets that attackers can later find or reuse.

For practitioners

• Inventory machine identities across AI workflows Create a live inventory of service accounts, API keys, tokens, and workload credentials used by AI services, CI/CD pipelines, and cloud integrations. Record ownership, purpose, and expiry so that governance can follow the identity, not just the repository where it was first found.
• Expand secrets monitoring beyond code repositories Include Slack, Confluence, Jira, and other collaboration platforms in detection and remediation workflows. Treat any channel where credentials are shared as part of the governed secrets estate, because leaks outside code can remain valid and harder to spot.
• Replace long-lived machine credentials with short-lived issuance Move high-value integrations toward attested workload identities and just-in-time credential issuance so reusable secrets are removed from steady-state operation. Use policy to constrain who or what can request access, and ensure access disappears when the task ends.
• Tie rotation and revocation to ownership records Require every non-human credential to have a named owner, a documented purpose, and a revocation path. If a secret cannot be tied to an accountable service or workload, treat it as an orphaned control gap rather than a harmless artifact.

Key takeaways

• AI-driven development is increasing the number of machine credentials faster than traditional secrets programmes can reliably govern.
• The article's evidence shows that exposure is not confined to source code, which means collaboration tools and operational workflows now sit inside the secrets risk surface.
• The practical response is to govern machine identity lifecycle and short-lived access, because detection without revocation leaves active risk in place.

Key terms

• 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.
• Machine identity lifecycle: Machine identity lifecycle is the full governance process for a non-human identity from creation to retirement. It includes provisioning, access scoping, rotation, renewal, offboarding, and auditability, and it fails when any one of those steps is handled manually or inconsistently.
• Identity-Based Authentication: Identity-based authentication verifies a specific person or subject rather than a pooled credential. In shared environments, it preserves accountability by keeping access tied to the individual even when the resource, workstation, or application is used by many people.
• Ephemeral Credentials: Ephemeral credentials are short-lived access artefacts issued for a limited task or session. They reduce the window for abuse, but they only improve security when paired with strong scope limits, telemetry, and automatic revocation at task completion.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.