The AI boom’s hidden cost: Managing millions of machine and non-human identities

TL;DR

AI and automation generate thousands of short-lived machine identities, making secrets sprawl hard to avoid. Traditional IAM and vault tools struggle to keep up. To reduce risk, enforce least privilege, use short-lived credentials, and centralize identity policies. Doppler helps you manage non-human access with automation and visibility at scale.

In the past, identity and access management (IAM) were tied to long-running services or human users. Over time, infrastructure and workflows became more dynamic, with short-lived tasks, automated processes, and distributed systems. To make that manageable, we introduced non-human identities like service accounts, API keys, and auth methods that could hold and use secrets without human involvement.

But AI and automation have pushed things into overdrive. Thousands of identities are created, used, and discarded, often in seconds. Your system now risks leaking credentials, spreading access too broadly, or leaving behind stale secrets attackers can find, unless you tighten how secrets are issued and how non-human identities are scoped.

How identity sprawl starts

Suppose you’ve worked in DevOps long enough. In that case, you’ve seen identity sprawl firsthand: dozens of service accounts with unclear owners, IAM roles piling up with overlapping permissions, and no one quite sure which automation script created what. It often begins with moving fast, i.e., standing up new services, spinning up temporary roles, and giving containers a bit more access to get things working. Do that a few dozen times across teams, and sprawl takes hold.

Identity sprawl happens when an organization piles up too many digital identities, human and non-human, without clear tracking or control. At that point, it's hard to know which identity has access to what service. Here are four common ways it builds up.

Integrations and data access workflows

AI applications deeply integrate with internal and third-party APIs, data pipelines, and business tools. To enable this, developers set up service accounts, issue API keys, configure OAuth flows, and embed access credentials into scripts and configs. These identities accumulate without a central inventory or expiration strategy. Most teams don’t centralize these flows, meaning secrets are hardcoded, reused, or copied between services without visibility. All of these weaken endpoint security and increase the chance of security breaches.

Cloud infrastructure and automated processes

AI workloads run heavily on cloud infrastructure such as GPU instances, storage buckets, model training pipelines, and APIs. Managing access to all of this requires setting up IAM roles, policies, service accounts, and key-based access. As you add more components, your cloud identities continue to increase. Without a clear strategy, this growth creates serious security risks that leave your organization blind to who has access to what across cloud environments. For example, if a service account tied to an AI pipeline gets compromised, attackers could escalate user privileges or exfiltrate sensitive data without being noticed.

DevOps and MLOps pipelines

In addition to cloud infrastructure sprawl, identity sprawl also appears in the automation layers that orchestrate and deploy services, such as DevOps and MLOps pipelines.

AI projects rely on automated pipelines to train models, validate data, deploy services, and monitor performance. These pipelines need credentials to interact with cloud storage, databases, model registries, and container platforms. Teams often generate service accounts or embed secrets directly into pipeline configs to keep things moving. This builds up a collection of machine identities, temporary keys, and static tokens that rarely get rotated or cleaned up.

Many of these identities have privileged access and operate with minimal oversight, making them ideal targets for attackers. If one pipeline gets compromised, it can inject malicious models, expose secrets, or deploy unauthorized infrastructure. What makes it worse is the lack of traceability; logs often show activity under vague pipeline or service account names, with no real link to who triggered what.

Self-service machine identities

Not every identity is created through official channels. Developers often create their own cloud projects, test environments, or SaaS accounts without involving the security or infrastructure teams. Because these identities aren’t tracked centrally, they stay hidden from audits and security checks. These unsanctioned efforts are a form of shadow IT and create some of the riskiest forms of identity sprawl because they happen entirely outside of security and compliance policies.

Why traditional IAM and vault tools fall behind

IAM and vault systems were built for static infrastructure, such as human logins and predictable services. AI workloads are the opposite. These workloads need temporary, scoped credentials that match their lifespan, but most IAM systems can’t handle that level of automation or granularity. So, teams fall back on shared credentials or manually managed accounts, both creating sprawl.

Beyond just issuing access, there’s the problem of tracking it. Traditional IAM systems show who has access but not why, how often it's used, or whether it's still relevant. In AI workflows, permissions granted for one experiment are rarely cleaned up. Without continuous analysis of usage patterns, most IAM tools can’t detect over-permissioned identities or unused credentials, resulting in many security holes that are never audited or cleaned up. Plus, these tools lack up-to-date information on how identities behave across changing environments, leading to poor decision-making.

Additionally, traditional secrets management tools were designed for simpler environments, where everything lived in one cloud and one toolset. In contrast, AI systems don’t live in one place. They span across multiple clouds, SaaS tools (GitHub, Slack), and ML platforms (Hugging Face, notebooks, etc.). The older IAM tools can’t keep up because they weren’t made to handle that level of sprawl and integration complexity.

What good access management looks like

To get ahead of identity sprawl, you need systems and practices that treat non-human access with the same rigor as human access. Here are four key areas to focus on, along with practical steps to put them into action.

Centralized policy and identity management

Managing access across multiple clouds, tools, and platforms in silos leads to inconsistent policies and blind spots. To avoid this, centralize how you define, issue, and enforce identity policies. Use federated identity systems, policy-as-code tools, or a unified control layer to bring everything under one view. Use a control layer like Doppler or policy-as-code tools (e.g., OPA) to ensure every identity, even a short-lived job, is scoped, versioned, and audited. This setup makes it easier to control access, apply consistent rules, and audit identities across your entire environment.

Enforce least privilege by default

Every identity should start with zero access. Only grant the permissions it actually needs to perform its job. Block default roles at the policy level. Set up automated scans to reject new service accounts with admin.* patterns. Define tight permission scopes, use role boundaries, and regularly audit access levels. Audit identity permissions weekly and expire unused scopes aggressively. This way, you reduce the risk of lateral movement or privilege escalation if an identity is ever compromised.

Use short-lived credentials

Long-lived credentials are risky. They often get reused, leaked, or forgotten and can outlive the systems that rely on them. Replace them with short-lived and automatically generated credentials that expire after use. Use secrets management tools to issue time-bound access tied to specific workloads across cloud environments. For example, instead of long‑running secrets or API tokens, you can use the Doppler CLI to generate a short‑lived service token like this:

This creates a token that expires automatically (in this case, after 1 minute) and avoids storing long-lived credentials. With such a setup, you limit the window of exposure and make credentials far less useful if stolen. Short-lived credentials also help enforce secure communication between services by reducing reliance on static secrets.

Automate secret rotation and cleanup

Make rotation and revocation a first-class part of your access strategy, not an afterthought. Without regular cleanup, it’s easy to lose track of what identities are still valid or needed. Set up automated secret rotation using tools that support time to live (TTLs), expiration policies, and scheduled cleanup. Remove inactive service accounts, expired tokens, and unused keys as part of your regular CI/CD hygiene. Don’t stop at credentials. Make sure you rotate internal certificates as well. Treating automated rotation and revocation as a baseline requirement is how you prevent the slow accumulation of unused credentials and avoid unmanageable access sprawl.

Why you need a secrets manager

Secrets managers are your first line of defense when it comes to machine identity hygiene. Tools like Doppler help you centralize how secrets such as API keys, tokens, and credentials are stored, accessed, and rotated across environments.

Doppler treats secrets like first-class infrastructure. It keeps them automated, scoped, and observable. Instead of hunting for static tokens in CI configs, you can:

• Inject per-job credentials that expire automatically
• Sync secrets across environments in real time
• Track which identity used what secret and when
• Enforce access policy without needing to write Terraform

Want to see how Doppler simplifies secrets management, protects data, and reduces identity sprawl? Try a live demo to get started.