TL;DR: GitGuardian reports 28,649,024 new secrets in public GitHub commits in 2025, a 34% year-over-year increase, alongside 1,275,105 exposed AI-service secrets and 81% growth in AI-related leaks. The issue is no longer just developer hygiene: AI tooling is multiplying NHI creation and making lifecycle governance the limiting control.
At a glance
What this is: GitGuardian’s latest analysis shows that secrets leakage is rising faster than the developer base, with AI services now a major source of exposed credentials.
Why it matters: IAM and NHI teams need to treat AI service keys, orchestration tokens, and other machine identities as governed lifecycle assets, not ad hoc developer artifacts.
By the numbers:
- 12 of the top 15 fastest-growing leaked secret types were AI services.
- Publicly active developers on GitHub grew 33% in 2025, while 54% of active developers made their first commit that year.
👉 Read GitGuardian's analysis of AI-driven secrets sprawl and enterprise governance gaps
Context
Secrets sprawl is no longer just a code hygiene problem. It is now a governance problem created by faster software production, more third-party services, and more machine identities embedded in day-to-day development.
GitGuardian’s 2025 data shows that the volume of leaked secrets is rising faster than the developer population itself, which means the control gap is not simply more people writing code. It is the lack of ownership, scope, rotation, and offboarding discipline for the identities that software now depends on.
AI tooling changes the shape of the problem because it increases the number of keys, tokens, and service connections required to ship ordinary software. That makes secrets lifecycle management a core identity control rather than a downstream DevOps cleanup task.
Key questions
Q: What breaks when AI service secrets are treated like ordinary developer artifacts?
A: Secrets become distributed faster than governance can track them. AI service keys, orchestration tokens, and retrieval credentials end up in configs, scripts, and repos without clear ownership or expiry, which makes revocation and containment far harder once exposure occurs.
Q: Why do AI pipelines expose more credential risk than traditional software development?
A: AI pipelines create more identities, more integrations, and more temporary execution paths than conventional software delivery. Each model, agent, notebook, and orchestration step can generate a new token or secret, and those artefacts often propagate into places security teams do not monitor. The result is identity sprawl, not just poor hygiene.
Q: How can security teams tell whether secret management is actually working?
A: Look for fewer plaintext secrets, narrower reuse, faster rotation, and a shrinking set of credentials that remain valid across multiple systems. If the same password or API key can still unlock several services, secret management is not yet reducing blast radius in practice.
Q: What breaks when cyber asset visibility is fragmented across too many tools and data sources?
A: Fragmented visibility makes it harder to understand relationships, prioritize the right assets, and respond quickly during an incident. Teams can miss connections between cloud assets, users, and dependencies, which slows analysis and increases the chance that important risks stay buried. In practice, fragmentation turns asset data into noise instead of usable context.
Technical breakdown
Why AI service secrets multiply faster than human review can absorb
AI-enabled development adds more services to a normal build path. Model APIs, orchestration layers, retrieval services, voice platforms, and monitoring tools all introduce new credentials, and many are embedded in local files, scripts, and sample configs before any governance step occurs. The technical issue is not only leakage, but credential proliferation across short-lived projects and fast-moving prototypes. Once those secrets exist, they are difficult to inventory because they sit outside central vault workflows and often span multiple tools and environments. That makes discoverability and lifecycle control the real bottlenecks, not detection alone.
Practical implication: Treat AI service keys as first-class NHI assets and require inventory, owner, scope, and expiry before they can be used in production.
How AI-assisted development changes the secrets exposure surface
AI-assisted commits do not create a new class of secret so much as they compress the time between code creation and exposure. Developers can scaffold applications, connect external services, and publish working code quickly, which increases the chance that credentials land in repositories, configs, shell histories, or demos before review catches them. The mechanism is speed plus repetition: insecure patterns get copied more often because the path to a runnable application is shorter. That is why AI adoption should be read as an accelerant of existing secrets-management weaknesses, especially where teams lack strong pre-commit scanning and enforced secret issuance patterns.
Practical implication: Shift from reactive leak detection to pre-commit blocking, secret scanning in CI, and approved issuance paths for every AI-related credential.
Why MCP and other AI control planes expand the identity graph
Model Context Protocol and similar control planes connect models to tools and data sources, which makes every integration point an identity boundary. A single AI workflow can touch databases, search APIs, retrieval services, and monitoring platforms, each with its own credential and access scope. That turns the AI stack into a dense web of delegated access rather than a single application integration. The problem is compounded when sample configs and quick-start patterns include hardcoded credentials, because those examples spread insecure defaults at the same time the standard spreads. Governance has to follow the integration graph, not just the model endpoint.
Practical implication: Map AI control-plane connections as an access graph so each tool, data source, and token is owned, scoped, and rotated independently.
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.
- Millions of Misconfigured Git Servers Leaking Secrets: Nearly 5 million misconfigured Git servers expose sensitive secrets and credentials online.
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-driven secrets sprawl is really identity sprawl. The article shows that leaked credentials are not rising only because developers are busier. They are rising because AI-heavy software now depends on more service accounts, API keys, tokens, and orchestration credentials than traditional application stacks. That is a lifecycle problem, not a tooling problem. The practical conclusion is that secrets management must be governed as NHI lifecycle management across the software delivery path.
Long-lived secrets remain the core control failure. GitGuardian’s own breakdown shows that the dominant breach pattern is not exotic exploitation but secrets that live too long, spread too widely, and remain valid after their original purpose has passed. In other words, the exposure window is the failure mode. The discipline gap is between creation and revocation, and AI accelerates both sides of that gap. Practitioners should read this as a standing privilege problem, not just a leak problem.
AI control planes create a new identity blast radius. When models, retrieval services, databases, and orchestration layers are stitched together, the number of identities per workflow rises sharply. That creates a larger blast radius whenever one credential is copied into a repo, log, or config file. The named concept here is identity blast radius: the number of downstream services, data sources, and workflows that inherit risk from one leaked secret. Governance has to reduce the blast radius, not just count the leaks.
Access governance now needs to keep pace with software production velocity. The report makes clear that AI-assisted development compresses the window in which security teams can intercept unsafe credential handling. Traditional review cycles assume there is time to catch and remediate secrets after they appear. In AI-heavy delivery pipelines, that assumption is weakening because the code reaches runnable form before many governance checkpoints trigger. The implication is to move ownership and issuance controls earlier in the delivery chain.
The market signal is not more AI risk, but more ordinary controls failing under AI scale. The article does not show that AI invents new identity principles. It shows that AI multiplies the number of places where familiar controls must work. That means enterprises should re-evaluate whether their secrets program is actually operating as a lifecycle discipline across development, deployment, and runtime, rather than as a scanning exercise after the fact.
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.
- 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
Identity blast radius: AI workflows do not just increase the number of secrets, they increase the number of systems that inherit risk from each credential. When one token can reach a model endpoint, a retrieval layer, and a database, the governance question becomes how far the blast radius extends before revocation can take effect.
Secrets security programs need to move upstream into release engineering, because the highest-risk credentials are increasingly created during fast integration work rather than after deployment. Controls that only scan for leaks after code is written will keep finding the same problem too late to prevent reuse.
According to the State of Secrets Sprawl 2026, 8 of the top 10 fastest-growing types of leaked secrets year-over-year are tied directly to AI services. That concentration suggests AI-specific lifecycle controls will matter more than generic secret hygiene as the stack keeps expanding.
For practitioners
- Establish a full inventory of AI-related NHIs Catalog model API keys, orchestration tokens, retrieval service credentials, database connections, and agent tool accounts with named owners and business purpose.
- Block hardcoded secrets before merge Use pre-commit and CI checks to stop credentials from entering repositories, and require approved secret issuance for AI application code.
- Shorten the lifetime of AI service credentials Set explicit expiry, rotation, and revocation rules for every AI service secret, especially those embedded in prototypes, scripts, and sample configurations.
- Map the AI integration graph Document each external service, data source, and tool an AI workflow can reach so access scope is visible before the workflow ships.
- Tie secrets governance to software release gates Require owner confirmation and scope review for any new secret that supports an AI feature before the feature can move to production.
Key takeaways
- AI-driven development is turning secrets management into a lifecycle governance problem because the number of machine identities is rising faster than most teams can track them.
- The article’s evidence points to a scale issue as well as a control issue, with millions of new secrets and rapid growth in AI-related credential types.
- Organizations that want to reduce exposure need to move secret ownership, scope definition, and rotation decisions earlier in the software delivery chain.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on exposed secrets in code and AI tooling. |
| NHI-07 — Long-Lived Secrets | Long-lived credentials are identified as the dominant policy-breach pattern. | |
| NHI-05 — Overprivileged NHI | AI service tokens and control-plane credentials often carry broad access scope. | |
| Recommendation — Scan AI development paths for leaked secrets and revoke exposed credentials immediately. Shorten secret lifetime and enforce rotation before credentials can persist across releases. Limit AI service tokens to the minimum access needed for each workflow and integration. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle management directly applies to leaked service secrets. |
| Recommendation — Apply IA-5 to govern issuance, rotation, and revocation of AI-related authenticators. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Leaked secrets can enable credential access and downstream movement across connected systems. |
| Recommendation — Map exposed secrets to TA0006 and TA0008 to prioritise containment of reachable credentials. | ||
Key terms
- AI Service Secret: An AI service secret is a credential used to connect software to model providers, retrieval services, orchestration tools, or adjacent AI infrastructure. It is a non-human identity artifact with the same lifecycle risks as any other secret: ownership, scope, rotation, and revocation all matter.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
- 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.
- Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
What's in the full report
GitGuardian's full article covers the operational detail this post intentionally leaves for the source:
- Breakdowns of the fastest-growing AI service secret types and the specific platforms they map to.
- The MCP configuration findings, including which secret types appear most often in exposed files.
- The AI-assisted commit data that shows how code production speed affects secrets leakage patterns.
- The policy-breach distribution that explains where lifecycle controls are failing most often.
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 IAM programme, it is worth exploring.
Published by the NHIMG editorial team on May 30, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org