The latest GitGuardian State of Secrets Sprawl 2026 report shows that hardcoded secrets in code and infrastructure are not just a persistent problem – they are accelerating rapidly. In 2025, GitGuardian detected 29 million new secrets on public GitHub, a 34% year‑over‑year increase and the sharpest rise since the report began.
Hardcoded secrets on GitHub surge with AI coding tools and DevOps
Since 2021, the volume of leaked secrets on GitHub has grown by 152%, while the number of public GitHub developers increased by 98%. This gap reflects two converging trends: more developers than ever, and the widespread use of AI code generation tools that frequently reproduce insecure patterns such as embedding API keys, tokens or passwords directly in source code.
AI ecosystems themselves are a rapidly growing source of exposure. In 2025, GitGuardian recorded 1,275,105 AI‑related secret leaks, up 81% from 2024. Eight of the ten fastest‑growing key categories were tied to AI services. The biggest growth was not in well‑known LLM APIs alone, but in the surrounding LLM infrastructure: retrieval APIs (for example, Brave Search, +1255%), orchestration services (Firecrawl, +796%) and managed backends (Supabase, +992%). Each new AI integration layer creates an additional machine identity and expands the attack surface.
Internal repositories and collaboration tools: the real secrets exposure
While public GitHub often receives most attention, the report confirms that the most valuable credentials tend to live in internal systems. GitGuardian found that 32.2% of internal repositories contained at least one hardcoded secret, compared with only 5.6% of public repositories. Internally, these are rarely “test” keys; they are typically CI/CD tokens, cloud credentials and database passwords – exactly the assets that attackers seek once they gain a foothold.
The sprawl of secrets also extends far beyond source code. In 28% of incidents in 2025, leaks were found exclusively in collaboration platforms such as Slack, Jira and Confluence. These incidents proved more severe: 56.7% of secrets found only in collaboration tools were rated critical, versus 43.7% for leaks confined to code repositories. Teams routinely exchange credentials during incident response, debugging and onboarding, often with minimal technical controls, creating high‑value targets in chat logs and tickets.
Exposed GitLab, Docker registries and a porous security perimeter
GitGuardian also identified thousands of accidentally exposed self‑hosted GitLab instances and Docker registries in 2025. Scanning these systems uncovered around 80,000 secrets, of which approximately 10,000 remained valid. Container images are particularly concerning: 18% of scanned Docker images contained secrets, and 15% of those secrets were still valid. For GitLab repositories, secrets were present in 12% of repos, with 12% of them remaining exploitable.
Containerized secrets pose elevated risk because they are close to production environments and often baked into images “once and forever.” Misconfigured network rules, access policies or registry settings can turn supposedly private registries into public resources, illustrating how the classic boundary between “internal” and “external” has become increasingly permeable.
Why secret remediation fails: long‑lived keys and fragile pipelines
Discovering a secret does not mean it is neutralized. When GitGuardian retested secrets that had been validated back in 2022, 64% were still exploitable four years later. This highlights that revocation and rotation of credentials remain poorly automated and rarely embedded into routine engineering processes.
Secrets hard‑wired into build pipelines, CI variables, container images and third‑party integrations can be difficult to rotate without risking production downtime. Many teams perceive aggressive rotation as more disruptive to the business than inaction, and attackers capitalize on this inertia. This pattern aligns with broader industry findings that configuration weaknesses and credential misuse are leading causes of breaches.
Supply chain attacks and AI agents expand the attack surface
Software supply chain attacks continue to be a powerful vector for secrets theft. During the Shai‑Hulud 2 campaign, researchers obtained rare visibility into secrets present on compromised developer workstations. On 6,943 systems, they identified 294,842 secret occurrences, corresponding to 33,185 unique values. Each active secret appeared in an average of eight different locations on a single machine, including .env files, shell history, IDE configuration files, cached tokens and build artifacts. Notably, 59% of compromised systems were CI/CD runners rather than individual laptops, underscoring how build infrastructure has become a primary target.
A more recent supply chain attack on the LiteLLM package followed a similar pattern: malicious code harvested SSH keys, cloud credentials and API tokens from developer machines – the same endpoints now heavily used to build and test AI applications.
The emergence of Model Context Protocol (MCP) and similar frameworks for “agentic AI” introduces an additional layer of exposure. In 2025, GitGuardian discovered 24,008 unique secrets in public MCP configurations on GitHub, with 2,117 confirmed as valid. As AI agents proliferate, the practice of embedding keys in configuration files, launch flags and local JSON files will likely become even more common.
From secret scanning to non‑human identity management
The GitGuardian report reinforces three strategic questions for modern security programs: how many non‑human (machine) identities exist, who owns them, and what do they have access to? Relying solely on scanning public repositories and enforcing manual policies is no longer adequate. Industry frameworks from organizations like NIST and OWASP increasingly emphasize identity‑centric security, and machine identities are rapidly outnumbering human accounts.
Organizations adopting AI and high‑velocity DevOps need to move from point‑in‑time secret detection toward continuous Non‑Human Identity (NHI) management. This means minimizing long‑lived static credentials, shifting to short‑lived, identity‑based access, standardizing on secrets vaults as a default developer pattern, and treating every service account, CI job and AI agent as a first‑class IAM entity with a defined lifecycle.
Secrets can no longer be viewed as isolated incidents; they are a systemic risk directly tied to AI growth, automation and distributed development. Organizations that extend visibility beyond public repositories to internal codebases, collaboration platforms, container registries and developer workstations—and that automate rotation and revocation—will be better positioned to withstand current and future attack waves. Investing early in robust secrets management and NHI governance is not only a defensive measure, but a foundation for resilient, scalable digital operations.
