Credential sprawl is outpacing IAM controls in AI-driven work

At a glance

What this is: This article argues that credential sprawl has become the real identity control gap, because modern work creates and spreads secrets faster than IAM, SSO, and PAM can govern them.

Why it matters: It matters because IAM teams must govern human, NHI, and AI-driven access paths that live outside the identity provider, or they will keep losing visibility, ownership, and revocation control.

By the numbers:

• 52% of employees have downloaded apps without IT approval.
• breaches take the longest to identify and contain, nearly 10 months.
• 52% of employees have downloaded apps without IT approval.

👉 Read 1Password's analysis of credential sprawl in AI-driven work

Context

Credential sprawl is what happens when passwords, tokens, service accounts, and secrets are created where work happens instead of where identity is governed. In this article, the primary keyword is credential sprawl, and the core claim is that sign-in controls do not cover the long tail of shared accounts, scripts, browser-stored credentials, and AI prompts that now carry real access.

That matters for IAM because the identity provider can only govern what is federated, provisioned, and visible. Once credentials live in SaaS admin consoles, files, pipelines, or automation workflows, access becomes harder to inventory, revoke, and audit, which is why the problem is operational rather than theoretical.

NHIMG's own analysis of secrets exposure shows how quickly unmanaged credentials become systemic. The question for practitioners is no longer whether secrets sprawl exists, but whether governance processes can keep pace with the places credentials are actually created and used.

Key questions

Q: How should security teams govern credentials that live outside the identity provider?

A: Security teams should treat every password, token, and secret as a governed asset, even when it is created in a browser, script, or SaaS console. The practical test is whether the team can name the owner, location, purpose, and revocation path without manual detective work. If not, the credential is already outside control.

Q: Why do shared accounts and service accounts increase identity risk?

A: Shared accounts and service accounts increase risk because they weaken ownership, blur accountability, and make revocation harder when people change roles or leave. They also create standing access that may outlive the task that required it, which expands the time window for misuse and audit failure.

Q: What breaks when credentials are created in AI workflows and pipelines?

A: Governance breaks when credentials are generated where work is executed but not where identity is managed. In AI workflows and pipelines, secrets can be copied into prompts, configs, and scripts, which makes discovery, rotation, and offboarding inconsistent. The result is a hidden access layer that standard IAM reports often miss.

Q: Who is accountable when a leaked secret is used to access business systems?

A: Accountability belongs to the team that created, approved, or failed to retire the credential, not only to the security function that discovered it. If the credential was used in an automation or AI workflow, the workflow owner also has responsibility for revocation, proof, and post-incident cleanup.

Technical breakdown

Why IAM and SSO stop at the edge of credential sprawl

IAM, SSO, and PAM govern authenticated pathways, but they do not automatically govern every credential that exists in a business workflow. Shared logins, API tokens, SSH keys, service accounts, and secrets created in scripts or AI prompts often live outside the identity provider. That creates an access layer that is real, useful, and largely invisible to central policy. The technical failure is not authentication itself. It is the gap between federated identity and the credential objects that execute work in browsers, pipelines, and SaaS tools.

Practical implication: map where credentials are created and stored outside the identity provider before you rely on sign-in controls alone.

How AI agents and automation multiply secret exposure

AI builders and developers routinely generate new credentials to let agents call tools, update records, or trigger workflows. Those secrets can sit in prompts, config files, spreadsheets, or browser sessions, which means the access path is embedded in operational tooling rather than managed identity infrastructure. That is why automation increases both the number of credentials and the number of places they can leak. Once credentials are distributed across workflows, the security problem shifts from login protection to ownership, lifecycle, and revocation of non-human credentials.

Practical implication: treat agent and automation credentials as governed assets with explicit ownership and revocation paths, not as disposable implementation details.

Coverage, control, and lifecycle for every credential object

The article's governance model breaks credential security into three parts. Coverage asks what must be protected, including passwords, passkeys, shared accounts, tokens, service accounts, environment files, and AI agent secrets. Control asks where those credentials may be stored, how they can be shared, and what rules apply where work occurs. Lifecycle asks how creation, ownership, rotation, revocation, and proof are maintained as roles change and automations continue. This is the right architecture because credential risk is not a single control failure, it is a missing operating model.

Practical implication: build policy, workflow, and audit coverage around the full credential lifecycle, not just sign-in events.

Threat narrative

Attacker objective: The attacker aims to use unmanaged credentials as a low-friction path into connected systems without needing to break traditional authentication controls.

1. Entry begins when a user, developer, or automation creates a credential in a browser, script, SaaS console, or AI prompt instead of in centrally governed identity systems.
2. Escalation occurs when that credential is reused, shared, or left behind in unmanaged locations, creating standing access that outlives the original task or owner.
3. Impact follows when attackers or unauthorised users rely on stolen or compromised credentials to sign in, move through connected apps, and delay detection and containment.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Credential sprawl is the operational form of identity drift. The article shows that access is no longer just provisioned and reviewed in one place. It is created in browsers, scripts, prompts, and shared tools where governance has weaker visibility. That means identity programmes that still think in terms of directory entries and login events are measuring the wrong layer of control.

IAM, SSO, and PAM do not equal credential governance. Those systems help with federated sign-in and privileged access, but they do not close the long tail of tokens, service accounts, shared accounts, and secrets living outside the identity provider. The governance failure is assuming authentication coverage implies access coverage. Practitioners need to treat that distinction as a board-level operating risk.

Shadow credential layer: this article names a real control plane that sits beneath the identity provider, where work tools create credentials faster than central teams can inventory them. Once that layer exists, lifecycle governance becomes partially fictional because owners change, automations persist, and revocation trails disappear. The practical conclusion is that access governance must extend to the places where credentials are born, not only where users sign in.

Joiner-mover-leaver processes break when credentials outlive the people and workflows that created them. Traditional lifecycle controls assume clear ownership and predictable offboarding. In credential sprawl, those assumptions fail because automations remain active after role changes and secrets are copied into places no one recertifies. The result is lingering access with unclear accountability, which means lifecycle review has to encompass machine and workflow-owned credentials as well as human accounts.

One governance model has to span human, NHI, and AI-assisted access creation. The article makes clear that the same business function can produce user sign-ins, service accounts, and agent secrets in one workflow. That convergence is why the identity programme cannot keep separate rules for separate access layers. Practitioners should align policy, ownership, and revocation around the credential object itself, regardless of which actor created it.

From our research:

• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks, according to The State of Secrets Sprawl 2026.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, which shows that detection without revocation leaves exposure intact.
• For a deeper view of lifecycle controls, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for the ownership and offboarding patterns that reduce lingering access.

What this signals

Shadow credential layer: the next programme failure will not be a lack of sign-on protection but a lack of control over where credentials are born, copied, and forgotten. Teams that only measure federated access will miss the access paths that matter most in SaaS, scripts, and AI-assisted work.

The practical shift is toward lifecycle governance for credentials as objects, not just for users as accounts. That means ownership, revocation, and proof need to follow the credential into collaboration tools, pipelines, and automation flows, or the programme will keep rediscovering the same exposure in different places.

With 28% of secrets incidents now originating outside code repositories, the operating model has already moved beyond repository scanning. The teams that adapt fastest will be the ones that connect identity governance to the tools where work is actually done, using OWASP Non-Human Identity Top 10 as a control vocabulary rather than a checklist.

For practitioners

• Inventory credentials outside the identity provider Identify passwords, tokens, service accounts, SSH keys, environment files, and agent secrets stored in browsers, scripts, notes, SaaS consoles, and AI prompts. Prioritise the systems where work actually happens, not only the directory where users authenticate. The goal is a real asset map, not a login report.
• Assign ownership to every non-human credential Require a named owner for each API key, token, shared account, and automation secret so review and revocation do not depend on tribal knowledge. Tie ownership to the workflow or application that uses the credential, then remove credentials that cannot be justified by a current business process.
• Extend lifecycle controls to automation and agents Apply creation, rotation, revocation, and offboarding controls to credentials created by scripts, pipelines, and AI workflows. Do not allow automated systems to inherit standing secrets indefinitely. If a workflow can still execute after its original owner changes roles, the lifecycle model is incomplete.
• Track where credentials are stored and shared Set policy for browser storage, spreadsheets, text files, chat tools, and collaboration platforms because those are common leak points once credentials escape identity platforms. Review access paths in Slack, Jira, Confluence, and developer tooling together, since the control gap is often cross-platform.

Key takeaways

• Credential sprawl is now an identity governance problem, not just a secrets management problem, because credentials live across SaaS, scripts, browsers, and AI workflows.
• The evidence points to a widening gap between sign-in controls and real access control, especially where secrets are created outside central identity systems.
• Practitioners need ownership, lifecycle, and revocation coverage for every credential object, including automation and agent-created secrets.

Key terms

• Credential Sprawl: Credential sprawl is the uncontrolled spread of passwords, tokens, service accounts, and other secrets across tools and workflows. In practice, the risk is not only quantity. It is the loss of ownership, visibility, and revocation discipline once credentials move outside central identity systems.
• Shadow Credential Layer: A shadow credential layer is the unmanaged access surface created when credentials live in browsers, scripts, notes, chat tools, or automation rather than in governed identity platforms. It behaves like a parallel control plane, because work can continue even when central IAM cannot see or revoke the credential cleanly.
• Non-Human Credential: A non-human credential is a secret used by software, automation, or an AI agent to authenticate or act on a system’s behalf. Examples include API keys, tokens, certificates, and service account secrets. These credentials need lifecycle governance because they often persist beyond the human task that created them.
• Credential Lifecycle: Credential lifecycle is the full path from creation to rotation, ownership change, revocation, and proof of retirement. For non-human and AI-assisted workflows, lifecycle management must follow the workflow itself, because the credential may outlive the person or script that originally requested it.

Deepen your knowledge

Credential sprawl, shared accounts, and AI agent secrets are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to govern access where work actually happens, this is the right starting point.

This post draws on content published by 1Password: credential sprawl in AI-driven work and why sign-ins are not enough. Read the original.