Credential sprawl is outpacing IAM controls in AI-driven work

At a glance

What this is: This is a 1Password analysis arguing that AI-driven work is spreading credentials into workflows that IAM, SSO, and PAM do not fully govern, creating a shadow credential layer.

Why it matters: IAM and PAM teams need to treat credential ownership, storage, rotation, and revocation as a workflow problem, not only a sign-in problem, because AI and automation keep generating access outside central controls.

By the numbers:

• 52% of employees have downloaded apps without IT approval, according to 1Password research cited by 1Password.
• Breaches that start with stolen or compromised credentials take nearly 10 months to identify and contain, according to 1Password research cited by 1Password.

Context

Credential sprawl is what happens when passwords, tokens, service accounts, API keys, and browser-stored logins spread into the places where work happens instead of staying under central governance. In AI-driven work, that includes copilots, agents, scripts, pipelines, spreadsheets, and prompts, which creates an identity problem for non-human credentials as much as for human users.

The governance gap is not sign-in authentication. It is ownership, lifecycle, and revocation for credentials created outside the identity provider and reused across SaaS, automation, and AI workflows. Once credentials move into those long-tail environments, traditional IAM controls can confirm a login but still leave access unmanaged.

Key questions

Q: What breaks when credentials are created outside the identity provider?

A: A clean ownership chain breaks first. Credentials created in browsers, scripts, or AI prompts often bypass central review, which means no one can reliably answer who owns them, where they are stored, or when they should be revoked. The result is unmanaged access that remains usable even after the original workflow has changed.

Q: Why do AI-generated development workflows increase IAM and secrets risk?

A: Because AI assistants often need access to prompts, templates, repositories, and cloud configuration examples to be useful. If those inputs are not tightly governed, they can normalise over-broad permissions, leak credentials into code, or encourage developers to copy unsafe access patterns. IAM risk grows when the assistant becomes part of the authorisation design process.

Q: How do teams know if credential sprawl is actually under control?

A: Credential sprawl is under control only when the organisation can identify every active credential, assign an owner, and prove that revocation and review are happening on a repeatable cadence. If departments still rely on local workarounds or shared logins, the programme is still operating with blind spots rather than governance.

Q: Should organisations prioritise revocation or discovery first in credential sprawl programmes?

A: Discovery comes first, but revocation must be designed at the same time. Knowing where secrets live is useful only if the team can disable them quickly when a user, workflow, or agent changes. The practical goal is to shrink the window between finding a credential and being able to remove its access.

Technical breakdown

Why federation does not govern the full credential estate

Federation solves authentication at the identity provider, but it does not govern every credential that work depends on. Shared logins, API tokens, service accounts, environment files, and agent secrets are often created in the workflow itself and then stored in tools that are invisible to IAM policy. That is why a programme can have strong sign-in controls and still lack control over what a script, browser extension, or AI workflow can actually use. The technical issue is not the absence of login security. It is the absence of credential governance at the point of creation, storage, and reuse.

Practical implication: inventory credentials outside the identity provider and treat them as governed assets, not local convenience objects.

How credential sprawl creates a shadow access layer

A shadow access layer emerges when access is created wherever work happens, including notes, browser vaults, admin consoles, text files, and prompts. Those credentials often bypass central review, which makes ownership ambiguous and revocation slow. Because the credentials still work, they tend to be reused and shared until an audit or incident forces a cleanup. This is particularly dangerous in AI-assisted workflows, where agents and builders can generate new tokens and secrets faster than governance teams can classify them. The result is not just sprawl. It is unmanaged authority that sits outside the identity programme.

Practical implication: close the creation and storage paths that allow credentials to bypass policy, review, and ownership assignment.

Why AI agents turn secrets management into lifecycle management

AI agents and automation do not merely consume credentials. They create and propagate them as part of runtime work. That changes the control problem from static protection to lifecycle governance: who issued the credential, who owns it, where it lives, when it rotates, and how it is revoked when the workflow changes. In NHI terms, the risk is not only secret leakage. It is that the secret remains valid across a workflow boundary the original controls never modelled. Traditional joiner-mover-leaver processes also become incomplete when the leaver is a script, pipeline, or agent rather than a person.

Practical implication: extend lifecycle controls to machine and agent credentials with explicit ownership, rotation, and revocation triggers.

Threat narrative

Attacker objective: The attacker seeks to use unmanaged credentials to enter systems, expand access, and persist in workflows that security teams cannot quickly inventory or revoke.

1. Entry occurs through credentials created in browsers, scripts, pipelines, or AI prompts rather than through a cleanly federated sign-in path.
2. Credential access follows because tokens, shared logins, and service accounts are reusable outside the identity provider and often survive tool changes.
3. Escalation happens when those credentials are copied into more workflows, shared across teams, or embedded in automation with wider access than originally intended.
4. Impact is delayed containment, orphaned access, and attacker sign-in opportunities that remain valid long after the original workflow should have been closed.

Breaches seen in the wild

• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Credential sprawl is now a governance model failure, not just an inventory problem. When credentials are created inside AI workflows, scripts, and browser-based tasking, the identity programme can no longer rely on sign-in controls as the boundary of control. That means IAM and PAM coverage must be judged by what they do not see as much as by what they authenticate. Practitioners should treat unmanaged credential creation as an access-governance defect, not an exception.

Coverage, control, and lifecycle are the three missing pillars in most credential programmes. Coverage defines which secrets and non-human credentials are in scope, control defines where they may live and be shared, and lifecycle defines how they are owned, rotated, and revoked. Without all three, organisations only move risk between repositories, browsers, and automation layers. The practitioner conclusion is simple: a credential programme that cannot answer who owns each secret is not governing access.

Shadow credential layers are especially dangerous because they scale with business-led IT and agentic automation. Teams adopt tools quickly, then generate tokens, shared logins, and service credentials to keep work moving. That creates a persistent layer of authority that sits outside the identity provider and outlives the people or workflows that created it. The implication for identity governance is that offboarding and certification must extend to machine-created access, not stop at employee accounts.

Long-lived secrets are the structural weak point in AI-assisted operations. AI tools can create access faster than review cycles can certify it, which makes stale credentials a standing exposure window rather than a cleanup issue. The access review model assumes an owner can attest to something that still exists when the review happens. In AI-driven work, that assumption is increasingly fragile, so practitioners need to rethink how governance attaches to runtime creation and revocation.

Credential sprawl converts incident response into archaeology. When access is scattered across SaaS, pipelines, prompts, and shared accounts, responders must first discover what exists before they can contain it. That delay is what turns a credential issue into a broad breach condition. For practitioners, the field lesson is to reduce the number of places where credentials can be born, copied, and forgotten.

From our research library:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Shadow credential layers: AI-driven work creates credentials in the same places people collaborate, which means the identity programme must govern browsers, prompts, scripts, and SaaS consoles as part of one access estate. If those creation points are outside policy, revocation will always lag behind usage.

Access review models assume a credential exists long enough to be certified. AI builders and automation can create and discard access inside the same workflow cycle, so governance has to shift toward issuance-time control and ownership enforcement rather than periodic cleanup.

The scale problem is already visible: 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, according to the State of Secrets Sprawl 2026. That pattern tells practitioners where discovery and containment need to start.

For practitioners

• Define the full credential estate Map passwords, passkeys, API tokens, SSH keys, service accounts, environment files, shared accounts, and agent secrets to a single inventory with named owners.
• Block ad hoc credential creation in workflows Limit where developers, admins, and AI builders can generate secrets, and remove browser notes, spreadsheets, and prompts from approved storage paths.
• Tie every secret to a lifecycle owner Assign ownership for creation, rotation, and revocation so credentials created by automation do not outlive the workflow or team that needed them.
• Prioritise revocation paths over discovery alone Build a fast route to disable shared logins, tokens, and agent secrets when a workflow changes, because visibility without revocation still leaves access live.

Key takeaways

• Credential sprawl is a workflow governance problem that extends beyond sign-in security into ownership, storage, and revocation.
• AI automation makes unmanaged credentials more dangerous because secrets can be created, reused, and forgotten faster than review cycles can catch them.
• The most effective control shift is to govern credentials at creation time and keep revocation tightly coupled to workflow change.

Key terms

• Credential Sprawl: Credential sprawl is the uncontrolled accumulation of machine secrets, keys, and tokens across systems, teams, and environments. It usually starts with a single use case and ends with overlapping permissions, unclear ownership, and a larger attack surface than the organisation expected.
• 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.
• Lifecycle Governance: Lifecycle governance is the set of controls that cover creation, assignment, review, rotation, and retirement of identities and credentials. For NHIs, it is the difference between a temporary automation asset and a persistent access risk. Strong lifecycle governance keeps ownership and expiry tied to actual business use.
• Federated Sign-In: Federated Sign-In lets a user access one system using credentials managed by another trusted identity provider. Technically, it relies on trust relationships, usually through SAML, OIDC, or similar federation protocols, so the service provider accepts an external assertion about the user’s identity, authentication state, and sometimes group or role attributes.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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.