Software production is scaling to tens of billions of commits a year, and every application, integration, and AI agent adds another credential that security teams have to find, judge, and govern. A complete map of that credential population is the first thing an organization needs before it can rotate, revoke, or stop risky exposures from spreading.
Why the credential layer is growing so quickly
Code volume and credential volume are moving in the same direction, and credential volume is moving faster. GitHub’s COO described a jump from roughly 1 billion commits during all of 2025 to 2.9 billion commits by August 2026, an annualized pace above 14 billion for 2026. GitHub’s engineering team has gone further in capacity planning, moving from designing for 10x scale to preparing for a 30x future as agentic development accelerates. Every new application, every automation, and every AI integration creates another system that has to authenticate to something else, so the credential layer keeps expanding well past the perimeter a traditional security program was sized to cover.
What does the credential layer actually look like?
The credential layer is the whole population of secrets connecting people, applications, infrastructure, and services across an enterprise. Its perimeter follows the credentials themselves rather than the network. A developer will create a secret inside a sanctioned cloud account, then the same key will appear in plaintext inside a repository or a shared workspace. A copy may sit in an approved vault while another plaintext copy remains on the developer’s laptop. More secrets are created outside the security team’s normal vantage point through personal projects or newly adopted AI services, including work done by citizen developers who now have access to coding agents.
GitGuardian’s State of Secrets Sprawl 2026 research puts a number on how wide this surface has become. Internal repositories were roughly six times more likely than public repositories to contain at least one secret. Around 28% of secrets incidents originated entirely outside source-code repositories, inside collaboration and productivity tools.
Which surfaces contain credentials today?
Each system a security program watches shows only the part of the credential layer it can see, so organizations still need a way to combine those partial views into one inventory.
Source control
Source control remains essential because hardcoded credentials leave durable evidence. A credential removed from the current version of a file can stay in git history. Copies can spread to other branches or other repositories. Public exposure can put the value beyond the organization’s control, which makes immediate notice extremely difficult.
Internal repositories
Internal repositories hold a second large population. They contain the credentials developers and applications use during normal work, including access to cloud environments and internal services.
Collaboration systems
Collaboration tools expose a third part of the credential layer. Credentials get pasted into tickets while troubleshooting. They move through chat during handoffs. They can remain searchable long after the work that required them is finished.
Developer endpoints
Developer machines accumulate more secrets than almost any other surface. Until recently, it was normal practice to keep application secrets in local environment files and to let command-line tools cache credentials for cloud services. The danger of an unscrubbed local shell history, which can preserve values long after someone has forgotten they were entered, was treated as low.
The end of 2025 changed that. New waves of infostealer attacks, including Shai-Hulud and S1ingularity, turned the developer laptop into a target and an entry point into the supply chain. Every laptop is now part of the credential layer, and the secrets on those machines need to be mapped just like the ones in a vault.
What do attackers already know about this surface?
Attackers have already adapted to the fact that credentials live across managed and unmanaged environments. Compromised credentials accounted for 22% of initial access in the 2026 Verizon Data Breach Investigations Report. The same research connected corporate credentials on unmanaged devices to a significant share of the breaches studied, and the reporting period ended before the infostealer worms seen in early 2026 became widespread.
Self-propagating malware running on an endpoint can search browser data, local files, and application storage. It can collect whatever authentication material is available without caring which team created it or which security product was supposed to govern it. Developer systems are especially valuable targets because a developer machine may authenticate to source control and cloud infrastructure and may also hold local credentials for applications under development. Compromising that endpoint can expose access that spans several otherwise separate parts of the enterprise.
What changes when AI agents sit on the developer laptop?
The developer endpoint has always accumulated credentials because building software requires connecting systems. Now a new type of internal actor has access to that same machine. Coding agents can read files, execute commands, and interact with external services. Model Context Protocol connections can give those agents access to additional tools, and each connection introduces another place where authentication and authorization need to be established.
GitGuardian’s analysis of systems compromised during the Shai-Hulud 2 supply-chain campaign offers a rare view into the density of credentials on these machines. Across 6,943 compromised systems, researchers identified 33,185 unique secrets. Forty-four percent of compromised machines held more than 10 secrets, while 5% contained more than 100. A separate analysis found 24,008 unique secrets in public MCP configuration files during 2025, of which 2,117 could be verified as valid.
A security team that scans repositories can know a great deal about repositories. It still has limited visibility into the credentials living on the machines where code is created, tested, and connected to external systems. Agents can also take unexpected actions with that access on their own, from accidentally deleting a production database to handing a foothold to an attacker, which is why the inventory has to extend to endpoints as well as code.
What context does each credential actually need?
Finding a secret gives the first coordinate. Security teams need the surrounding context to understand the risk it represents.
- Validity. Most secrets stay valid far longer than they should. Ideally a credential would be made just in time and expire after use, but GitGuardian retested credentials confirmed valid in 2022 and found that 64% were still valid in January 2026. A credential can remain useful to an attacker years after the original exposure.
- Location and spread. A credential found once in an internal repository has one exposure history. The same credential appearing on a laptop and later in a public repository has traveled much farther. Credential fingerprinting can connect those appearances while keeping a single credential record, so seven detections of the same secret count as one credential with seven known exposures.
- Ownership. Security teams need to know which user, workload, or application relies on the credential, the team that owns the access, and the governance that applies.
- Permissions. A credential limited to a development service carries one level of danger, and a production credential with broad administrative permissions carries another. Validity and permission scope together show which findings deserve the fastest attention.
- Dependencies. A credential can be highly exposed while still supporting critical workloads. Mapping each credential to the services and systems that depend on it shows the blast radius before a rotation, and shows which downstream consumers will break if the credential is revoked.
How does discovery turn into a usable inventory?
Vault coverage, repository findings, and endpoint discoveries combine into an inventory of credentials the security team can act on. Detection builds the map that rotation and revocation both depend on.
Many enterprises already run strong secrets-management programs. Those systems describe the credentials already under management: what is stored, who has access, and how the secret is being used. The larger credential-layer mapping shows how complete that coverage really is. A company might hold 50,000 credentials in approved vaults while thousands more sit in plaintext across repositories, developer endpoints, and collaboration systems. Vault reporting accounts for the secrets the program knows about and stays blind to the ones created outside the paved path. Some of those outside secrets may duplicate values already held in the vault. Others may exist entirely outside any approved manager.
What is the time pressure on this work?
Software production is not the only thing speeding up. GitGuardian’s research shows that, over the period they have been studying the area, secret exposure has grown 1.6 times faster than the number of active developers. Attackers are accelerating along the same curve. CrowdStrike measured an average eCrime breakout time of 29 minutes in 2025, with the fastest observed case reaching lateral movement in 27 seconds. Defenders need to react at machine speed, since human-paced attacks are no longer the bottleneck. The answer is faster reaction paired with a move toward prevention, and that shift is not possible until the organization knows which surfaces its credentials can leak into today.
What should a security team do first?
The first step in controlling credential risk is understanding the credential layer the organization actually has. That requires discovery across repositories, public exposure, and developer endpoints, and it requires context around every credential, including validity, ownership, permissions, and dependencies. GitGuardian’s approach to that work runs through three connected stages: Detect, Remediate, and Prevent, and the inventory built during detection is what the next two stages run on.
The growth already underway raises the cost of waiting. GitHub’s move from 1 billion annual commits to a pace measured in hundreds of millions per week is a glimpse of the software volume ahead. GitHub itself is preparing infrastructure for a future measured at 30 times today’s scale. Every new application, agent, and integration can extend the credential layer further. A complete map of that layer is the input everything else depends on, and that map is what detection is for.
FAQ
What is the credential layer?
The credential layer is the entire population of secrets connecting people, applications, infrastructure, and services across an enterprise. Its perimeter follows the credentials themselves rather than the network, which is why secrets created inside a sanctioned cloud account can later appear in a repository, a collaboration tool, or a developer laptop.
Why is credential sprawl getting worse?
Software production is scaling far faster than headcount. GitGuardian’s research has found that secret exposure has grown 1.6 times faster than the number of active developers over the period they have been studying it, and every new application, integration, and AI agent creates another system that has to authenticate to something else.
How many secrets live on a typical developer machine?
GitGuardian’s analysis of systems compromised during the Shai-Hulud 2 supply-chain campaign identified 33,185 unique secrets across 6,943 compromised systems. Forty-four percent of those machines held more than 10 secrets, and 5% held more than 100.
This article summarizes reporting from thehackernews.com.