Why 82% of enterprise attack surface stays invisible to IAM

At a glance

What this is: This analysis argues that most enterprise attack surface remains invisible to IAM because machine identities are proliferating faster than governance models can track them, especially in AI and development domains.

Why it matters: IAM, PAM, and NHI programmes have to move from system-by-system control to domain-level governance if they want to see where credentials are created, inherited, and left exposed.

By the numbers:

• Organizations now manage 82 machine identities for every human user in the enterprise, according to Clutch Security.

Context

Enterprise attack surface visibility is no longer limited by tooling alone. The harder problem is that business functions keep creating non-human identities faster than security programmes can classify, govern, and retire them.

In this article, Clutch Security argues that AI, development, supply chain, and productivity workflows are producing large pools of machine identities with different risk profiles, while security teams keep spending more time on mature domains with lower marginal risk. That creates an identity governance problem, not just a monitoring problem.

The result is a widening gap between where access is generated and where security attention lands. For IAM, PAM, and NHI teams, the issue is whether controls can follow business-created access across domains instead of assuming infrastructure boundaries will contain it.

Key questions

Q: What breaks when machine identities are created inside business workflows without IAM ownership?

A: Ownership, rotation, and offboarding all become ambiguous, so credentials persist after the business need changes. That is where invisible attack surface forms: the identity exists, but no one can explain who approved it, who maintains it, or when it should be retired.

Q: Why do AI and development domains create more machine identity risk than mature corporate IT environments?

A: They create identities faster, with broader privileges and less consistent lifecycle governance. Mature domains tend to have clearer review processes and better tooling, while AI and development often optimise for speed, which leaves credential scope and retirement poorly controlled.

Q: What are the signs that machine identity management is failing in an organisation?

A: Common signs include incomplete inventory, spreadsheet based tracking, manual renewal processes, unclear ownership, and repeated certificate expiry events. Another signal is when teams struggle to audit where machine identities exist or cannot automate lifecycle actions at scale. If operational teams keep reacting to expiring certificates instead of governing identity lifecycles proactively, the control environment is already under strain.

Q: How should security teams respond when machine identities span multiple business domains?

A: Treat cross-domain credentials as a separate governance class and review them for delegated scope, overlapping privileges, and ownership gaps. A machine identity that can cross from AI into development or production should be monitored as a blast-radius problem, not as a normal account.

Technical breakdown

Why business functions create invisible NHI sprawl

Machine identities are not only created by infrastructure teams. SaaS integrations, developer workflows, AI automations, and vendor relationships each mint OAuth tokens, API keys, service accounts, and long-lived secrets as part of ordinary business activity. The visibility gap appears when those identities inherit access from the workflow that created them, not from an identity governance process. In practice, that means security teams may know the system exists but not who owns the credential lifecycle, what it can access, or when it should be retired.

Practical implication: Map NHI creation to business workflows, not just platforms, so ownership and offboarding can be assigned at the point of issuance.

Why domain-level risk matters more than infrastructure tiers

Traditional security taxonomies organise by cloud, SaaS, or on-premises, but the article’s central point is that risk clusters around business domains such as AI and development. Those domains generate more credentials with less governance, which makes them more attractive than mature environments with heavier monitoring. This is a control-design problem: the same IAM pattern does not work equally well when one domain has high velocity and another has stable, well-instrumented access. The governance question is not where the asset runs, but how the identity was created and whether it can be continuously accounted for.

Practical implication: Use domain-based risk tiers to prioritise review, rotation, and lifecycle controls where identity creation is fastest and oversight is weakest.

Why mature IAM controls miss machine identity blast radius

IAM controls were built around relatively stable human accounts, but machine identities often multiply through delegation chains and integrations. A single user action can create multiple downstream identities, each with a different privilege scope and persistence model. That creates hidden blast radius when one exposed token or service account can reveal other secrets, reach adjacent systems, or outlive the business need that created it. The governance failure is treating those identities as technical by-products instead of governed assets.

Practical implication: Inventory delegated and inherited access paths separately from primary accounts so machine identity blast radius can be bounded before abuse occurs.

Threat narrative

Attacker objective: The attacker wants to turn one overlooked machine identity into broader enterprise access by chaining hidden credentials and under-governed privileges.

1. Entry begins when business workflows create OAuth tokens, service accounts, API keys, or other machine identities with broad access and weak ownership.
2. Escalation follows when attackers compromise one high-value NHI, then use its privileges to discover credentials, internal architecture, or adjacent access paths.
3. Lateral movement occurs as those credentials open development, production, or user-facing systems that were never governed as one identity estate.
4. Impact is enterprise-wide exposure through persistent access, credential reuse, and cross-domain privilege expansion that security teams never fully saw.

Breaches seen in the wild

• Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.
• United Nations breach 2021: Sakura Samurai used exposed Git credentials to reach 100,000+ UNEP staff records, then reported the flaw through the UN disclosure programme.

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

NHI Mgmt Group analysis

Attack surface visibility breaks when identity creation shifts into business workflows. Security teams still organise around systems, but the article shows that the real source of NHI growth is workflow-driven access creation inside sales, DevOps, legal, and AI operations. That means the inventory problem is really an ownership and lifecycle problem. Practitioners should stop treating visibility as a scan result and start treating it as a governed process boundary.

Domain risk is now more important than infrastructure location. AI and development domains generate the highest-risk machine identities because they combine velocity, broad privileges, and weak governance. Mature environments like corporate IT may be easier to observe, but that does not mean they are where the marginal risk sits. The implication is that IAM programmes need a domain-risk model, not a platform-only model.

Ephemeral credential trust debt: the organisation keeps inheriting access it never explicitly approved. OAuth tokens, service accounts, and API keys accumulate because business teams optimise for delivery, not identity lifecycle discipline. Each new integration adds trust that may never be revisited. Practitioners should treat inherited machine access as a balance sheet item, because the exposure window grows every time lifecycle ownership is implicit instead of explicit.

NHI lifecycle governance has outgrown account-centric IAM assumptions. Controls built for stable human identities do not account for credentials created by applications, vendors, and AI workflows at machine speed. That is why visibility projects stall when they are mapped only to directories or cloud accounts. The next governance layer has to follow creation, delegation, rotation, and retirement across every business domain.

Cross-domain privilege is the real blast-radius multiplier. The article’s risk model shows that a compromise in one domain can reveal secrets, architectures, or access paths that unlock others. That is not a tooling failure alone, it is a governance model that assumes identities stay inside one operational lane. Practitioners need to design controls around cross-domain linkage, because that is where enterprise-scale exposure starts.

From our research library:

• NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
• 42% of machine identities have privileged access and 61% of organisations lack identity security controls for cloud workloads, according to CyberArk's 2025 Identity Security Landscape.
• Read next: Identity Convergence Guide

What this signals

Domain-aligned governance is the real next step. The article’s strongest signal is that security teams need to stop organising NHI controls only by platform and start organising them by business function. That is where creation, ownership, and retirement actually happen, and that is where visibility failures begin.

Machine identity lifecycle has become a board-relevant risk metric. When AI, development, and supply chain workflows keep generating secrets outside traditional IAM process boundaries, the question is no longer whether the environment has enough scanners. The question is whether the organisation can prove who owns the credential, why it exists, and when it will be removed.

Attack surface governance now depends on cross-domain linkage. Identity teams need to know how one token or service account can unlock other systems, because the blast radius is rarely confined to the original workflow. That makes delegated access mapping a practical requirement, not an abstract design preference.

For practitioners

• Audit identity creation by business workflow Inventory where OAuth tokens, service accounts, API keys, and other machine identities are created inside sales, development, legal, AI, and vendor workflows. Record owner, purpose, scope, and retirement trigger for each.
• Prioritise governance in high-velocity domains Assign stricter lifecycle review to AI and development domains first, because they combine rapid credential growth with weak oversight and elevated privileges.
• Separate delegated access from primary accounts Map downstream credentials and inherited access paths independently so one user action does not hide multiple machine identities with different blast radii.
• Rotate and revoke machine secrets by ownership Tie rotation and revocation to the business owner of the workflow, not to the system team that stores the secret, so stale access is actually retired.
• Build cross-domain monitoring for NHI movement Correlate machine identity activity across development, production, user, and supply-chain domains to spot credentials that move beyond their original business context.

Key takeaways

• Machine identity sprawl is being created by business workflows faster than IAM programmes can assign ownership or lifecycle control.
• The biggest risk sits in AI and development domains, where credentials grow quickly and governance is weakest.
• IAM teams need domain-level visibility, not just platform inventory, if they want to reduce machine identity blast radius.

Key terms

• Machine Identity Sprawl: Machine identity sprawl is the uncontrolled growth of non-human identities across teams, platforms, and business processes. It becomes a governance problem when identities are created faster than they can be inventoried, reviewed, rotated, or retired, leaving security teams with incomplete visibility and weak accountability.
• Domain-Based Governance: An identity governance model that groups risk by business function rather than by infrastructure tier. It is useful when the same control failure looks different across AI, development, supply chain, and production workflows, and when credential creation happens outside central IAM processes.
• Cross-domain privilege path: A chain of permissions that moves access from one identity domain to another, such as from a developer account into cloud administration or a CI/CD pipeline. These paths matter because attackers often use inherited or linked permissions rather than direct admin compromise.
• Ephemeral Credential Trust Debt: Ephemeral credential trust debt is the hidden risk that appears when short-lived tokens create a false sense of safety while permissions remain broad. The credential expires quickly, but the underlying blast radius stays large unless identity scope, revocation, and audit controls are also tightened.

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.