AI-driven secrets sprawl is outpacing enterprise governance

At a glance

What this is: GitGuardian’s 2025 secrets sprawl report shows that AI adoption, faster code production, and expanding machine identities are accelerating credential leakage across public GitHub.

Why it matters: For IAM and NHI practitioners, the report shows that the risk is no longer just exposure, but the rate at which new identities, secrets, and tool connections are being created faster than governance can absorb them.

By the numbers:

• Publicly active developers on GitHub grew 33% in 2025, and 54% of active developers made their first commit that year.
• 2021, e 2021, leaked secrets have grown 152%, while the public developer population grew 98%.

👉 Read GitGuardian's 2025 State of Secrets Sprawl report on AI and NHI risk

Context

The core issue is not simply that more secrets exist. It is that modern software delivery now creates more non-human identities, more integrations, and more ephemeral workflows than traditional IAM operating models were built to track. When AI tooling becomes part of the default software stack, every model call, orchestration layer, and support service adds another credential lifecycle that needs ownership, scope, and rotation.

GitGuardian’s 2025 findings point to a governance gap rather than a detection gap. The report describes a world where identity creation is speeding up, credential sprawl is widening, and lifecycle controls are lagging behind the pace of development. That pattern is consistent with broader NHI risk, where the problem is not only exposure, but unmanaged persistence.

For practitioners looking at the mechanics of this drift, the issue is familiar: convenience patterns become normal before policy catches up. The same dynamic appears in the Ultimate Guide to NHIs, where static versus dynamic secret handling is framed as a lifecycle problem, not a tooling preference.

Key questions

Q: How should security teams govern AI service credentials in production?

A: Security teams should govern AI service credentials as production identities, not disposable developer artifacts. That means assigning owners, setting expiry, limiting scope to the minimum required service, and tracking where each credential is stored and used. The key control is lifecycle discipline, because most exposure comes from credentials that remain valid long after the original task is finished.

Q: Why do AI workflows increase non-human identity risk?

A: AI workflows increase non-human identity risk because each feature usually depends on multiple connected services, not one model call. A single application can require model APIs, retrieval tools, databases, and orchestration layers, each with its own secret or token. That expands the number of identities to govern and increases the chance of reuse, leakage, and stale access.

Q: What is the difference between secret detection and secret governance?

A: Secret detection finds exposed credentials. Secret governance controls who owns them, how long they live, where they can be used, and when they are retired. Detection can tell you a secret leaked. Governance prevents that secret from staying valid long enough to become a durable access path.

Q: When should organisations treat AI credentials as a privileged access problem?

A: Organisations should treat AI credentials as privileged access whenever a token can reach production data, external tools, or automation that can change state. At that point, the credential is not just an integration detail. It becomes an access control decision that needs least privilege, review, and timely revocation.

Technical breakdown

Why AI service secrets are now a distinct NHI risk category

AI service secrets are credentials used to connect applications to model providers, orchestration frameworks, search APIs, and adjacent AI infrastructure. They matter because the AI stack is no longer a single model key. It is a chain of services, each with its own access token, configuration file, and rotation requirement. That increases the number of NHI objects that must be owned and governed. In practice, developers often copy keys into local files, demo scripts, and automation jobs to move quickly. Those shortcuts create durable exposure even when the workload is temporary. Practical implication: classify AI-related secrets as a separate control population with explicit ownership and expiry rules.

Practical implication: Treat AI service credentials as a distinct control population with explicit ownership, expiry, and rotation rules.

How model orchestration expands the identity blast radius

Orchestration layers such as agent builders, retrieval services, and workflow engines sit between users, data, and models. They do not remove credential risk. They multiply it by introducing more tool calls, more service-to-service trust, and more places where secrets can be embedded. A single AI feature can therefore depend on multiple NHI identities, including database credentials, API keys, and platform tokens. When those identities are reused across environments or copied into examples, the blast radius expands beyond the original code path. The architectural problem is not the model itself, but the growing dependency graph around it. Practical implication: map every AI workflow to its downstream credentials before allowing it into production.

Practical implication: Map each AI workflow to every downstream credential before approving production use.

What leaked secret growth says about lifecycle control failure

Secrets leakage rises when creation outpaces governance. That means the operational failure is usually not discovery but lifecycle control. Teams create credentials faster than they can scope, rotate, or retire them, so long-lived secrets persist in code, logs, and configuration. In NHI terms, that is a standing privilege problem disguised as a developer productivity problem. AI accelerates the cycle because it makes it easier to prototype, connect, and ship with minimal friction. The result is not just more secrets, but more identities whose purpose is unclear after deployment. Practical implication: shift from manual cleanup to lifecycle enforcement tied to ownership and expiration.

Practical implication: Move from manual cleanup to lifecycle enforcement tied to ownership and expiration.

Threat narrative

Attacker objective: The attacker aims to harvest reusable credentials that unlock AI workflows, data access, and broader service-to-service trust.

1. Entry occurs when developers embed API keys, database credentials, or AI service tokens into commits, local files, and sample configurations.
2. Escalation follows when those credentials are reused across environments or linked to orchestration layers that can call multiple services on behalf of the workload.
3. Impact is credential exposure at scale, enabling unauthorized access to AI services, data stores, and supporting automation paths.

Breaches seen in the wild

• Emerald Whale breach — exposed Git config files led to 15K secrets stolen and 10K repo compromises.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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 service credentials have become a first-class NHI population, not a side effect of development. The report shows that model-provider keys, orchestration tokens, search APIs, and supporting platform credentials are now part of routine software delivery. That changes governance because these identities are created, copied, and retired by engineering teams at high speed. NHI programmes should stop treating them as miscellaneous secrets and start treating them as a distinct control class.

Identity blast radius is now the right mental model for AI tooling risk. AI workflows do not usually fail because one credential exists. They fail because one credential unlocks multiple services, multiple environments, or multiple tool chains. That makes scope, ownership, and expiry more important than raw detection volume. Practitioners should measure how far a single leaked AI secret can travel before they focus on remediation speed.

Ephemeral development does not mean ephemeral risk. The report shows that prototypes, demos, and fast integrations often outlive the assumptions behind them. A secret pasted for a temporary test can remain reachable in repositories, scripts, and automation after the feature ships. That is a governance failure, not a coding mistake. Teams need lifecycle controls that assume fast creation will be matched by fast sprawl unless policy intervenes early.

Model Context Protocol reinforces, rather than resolves, the governance challenge. Any standard that makes it easier to connect models to tools and data sources also makes it easier to multiply identities and credentials. The market should read that as validation for stronger NHI governance, not as a reason to postpone it. Security teams should build controls for connection points, not just for the model endpoint itself.

Secrets management is becoming an operating discipline for AI adoption. The report links AI growth to more credentials, more integrations, and more unmanaged lifecycle states. That means organisations cannot separate AI strategy from NHI strategy anymore. The practitioners who win here will be the ones who can answer ownership, scope, rotation, and retirement questions before the next integration goes live.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, showing that behaviour remains the weak point in most programmes.
• The Guide to the Secret Sprawl Challenge frames how to reduce sprawl across code, CI/CD, and collaboration tools before secrets become durable access paths.

What this signals

Identity blast radius will become the decisive governance metric for AI programmes. As AI features spread across retrieval, orchestration, and data access layers, the question is no longer whether a secret exists. The real question is how much access it grants when it leaks. Teams that can quantify blast radius will be better positioned to prioritise remediation and justify tighter control over high-risk integrations.

The 2025 secrets data suggests a structural control gap, not a temporary tooling gap. With 6 distinct secrets manager instances on average in many organisations, identity ownership fragments quickly once AI projects move from prototype to production. Practitioners should expect credential sprawl to rise unless they consolidate lifecycle controls around the systems that create secrets, not just the systems that store them.

For programmes building agentic AI or model-connected workflows, the next governance step is to define who can approve new tool connections, who can revoke them, and how quickly that revocation takes effect. The discipline required is closer to privileged access governance than to traditional application configuration management.

For practitioners

• Inventory AI-related NHI credentials separately Create a dedicated inventory for model-provider keys, orchestration tokens, search APIs, and database credentials used by AI workflows. Tie each secret to an owner, system, and expiry date so the AI stack is not buried inside general secrets registers.
• Enforce lifecycle controls on temporary integrations Require expiration and review dates for demo keys, proof-of-concept credentials, and automation tokens. Temporary integrations are where hardcoded secrets most often persist after a project moves into production.
• Map each AI workflow to its blast radius Document every downstream service a model or agent can reach, including databases, retrieval layers, and external APIs. Use that map to decide whether the credential should be scoped down, segmented, or replaced with short-lived access.
• Move secret detection closer to the developer loop Scan commits, configuration files, and pipeline artifacts before merge, then gate releases on remediation for exposed AI service keys and other high-value secrets. Detection after deployment is too late for fast-moving AI projects.
• Review ownership for agent and orchestration credentials Assign explicit business and technical owners for every token used by agent builders, retrieval services, and orchestration platforms. Without clear ownership, rotation and retirement decisions stall and the credential outlives its purpose.

Key takeaways

• AI adoption is accelerating secrets sprawl because every new model, orchestration layer, and support service adds another NHI to govern.
• The main failure mode is lifecycle control, not discovery, because leaked credentials often remain valid far longer than teams expect.
• Organisations should govern AI credentials as privileged access assets with ownership, scope, rotation, and retirement rules.

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: Identity blast radius is the amount of access a credential can unlock if it is exposed or misused. In NHI programmes, it helps teams judge how far a token, key, or certificate can move across services, data stores, and automation paths before it is contained.
• Secrets Sprawl: Secrets sprawl is the uncontrolled spread of credentials across code, pipelines, repositories, and collaboration tools. It becomes a governance problem when secrets are created faster than they are inventoried, scoped, rotated, and retired, leaving hidden access paths behind.
• Model Context Protocol: Model Context Protocol is an open protocol for connecting AI agents to tools and data sources. In security terms, it increases the number of integration points that can expose credentials, so teams need to treat each connection as a governed identity relationship, not a simple API call.

What's in the full report

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

• The full detector-by-detector breakdown of AI service secrets, including which platforms drove the largest year-over-year increases.
• The MCP configuration findings that show which credential types are leaking inside model-to-tool connection files.
• The commit-level analysis of AI-assisted coding and how co-authored commits correlate with secrets leakage patterns.
• The policy-breach distribution that explains where lifecycle weaknesses are most visible across long-lived and duplicated secrets.

👉 GitGuardian's full report covers detector trends, MCP findings, and AI-assisted commit patterns in more detail.

Deepen your knowledge

AI service credentials and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to bring order to AI-driven secrets sprawl, it is worth exploring.