AI secrets sprawl is outpacing legacy identity controls

At a glance

What this is: Wiz found that most Forbes AI 50 companies leaked secrets across a broad set of AI development and collaboration surfaces, exposing credentials in places traditional scanning misses.

Why it matters: This matters because AI programmes are creating more non-human identities, tokens, and access paths than legacy IAM and secrets governance were built to track.

By the numbers:

• Wiz found that 65% of the Forbes AI 50 have leaked verified secrets on GitHub.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.

👉 Read Akeyless's analysis of AI secrets sprawl and exposed credentials

Context

AI development creates a larger identity problem than a simple secret-scanning problem. Every model workflow, notebook, extension, orchestration step, and support channel can carry credentials, and many of those surfaces sit outside the places security teams normally inspect. In practice, the primary keyword here is AI secrets sprawl, because the issue is not a single leak but the multiplication of exposed identities across the development stack.

That changes how IAM, PAM, and NHI programmes have to think about governance. Static keys, broad API tokens, and long-lived access in AI pipelines behave like persistent liabilities, especially when secrets move into logs, forks, scratch files, and collaboration tools. The article’s core point is that AI teams are generating credential exposure faster than conventional controls can absorb, which makes identity lifecycle and secretless access the real control plane.

Key questions

Q: How should security teams reduce secret sprawl in AI development environments?

A: Start by expanding discovery beyond source code into notebooks, logs, extensions, support tools, and collaboration platforms. Then remove reusable credentials from the workflow wherever possible. The most effective programmes combine broad visibility with runtime-issued access, clear ownership for machine identities, and fast revocation when secrets are found.

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: What breaks when secrets are used to authenticate AI agents and workflows?

A: Reusable secrets create standing exposure in environments that change too quickly for manual review. If a secret must exist before a task can run, it can be copied into logs, prompts, configs, or caches and reused later. That turns a short task into a long-lived compromise opportunity.

Q: How do teams know if secretless access is actually working?

A: Look for a reduction in persistent credentials, fewer secrets appearing outside repositories, and tighter ownership of machine identities. If AI workflows still depend on copied keys or broad tokens, then the programme has only moved the leak point rather than removing the leak surface.

Technical breakdown

Why AI development environments create secret sprawl

AI engineering stacks combine rapid iteration, shared tooling, and many temporary artefacts. Notebooks, CI workflows, model endpoints, vector databases, IDE extensions, and troubleshooting portals all generate or store credentials. Because these components are distributed across developer laptops, SaaS tools, and orchestration layers, a secret can appear in places that never go through the same review or scanning path as source code. The problem is not only where the secret is created, but how many copies and derivatives it accumulates as work moves between tools.

Practical implication: Security teams need coverage beyond repositories, including logs, extensions, notebooks, support systems, and personal repos.

Why static credentials fail in AI pipelines

Static credentials assume a stable identity and a predictable access path. AI pipelines break both assumptions because each agent, integration, or task may need fresh access at runtime, and that access often exists only briefly. When credentials persist longer than the task, they become transferable artefacts that can be copied into configs, prompts, logs, or caches. Secret rotation helps, but it does not remove the underlying exposure surface if the credential must exist before the workflow starts.

Practical implication: Move toward secretless or ephemeral access patterns so credentials do not remain available for leakage after task completion.

How machine identities expand the attack surface

Every new AI workflow introduces another non-human identity, another token, and another trust relationship. That is why AI programmes create an identity population that grows faster than manual governance can classify. If the organisation cannot inventory which machine or agent identities exist, where they authenticate, and who owns their lifecycle, then privilege drift becomes inevitable. The governance failure is structural: identity management was designed for more stable populations than AI systems now produce.

Practical implication: Treat AI agents, services, and integrations as first-class identities with ownership, scope, and lifecycle controls.

Threat narrative

Attacker objective: The attacker wants usable credentials that open access to AI pipelines, sensitive data, or privileged enterprise services without needing to break authentication directly.

1. Entry occurs when a secret is exposed in a repository, notebook, extension package, support portal, or other AI development surface that attackers routinely monitor.
2. Escalation follows when the exposed token or API key grants access to model systems, cloud services, or collaboration tools with broader permissions than intended.
3. Impact is achieved when the attacker uses that access to reach sensitive datasets, proprietary model assets, or downstream enterprise systems.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• 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 secrets sprawl is a governance failure, not a scanning gap: The article shows that credentials are leaking across repositories, forks, gists, notebooks, logs, extensions, and support portals because AI development produces too many identity touchpoints for legacy controls to cover. Traditional secrets hygiene assumes that the important surfaces are known in advance. That assumption no longer holds. Practitioners should treat AI pipelines as distributed identity systems, not just code repositories.

Secretless access becomes the only durable answer when static credentials multiply faster than review cycles: A short-lived token still leaves a secret to steal if the workflow depends on it existing before execution begins. The problem is not rotation cadence alone. The problem is that AI tooling creates a persistent exposure window whenever a credential must be materialised for the task. Practitioners should view ephemeral access as a structural control, not a convenience feature.

Identity lifecycle for machine identities is now the control boundary that matters: AI companies are creating non-human identities at a pace that outstrips classification, ownership, and offboarding processes. When a notebook, agent, or integration no longer has a clear owner, the associated credentials linger and drift into unmanaged use. The implication is that identity governance for AI must be built around ownership, scope, and retirement, not just authentication events.

Runtime access in AI systems should be governed by the same privilege logic used for high-risk machine access: Broad API tokens, org-level keys, and long-lived credentials behave like standing privilege in a fast-moving environment. That means the real governance question is not whether the secret is encrypted at rest, but whether it should exist at all. Practitioners should re-evaluate which AI workflows still require reusable secrets versus task-scoped access.

AI identities are becoming the new blast-radius multiplier in enterprise environments: As the number of agents, connectors, and orchestration steps grows, each identity expands the possible compromise path. That makes credential exposure a platform risk, not an isolated developer mistake. Practitioners should align NHI governance, PAM, and development controls around the same exposure model.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to Guide to the Secret Sprawl Challenge.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
• For the broader breach pattern behind exposed credentials and downstream access abuse, see 52 NHI Breaches Analysis.

What this signals

The next governance step for AI programmes is to treat every notebook, plugin, and orchestration layer as a credential-bearing identity surface. Once teams accept that reality, the question shifts from detection volume to lifecycle control, ownership, and runtime access design.

Ephemeral identity debt: the longer a credential exists outside the task that needs it, the more likely it is to become an exploitable artefact. That means AI programme maturity will increasingly be measured by how quickly credentials disappear after use, not how many alerts are generated.

Security teams that still rely on periodic scans will keep finding the same problem after it has already spread. The stronger signal is whether your identity programme can map every machine identity to an owner, a purpose, and a retirement path.

For practitioners

• Expand discovery beyond source control Scan notebooks, logs, IDE extensions, gists, forks, Slack, Jira, Confluence, and support portals for exposed credentials, not just primary repositories. Coverage has to follow where AI work actually happens.
• Replace reusable secrets with runtime-issued access Use secretless or ephemeral authentication for AI pipelines so the task receives access only when needed and does not leave a credential behind for later reuse.
• Inventory machine identities with named ownership Assign ownership, purpose, and expiry expectations to each AI service, workflow, and integration, then retire credentials when the associated process or team no longer exists.
• Treat developer tooling as an identity surface Review VS Code extensions, copilots, and automation plugins as potential credential sinks and apply the same governance standards you would use for other third-party access paths.
• Connect secrets detection to revocation workflows Make sure discovered secrets are not only found but also revoked quickly, because exposure without revocation still leaves valid access in circulation.

Key takeaways

• AI secrets sprawl is really an identity governance problem because the attack surface now includes every place machine work leaves artefacts.
• The evidence points to broad and persistent credential exposure, which means detection without revocation still leaves usable access in circulation.
• Programmes that want to control AI risk need secretless access, named ownership for machine identities, and lifecycle discipline across the full development stack.

Key terms

• Secret sprawl: Secret sprawl is the uncontrolled spread of credentials across code, tools, logs, notebooks, and collaboration systems. In AI environments, it grows quickly because each workflow creates new tokens and copies of existing ones, turning one access decision into many potential exposure points.
• Machine identity: A machine identity is a non-human identity used by software, services, or AI workflows to authenticate and act. It includes service accounts, tokens, API keys, and certificates, and it must be governed as an identity with ownership, scope, and retirement, not as a disposable implementation detail.
• Secretless access: Secretless access means a system authenticates without storing reusable credentials in the places where work is created. Instead of leaving keys in code or tooling, the platform issues short-lived access at runtime, which reduces the chance that a secret can be copied, reused, or leaked later.
• Identity lifecycle: Identity lifecycle is the process of creating, governing, reviewing, and retiring identities and their access. For AI and machine identities, the lifecycle must account for fast creation rates, short task windows, and rapid offboarding so that access does not outlive the workload it was meant to serve.

What's in the full article

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

• A step-by-step breakdown of the specific AI development surfaces where secrets were found, including notebooks, forks, logs, and support portals.
• Detailed discussion of the secretless access model and how ephemeral credentials are issued at runtime.
• Operational examples of how developers can retrieve credentials without embedding them in code or tooling.
• The product-level workflow for monitoring and terminating privileged AI access across environments.

👉 Akeyless's full post covers the exposure surfaces, machine identity growth, and secretless access model in more detail.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.