ISPM for machine identity sprawl in the age of agentic AI

At a glance

What this is: This is an independent analysis of how ISPM helps control machine identity sprawl, with the key finding that AI adoption is multiplying NHIs faster than most identity programmes can inventory, govern, and rotate them.

Why it matters: It matters because IAM teams now have to govern service accounts, API keys, tokens, certificates, and agentic AI access through the same lifecycle discipline, or risk losing visibility and control across machine and human identity estates.

By the numbers:

• CyberArk's 2025 research reveals that machine identities now outnumber humans by more than 80 to 1.
• Security leaders expect up to 150% growth in the next year.
• 68% of organizations lack proper identity security controls for AI.

👉 Read Oasis Security's guide to kickstarting an ISPM program

Context

Machine identity sprawl is the accumulation of service accounts, API keys, tokens, and certificates faster than teams can see, govern, and retire them. In this article, Oasis Security argues that the core problem is not just volume, but the absence of a repeatable identity security and privileged management model for NHIs and agentic AI.

That framing fits the current IAM reality. Discovery is incomplete, ownership is often unclear, rotation is inconsistent, and shadow AI introduces credentials outside normal control planes. For most programmes, the gap is already operational rather than theoretical, which makes lifecycle governance the first control problem, not the last.

Key questions

Q: How should security teams implement ISPM for machine identities?

A: Start with discovery, then classify machine identities by privilege, age, ownership, and reuse. After that, enforce rotation, unique credentials, just-in-time access, and continuous monitoring. ISPM works best when it is tied to lifecycle governance, because the goal is not just visibility but enforced reduction of standing risk across service accounts, tokens, keys, and certificates.

Q: Why do machine identities create more governance risk than human accounts in cloud environments?

A: Machine identities are created faster, used more frequently, and reviewed less consistently than human accounts. They also often have standing access and weak ownership, which makes them easy to forget and hard to retire. That combination expands blast radius and increases the odds that a leaked key or stale service account remains exploitable.

Q: What breaks when secrets are not rotated in machine identity programmes?

A: Unrotated secrets create long-lived access paths that survive application changes, ownership changes, and even some detection efforts. If a key is exposed or copied, the attacker can often keep using it until someone notices and revokes it. That is why rotation must be automated and paired with revocation, not treated as an occasional housekeeping task.

Q: What should teams do when shadow AI starts using credentials outside normal control paths?

A: Bring shadow AI into the same identity governance process as other NHIs. Map which credentials the models use, who owns them, and whether they can be rotated, expired, or restricted. If AI usage sits outside the lifecycle record, the programme has a blind spot that policy alone will not close.

Technical breakdown

Discovering machine identities across cloud, on-prem, and hybrid estates

ISPM begins with inventory because identity control cannot start without visibility. Machine identities include service accounts, API keys, tokens, secrets, and certificates, and they often exist outside the places IAM teams usually monitor. Discovery has to span cloud, on-prem, CI/CD, developer workstations, and shadow AI environments. The mechanism matters because ownership, rotation, and privilege decisions all depend on knowing what exists, where it is used, and whether it is still active. Without that baseline, every later control becomes partial and reactive.

Practical implication: build a cross-environment discovery process that finds identities before you try to govern them.

Risk assessment for overprivileged, stale, and shared credentials

Once identities are inventoried, the next technical step is to classify risk by access scope, age, reuse, and business function. Overprivileged identities enlarge blast radius, stale identities create persistence, and shared credentials erase accountability. The article also points to agentic and local AI use as a new blind spot because credentials may be requested or consumed outside standard review paths. That is a governance problem as much as a technical one, because policy only works when the identity subject is known and the lifecycle state is current.

Practical implication: rank machine identities by privilege, age, and reuse so remediation targets the highest-risk credentials first.

Automation, JIT access, and continuous monitoring in ISPM

Manual machine identity management does not scale because credential volume and change frequency exceed human review cadence. ISPM therefore depends on automated rotation, just-in-time access, and continuous monitoring for anomalous usage such as a key appearing from a new geography or an unusual runtime context. The technical pattern is closed-loop governance: detect, decide, enforce, and re-check. That loop reduces standing privilege and shortens exposure windows, but only if automation is tied to policy and not used as a substitute for ownership or lifecycle discipline.

Practical implication: automate rotation and expiry, then monitor for anomalies that indicate a credential has drifted outside its intended use.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.

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

NHI Mgmt Group analysis

ISPM is now the control plane for machine identity sprawl, not a niche hygiene programme. The article describes a world where NHIs, secrets, and AI access outgrow manual administration faster than teams can review them. That means the discipline is shifting from point fixes to lifecycle governance across service accounts, keys, and certificates. Practitioners should treat ISPM as a core identity operating model, not an auxiliary toolset.

Secret rotation without discovery is incomplete governance. If you cannot find the identity, you cannot rotate it, attest it, or retire it. That is why the article's emphasis on inventory is more than a checklist item, it is the prerequisite for every control downstream. The conclusion for practitioners is simple: control quality is bounded by discovery quality.

Shadow AI turns machine identity into an accountability problem. Local models and agentic workflows can consume credentials outside standard visibility, which means policy enforcement can be bypassed without any obvious security event. This is where NHI governance and AI access governance converge. The implication is that identity teams must align ownership, policy, and runtime visibility before AI usage becomes structurally ungoverned.

Identity blast radius is the right way to think about machine identity risk. Overprivileged, shared, and stale credentials all expand the blast radius when one identity is misused or exposed. The article's remediation path points toward reducing that blast radius through least privilege, unique identities, and tighter lifecycle control. Practitioners should measure machine identity risk by how far one credential can reach, not just by how many exist.

From our research:

• 68% of organizations lack proper identity security controls for AI, according to OWASP NHI Top 10.
• Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, according to The State of Secrets Sprawl 2026.
• See how identity scope changes across humans, NHIs, and autonomous systems in Ultimate Guide to NHIs , What are Non-Human Identities.

What this signals

Identity blast radius is the operational metric that matters here. As machine identities proliferate, the question is no longer whether a secret exists, but how far it can reach, how long it lives, and whether it can be traced back to a current owner. Programme teams should align discovery, ownership, and expiry into one lifecycle record so remediation can actually move.

With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, the control problem is now extending into agent tooling and integration layers, not just code repositories. That makes runtime visibility and policy enforcement essential for anyone governing AI-connected systems.

The next phase of identity governance will reward teams that can unify machine, human, and agent access reviews without creating separate exceptions for each actor type. That is where lifecycle discipline becomes a security control, not an administrative burden.

For practitioners

• Discover every machine identity across all environments Start with a unified inventory for service accounts, API keys, tokens, secrets, and certificates across cloud, on-prem, CI/CD, and developer-managed AI workspaces. Assign ownership, usage context, and business criticality before you attempt remediation.
• Prioritise high-risk identities for immediate cleanup Target overprivileged, shared, stale, and unrotated credentials first, because those are the identities most likely to create persistent access and broad blast radius. Remove dormant accounts and replace shared secrets with unique identities where possible.
• Automate rotation and expiry for standing secrets Use policy-driven rotation, expiry, and just-in-time issuance so access is temporary and task-scoped rather than persistent. Tie automation to ownership and exception handling so the control remains auditable.
• Add shadow AI to your identity risk review Include local AI usage and agentic workflows in access reviews so credentials consumed outside the normal control plane are still visible to governance teams. Treat new runtime contexts as part of the identity perimeter, not outside it.
• Monitor for anomalous credential use patterns Track geolocation changes, unusual runtime contexts, and unexpected service-to-service access so you can detect when a machine identity has drifted beyond its intended use. Anomaly detection should feed back into the lifecycle record, not sit in a separate security silo.

Key takeaways

• Machine identity sprawl is already a governance problem, not a future-state risk.
• Discovery, ownership, and rotation are the controls that determine whether ISPM reduces blast radius or just documents it.
• Shadow AI makes identity governance cross-domain, so teams need one lifecycle model for humans, NHIs, and autonomous workflows.

Key terms

• Machine Identity: A machine identity is a non-human credential used by software, services, or infrastructure to authenticate and access resources. In practice it includes service accounts, API keys, tokens, and certificates, all of which need ownership, scope, and lifecycle control to stay governable.
• Identity Security And Privileged Management: Identity Security and Privileged Management is the discipline of discovering, governing, and reducing risk across privileged machine identities. It combines inventory, policy, rotation, and monitoring so organisations can control non-human access at scale rather than rely on manual review.
• Shadow AI: Shadow AI is AI usage that happens outside approved identity and security controls. It creates governance blind spots because models can consume credentials, data, or tools without being captured in standard inventory, ownership, or access review processes.
• Identity Blast Radius: Identity blast radius is the amount of systems, data, and privileges that can be reached if one identity is misused or exposed. For machine identities, it is shaped by scope, reuse, standing access, and how quickly the credential can be rotated or revoked.

Deepen your knowledge

Machine identity discovery, rotation, and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building an ISPM programme from the same starting point, it is worth exploring.

This post draws on content published by Oasis Security: Taming the Machine Mayhem: 5 Steps to Kickstart Your ISPM Program. Read the original.