AI-assisted coding is accelerating secrets sprawl and NHI risk

At a glance

What this is: This analysis shows how AI-assisted coding, MCP-style configuration patterns, and faster software delivery are amplifying hardcoded secret exposure across GitHub and adjacent collaboration systems.

Why it matters: IAM and NHI teams need to treat AI-driven development as an identity governance problem because the growth in secrets is happening faster than ownership, rotation, and remediation workflows can keep up.

By the numbers:

• 28.65 million new hardcoded secrets were added to public GitHub commits in 2025 alone, a 34% increase year over year.
• Public GitHub commits climbed to about 1.94 billion in 2025, up 43% year over year.

👉 Read GitGuardian's analysis of AI-assisted coding and secrets sprawl in 2025

Context

AI-assisted coding has turned more people and more systems into creators of production credentials, which makes secrets exposure a governance problem rather than a narrow developer hygiene issue. In NHI terms, every new service account, API key, token, certificate, or agent integration increases the number of identities that must be owned, monitored, and retired.

The article's core finding is that acceleration itself is now a security variable. Public code activity rose sharply in 2025 while hardcoded secrets rose even faster, and that pattern is typical of organisations that scale delivery before they scale identity controls. The same pressure shows up in MCP configuration, AI service access, and collaboration tools, where convenience-first setup patterns encourage credential sprawl.

Key questions

Q: How should teams reduce secrets exposure in AI-assisted development?

A: Start by treating AI-assisted development as a new source of credential creation. Remove hardcoded secrets from templates and sample configs, enforce secret manager use, and require owners for every service account, token, or API key. Then measure how quickly exposed credentials are rotated or revoked, because discovery alone does not reduce access risk.

Q: What is the difference between secrets scanning and secrets governance?

A: Secrets scanning finds exposed credentials. Secrets governance assigns ownership, defines scope, sets rotation and revocation rules, and proves that access has actually been removed. Scanning is a detection control, while governance is a lifecycle control. Organisations need both, but only governance reduces the chance that a discovered secret remains usable.

Q: Why do AI agents and MCP integrations increase IAM risk?

A: AI agents and MCP integrations increase IAM risk because they multiply the number of tool connections, service accounts, and tokens that can carry execution authority. If those credentials are embedded in configs or copied across workflows, the trust boundary moves into places that are hard to review. That makes least privilege and short-lived access much more important.

Q: Should organisations prioritise secret rotation or secret discovery first?

A: They should do both, but rotation is the control that reduces immediate exposure when a secret is already live. Discovery tells you where the problem is. Rotation and revocation tell you whether the credential still works. If you can only choose one urgent action after a leak, invalidate the credential and confirm it is no longer active.

Technical breakdown

Why AI-assisted development increases NHI secret sprawl

AI-assisted coding changes the rate at which credentials appear in code, configs, and collaboration tools. The risk is not that models create secrets on their own, but that they lower the friction of building integrations, adding services, and copying working patterns into new environments. That expands the number of places where service accounts, API keys, and tokens can be introduced without strong review. In NHI terms, the attack surface grows because each automated workflow adds another identity that needs lifecycle control, not just detection after the fact.

Practical implication: Practitioners should treat AI-assisted development as a source of new NHI issuance, not only a productivity tool.

MCP configuration files and hardcoded credentials

MCP, or Model Context Protocol, connects AI agents to tools and data sources. That makes its configuration layer sensitive because connection strings, API keys, and command-line arguments can become the de facto trust boundary for agent access. When quickstart guides normalize embedded credentials, teams inherit insecure defaults that spread quickly across repositories and internal tooling. The problem is architectural: credentials placed in config files are easy to copy, hard to inventory, and often reused beyond their intended scope. Once those patterns enter templates, they replicate at ecosystem speed.

Practical implication: Security teams should review MCP setup patterns before broad rollout and ban embedded secrets in reference configurations.

Why leaked secrets remain a long-tail identity problem

Secrets exposure is not just a discovery problem. A leaked secret can remain valid long after initial disclosure, which means old exposures continue to function as live access paths. That is why validation alone is incomplete. If teams cannot tie a secret to an owner, scope, expiration date, and revocation workflow, the credential behaves like standing privilege. In NHI governance, the real issue is lifecycle failure: issuance is easy, but retirement, rotation, and confirmation of revocation lag behind.

Practical implication: Use ownership and expiry controls so every secret has a clear revocation path, not just a scan result.

Threat narrative

Attacker objective: The attacker objective is durable access through reusable non-human identities that can be exploited across development and production systems.

1. Entry occurs when credentials are hardcoded into AI-assisted commits, MCP configs, or collaboration tools such as Slack and Jira, creating exposed access paths.
2. Escalation follows when compromised secrets remain valid across repositories, CI/CD runners, or developer machines, giving attackers persistent footholds into NHI-managed systems.
3. Impact comes from stolen tokens and keys being used to reach production services, automate access, or exfiltrate data through trusted integrations.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.

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 coding has become a secrets production system, not just a software production system. The article shows that faster development now creates more credentials, more integration surfaces, and more opportunities for secret leakage. That shifts NHI governance from a perimeter topic to a lifecycle topic. Practitioners should treat every AI-enabled workflow as a potential issuer of new identities and new access paths.

Ephemeral creation does not remove trust debt. Even when teams use short-lived patterns, the surrounding assumptions about ownership, scope, and revocation still determine whether access remains safe. If a secret is copied into a template, config file, or shared chat thread, it behaves like persistent privilege until it is retired everywhere. Security teams should measure the trust debt created by convenience-first development patterns.

MCP-style agent connectivity exposes a runtime governance gap: the control point moves from application code to configuration, where credentials are easier to embed and harder to govern. This is especially consequential for agentic systems because tools, data sources, and execution authority can be bound together in a single trust chain. Practitioners need policy controls that treat configuration as part of the identity plane.

Secrets sprawl is now a program management problem as much as a technical one. The article's evidence across public GitHub, AI service secrets, and collaboration tools shows that leaks originate in multiple workstreams, not one product area. That means ownership models, exception handling, and remediation SLAs matter as much as scanners. Teams should build governance around where secrets are created, not only where they are found.

Blast-radius control is becoming the decisive NHI security discipline. When new secrets appear faster than remediation can keep up, the priority is limiting what any one credential can reach. Least privilege, short TTLs, strict scoping, and revocation assurance become the controls that contain failure. Organisations that cannot bound blast radius will keep turning small leaks into large incidents.

From our research:

• Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to State of Secrets in AppSec.
• Our research also shows: The average estimated time to remediate a leaked secret is 27 days, even though 75% of organisations express strong confidence in their secrets management capabilities.
• For a broader prevention lens: Review Ultimate Guide to NHIs - 2025 Outlook and Predictions for how AI-driven identity growth changes governance priorities.

What this signals

Ephemeral credential trust debt: shorter-lived access only helps if ownership, scoping, and revocation are enforced consistently across development and runtime systems. With 43% of security professionals concerned about AI systems learning and reproducing sensitive information patterns from codebases, governance now has to cover both human workflow and machine reuse. That is why teams should align their secrets programme with the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10.

The operational signal is that remediation capacity is becoming a control surface of its own. If leaked secrets remain valid for weeks, then scanner coverage without revocation automation only documents exposure. Security programmes should build explicit ownership for NHI secrets, because the same tool sprawl that accelerates delivery also multiplies the number of credentials that need review, rotation, and retirement.

As AI-integrated workflows move from pilots to production, expect more security debt to originate in setup patterns rather than in overt attacks. That makes standardisation critical. Teams should consolidate secret storage, tighten template governance, and use workload identity where possible so the environment creates fewer reusable credentials in the first place.

For practitioners

• Inventory secrets by creation path Map where credentials enter the environment, including AI-assisted commits, MCP configs, CI/CD runners, and collaboration tools. Assign an owner and expiry expectation to each path so the team can see which workflows create the most risk.
• Ban embedded credentials in reference patterns Remove API keys and tokens from setup guides, templates, and sample files. Require environment variables, secret managers, or workload identity patterns instead of copying secrets into code or connection strings.
• Set revocation SLAs for exposed secrets Define time limits for rotating and invalidating secrets once exposure is detected. Track whether the credential is still valid after remediation so scans do not create a false sense of closure.
• Limit the blast radius of AI-linked access Scope AI service credentials to the smallest possible data set, tool set, and runtime. Use short-lived access where possible and separate production privileges from development workflows.

Key takeaways

• AI-assisted coding is increasing the number of non-human identities and credentials faster than many security programmes can govern them.
• Secrets sprawl is not limited to source code, because collaboration tools, CI/CD systems, and agent configurations now carry meaningful exposure.
• The practical response is lifecycle control: assign ownership, reduce standing access, shorten credential lifetimes, and verify revocation.

Key terms

• Non-Human Identity: A non-human identity is any credentialed entity that acts on behalf of software rather than a person. It includes service accounts, API keys, tokens, certificates, bots, workloads, and AI agents. These identities need ownership, scope, lifecycle management, and revocation just like human accounts.
• Secrets Sprawl: Secrets sprawl is the uncontrolled spread of credentials across code, infrastructure, and collaboration systems. It usually starts as convenience and ends as untracked access. In practice, it creates hidden trust paths that are difficult to inventory, rotate, or revoke quickly enough to reduce risk.
• MCP Configuration Risk: MCP configuration risk is the exposure created when Model Context Protocol settings contain embedded credentials or overly broad access parameters. Because MCP links agents to tools and data sources, weak configuration can turn a simple setup file into an access gateway with a large blast radius.
• Blast Radius: Blast radius is the amount of data, systems, or operations a single credential can reach if it is misused. In NHI governance, reducing blast radius means narrowing scope, shortening lifetime, and separating production privileges from development or testing access so a leak cannot cascade widely.

What's in the full report

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

• Repository-level breakdowns of where hardcoded secrets are most often introduced in public GitHub workflows
• AI service and MCP-related leak patterns that can help teams prioritise controls by integration type
• Longitudinal validity data showing how long exposed secrets continue to work after initial disclosure
• Examples of leakage outside code, including collaboration and project management tools where urgency drives exposure

👉 GitGuardian's full report covers the public GitHub, AI service, and MCP leak patterns in more operational detail.

Deepen your knowledge

Secrets lifecycle control and non-human identity ownership are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to govern AI-driven credential sprawl, it is a practical place to start.