AI-assisted coding is accelerating secrets sprawl and NHI risk

At a glance

What this is: NHI Mgmt Group's analysis, drawing on GitGuardian's research: AI-assisted development is amplifying secrets sprawl, with hardcoded credentials rising sharply alongside AI service secrets and broader GitHub activity.

Why it matters: IAM, PAM, and NHI teams need to treat AI-enabled development as a credential-governance problem, because faster software creation expands the number of secrets that can leak, persist, and be reused.

By the numbers:

• Public GitHub commits climbed to about 1.94 billion in 2025, up 43% year over year.

👉 Read GitGuardian's analysis of how AI-assisted coding is accelerating secrets sprawl

Context

AI-assisted coding is now a scale problem for identity governance, not just a productivity trend. When development speed rises faster than credential ownership, the number of places where non-human identities and secrets can be created, copied, embedded, or forgotten expands faster than control planes can keep up.

The core issue is not that AI creates secrets by itself. The issue is that AI-driven workflows increase the number of integrations, service accounts, configuration files, and collaboration paths where credentials can be handled informally. That turns secrets sprawl into an NHI governance problem across code, tooling, and operational channels.

GitGuardian's data suggests that the underlying failure mode is familiar, but the pace is new. Teams are shipping faster, using more AI-enabled tooling, and exposing more credentials across more surfaces before lifecycle control, ownership, and remediation processes have adapted.

Key questions

Q: What breaks when AI-assisted development outpaces secret governance?

A: When development speed outruns ownership, secrets stop behaving like controlled credentials and start behaving like unmanaged access residue. The result is more hardcoded secrets, more leaked AI service credentials, and more valid tokens that persist after exposure. Governance breaks because discovery is happening after the secret has already moved through too many systems.

Q: Why do leaked secrets remain such a persistent NHI risk?

A: Leaked secrets persist because they are often embedded in code, pipelines, or collaboration tools, then left valid long enough for reuse. The real problem is not only exposure but weak identity lifecycle management, especially when ownership, rotation, and revocation are not tightly governed.

Q: What are the warning signs that secrets sprawl is becoming a control failure?

A: Watch for credentials appearing outside source control, especially in collaboration tools, MCP-related configuration files, local developer environments, and CI/CD runners. A rising count of valid secrets, repeated use of embedded API keys, and slow remediation of known exposures all indicate that the organisation is losing control of secret lifecycle.

Q: Should teams prioritise secret discovery or secret lifecycle governance first?

A: Discovery is necessary, but lifecycle governance should be treated as the primary control objective when exposed secrets remain valid. If ownership, rotation, and revocation are not defined, scanning only creates a backlog of unresolved access paths. The better question is whether your remediation process can outpace how fast secrets are created.

Technical breakdown

Why AI-assisted development increases secrets exposure

AI-assisted coding shortens the distance between idea, implementation, and deployment. That acceleration increases the number of ephemeral edits, generated snippets, copied examples, and integration steps where credentials can be hardcoded or pasted into the wrong place. In identity terms, every new tool or workflow adds more non-human identities, more authentication material, and more opportunities for secret reuse. The risk is not limited to code generation. It extends to the surrounding development stack, including CI/CD, local environments, and config management, where credentials often move informally before they are governed.

Practical implication: Treat AI-assisted software delivery as an expansion of the secret-bearing surface, not just a coding efficiency gain.

Why MCP-related configurations and AI service secrets matter

Model Context Protocol configurations, AI wrappers, gateways, and orchestration layers often need API keys, tokens, and connection strings to function. That makes them high-friction zones for credential handling because the setup instructions themselves may encourage unsafe storage patterns. Once a secret is embedded in a configuration file or command line argument, it becomes part of the identity boundary for that service, agent, or integration. In practice, this means AI infrastructure is not only consuming identity, it is creating new places where identity material can leak through convenience-first deployment patterns.

Practical implication: Review AI infrastructure onboarding paths for where secrets are introduced, not just where they are later stored.

Why public leaks are only the visible edge

Public GitHub is a useful signal, but it is not the whole reservoir. Internal repositories, collaboration tools, developer laptops, and CI/CD runners often hold a much larger body of exposed secrets, and those credentials can remain valid long after disclosure. That matters because the governance problem is cumulative: a secret may appear once in code, then again in Slack, then again in a config file, with no single owner taking responsibility for its full lifecycle. This is why secrets management and NHI governance have to be treated as the same operational discipline across environments.

Practical implication: Build inventory and remediation around where secrets actually live across the lifecycle, not only where scanners are most convenient.

Threat narrative

Attacker objective: The attacker wants reusable non-human credentials that outlive the original leak and can be used to reach additional systems, services, or software supply chain paths.

1. Entry begins when secrets are hardcoded into public GitHub commits, AI tooling configuration, collaboration channels, or local development environments during rapid software creation.
2. Credential access follows when attackers harvest exposed API keys, tokens, and service credentials from repositories, logs, workstation artifacts, or third-party package disclosures.
3. Escalation occurs when those credentials still validate, are reused across systems, or provide access to internal services and CI/CD infrastructure.
4. Impact is achieved when the stolen secrets enable broader compromise, supply chain abuse, or persistence across developer and production environments.

Breaches seen in the wild

• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
• 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.

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-assisted coding has turned secrets sprawl into a governance scaling problem. The central change is not just more code, but more identities, more integrations, and more places where credentials can be introduced faster than they can be owned. That means the control failure is no longer isolated leakage, it is programme-level inability to keep pace with creation. Practitioners should read this as an identity lifecycle issue, not a developer hygiene issue.

Ownership is the missing control plane for NHI risk. A secret without a named owner, rotation expectation, and offboarding trigger is effectively a dormant access path waiting to be reused. GitGuardian's findings show that the environment is producing more secrets than governance can classify, which is why discovery alone does not reduce exposure. The practitioner conclusion is that every secret-bearing system needs accountable lifecycle ownership.

Hardcoded secret exposure is now a cross-channel identity problem. The report's attention to Slack, Jira, Confluence, and developer endpoints matters because it shows credentials flowing outside repositories where traditional code scanning is weakest. That widens the blast radius of NHI governance failures beyond source control. The implication is that secrets management has to align with operational collaboration habits, not only with source code policy.

Secrets sprawl is becoming a form of identity drift. The number of valid credentials that remain active long after exposure demonstrates that the issue is not just leak detection, but persistence of access. This is where lifecycle governance and remediation cadence become decisive. Practitioners should measure how many exposed secrets remain live, not just how many were found.

Runtime convenience is now outpacing preventive control design. The article points to a broader market pattern: AI development stacks normalize fast onboarding and embedded credentials before governance standards harden. That creates a recurring gap between how teams build and how identities are controlled. The practical takeaway is that NHI governance must move upstream into configuration patterns, setup guidance, and provisioning defaults.

From our research library:

• 8 of the top 10 fastest-growing types of leaked secrets year-over-year are tied directly to AI services, according to the State of Secrets Sprawl 2026.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Secrets sprawl is now being accelerated by AI tooling, not just by sloppy storage habits. The practical shift for programmes is that setup guides, embedded examples, and developer shortcuts are becoming credential creation events. Teams need to review onboarding paths, not just scan repositories.

Identity ownership has to extend beyond repositories. The article's focus on Slack, Jira, Confluence, and developer endpoints shows that secrets governance fails when it assumes code is the only place where credentials live. A stronger programme treats every collaboration surface as a potential non-human identity boundary.

For practitioners

• Map secret-bearing surfaces across the development lifecycle Inventory where credentials appear in repositories, CI/CD, collaboration tools, local workstations, and AI-related configuration files before you tune remediation priorities.
• Assign accountable owners to every non-human credential Tie each secret to a business or technical owner, a rotation expectation, and a revocation path so no exposed credential survives as an orphaned access path.
• Audit AI setup paths for hardcoded credential patterns Review quickstarts, templates, and onboarding documents for API keys, tokens, command-line arguments, and embedded connection strings that normalize unsafe handling.
• Prioritise remediation by exposure plus validity Do not rank leaked secrets only by discoverability; focus first on credentials that are confirmed valid, broadly reusable, or tied to privileged services.
• Extend NHI controls into collaboration channels Treat Slack, Jira, and Confluence as credential-bearing environments and apply the same logging, redaction, and response discipline used for code repositories.

Key takeaways

• AI-assisted development is widening the gap between credential creation and credential control, which makes secrets sprawl a programme-level issue.
• The scale is no longer abstract: millions of new hardcoded secrets and rapidly growing AI service credentials show that exposure is increasing with software velocity.
• The limiting factor is lifecycle governance, because ownership, rotation, and revocation determine whether a leaked secret becomes a lasting access path.

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.
• 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.
• Non-Human Identity Lifecycle: The Non-Human Identity Lifecycle is the full sequence of creation, use, control, review, and retirement for identities that are not tied to a person. It covers service accounts, API keys, certificates, tokens, bots, and AI agents, including issuance, rotation, monitoring, revocation, and secure decommissioning across systems and environments.
• Credential Blast Radius: Credential blast radius is the amount of access, data, and system reach that a single compromised secret can unlock. The wider the blast radius, the more damage one leaked token or certificate can cause. Reducing it requires tighter scope, faster revocation, and better segmentation.

What's in the full report

GitGuardian's full report covers the operational detail this post intentionally leaves for the source:

• Breakdowns of leaked secrets by environment, including public GitHub, internal repositories, collaboration tools, and developer workstations
• Evidence on how AI service secrets and MCP-related configuration leaks are changing the composition of exposed credentials
• Validation data showing how long previously exposed secrets remain active and exploitable over time
• Examples of the setup and workflow patterns that normalize hardcoded credentials in AI development stacks

👉 The full GitGuardian report covers the secret types, exposure paths, and remediation gaps behind the trend

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.