Executive Overview

Every enterprise API call, cloud service integration, and CI/CD pipeline step is authenticated by something, and increasingly that something is not a human. Research from Rubrik Zero Labs puts the ratio of machine identities, service accounts, API keys, and workload credentials, to human identities at roughly 45 to 1 in the modern enterprise, while Entro Labs' research into cloud-native and DevOps-heavy environments specifically puts the ratio closer to 144 to 1 [1][2]. CyberArk's 2025 State of Machine Identity Security Report, based on a survey of 1,200 security leaders, found that 50% of organizations have already reported a breach linked to a compromised machine identity, with API keys and TLS certificates leading as the primary vectors [3]. This Expert Insight argues that machine identity is not a subset of API security or cloud security. It is the connective layer underneath both, and it is currently the least governed identity category in most enterprise environments.

Core Insight

Human identity governance has matured substantially over the past decade: multi-factor authentication, conditional access, and regular access reviews are now standard practice at most enterprises. Machine identity has not received the same treatment. A service account or API key is typically created once, granted broad permissions to avoid follow-up requests, and then left untouched for the lifetime of the system it supports, which is frequently years. GitGuardian's 2026 State of Secrets Sprawl report found 28.65 million new hardcoded secrets pushed to public GitHub repositories in 2025 alone, a 34% year-over-year increase, and found that AI-assisted code commits leak secrets at roughly twice the rate of human-written commits [4].

Figure 1. Machine-to-human identity ratio by source, 2026 research.

Market Context

The scale of exposed machine credentials in circulation is no longer a theoretical concern. SpyCloud's 2026 Identity Exposure Report recaptured 18.1 million exposed API keys and tokens in 2025 alone, spanning payment platforms, cloud infrastructure providers, developer ecosystems, and AI services, alongside 6.2 million credentials or authentication cookies specifically tied to AI tools [5]. Google Cloud's Cloud Threat Horizons Report H1 2026 found that identity compromise underpinned 83% of cloud-related compromises its research team analyzed, a figure that dwarfs any single technical vulnerability category [6].

A May 2026 incident illustrates the practical stakes. Braintrust, an AI infrastructure provider, disclosed unauthorized access to an AWS account storing API keys that customers used to access cloud-based AI models. The company locked down the account, audited related systems, and rotated internal secrets, and while the confirmed impact was limited to a small number of customers, the incident is a clean illustration of a pattern security researchers describe consistently: a leaked machine credential does not require a sophisticated exploit to cause damage, only for someone to find it before the owning organization notices it is exposed [7].

Machine Identity Incident Data at a Glance

Source

Finding

CyberArk (2025 survey, 1,200 orgs)

50% reported a breach linked to a compromised machine identity; 42% lack a unified governance approach [3]

SpyCloud (2026)

18.1 million exposed API keys and tokens recaptured in 2025; 6.2 million credentials tied to AI tools [5]

GitGuardian (2026)

28.65 million new hardcoded secrets pushed to public repositories in 2025, up 34% year-over-year [4]

Google Cloud Threat Horizons (H1 2026)

Identity compromise underpinned 83% of analyzed cloud-related compromises [6]

 

Why This Is Specifically an API Problem

Machine identity and API risk are not two adjacent concerns that happen to interact occasionally; machine identities are, in practice, how the overwhelming majority of API calls between services get authenticated in the first place. Every internal microservice calling another, every integration pulling data from a partner API, and every AI agent invoking a tool is doing so using a service account, an API key, or an OAuth token, not a human login. This means the machine identity governance gap described above is not a separate finding from the API attack surface trend this campaign has already established; it is the mechanism underneath it. Wallarm's finding that broken authentication accounts for the majority of analyzed API breaches, and Verizon's finding that third-party involvement now appears in 48% of breaches, both describe outcomes that machine identity failures, an over-permissioned key, an unrotated token, an orphaned service account, directly produce.

DZone's 2026 analysis of machine identity incidents documented a supply-chain attack against a widely used CI/CD automation component relied on by more than 23,000 repositories, which scraped cloud provider keys, developer platform tokens, and private cryptographic keys directly out of build workflow logs, a pattern that required no vulnerability in any single API, only the ordinary practice of machine credentials sitting in places they should not have persisted [8]. Incidents like this illustrate why machine identity cannot be governed solely at the API gateway; the credentials themselves move through build pipelines, code repositories, and configuration files long before, and often long after, they are used to call an API.

Strategic Interpretation

Machine identity governance vs. human identity governance

Practice

Typical Human Identity Governance

Typical Machine Identity Governance

Multi-factor authentication

Standard and enforced

Rarely applicable; credential alone often suffices

Credential rotation

Periodic, policy-driven

Frequently never, once initially issued

Ownership tracking

Tied to an active employee record

Often untracked once the creating engineer moves on

Offboarding trigger

Employee departure automatically revokes access

No equivalent trigger; access persists indefinitely

 

This asymmetry is the central strategic problem, not a footnote to it. Every governance discipline enterprises apply confidently to human users, from MFA to lifecycle-based offboarding, has no consistent equivalent for machine identities, even though machine identities now outnumber human ones by a wide margin and, per CyberArk's data, are already implicated in half of reported breaches [3].

Enterprise Implications

Three implications follow directly. First, API and cloud security programs that do not explicitly include machine identity governance are addressing only part of the access layer that actually matters; credentials, not code vulnerabilities alone, increasingly determine how far an attacker can move once any foothold is gained. Second, the volume problem compounds over time: with 79% of organizations in CyberArk's survey anticipating a machine identity increase of up to 150%, governance debt accumulated today will be materially larger, not smaller, within the next planning cycle [3]. Third, AI agents are a new and fast-growing category of machine identity consumer, and SpyCloud's finding of 6.2 million AI-tool-linked credentials already in circulation suggests this category is not a future risk to plan for but a current one to address [5].

There is also a budgeting implication worth stating plainly. Most enterprise identity security spending has historically concentrated on human identity and access management, single sign-on, MFA enforcement, and privileged access management for employee accounts, categories that are comparatively mature and well-funded. Machine identity security tooling remains a newer, less consolidated market, and CyberArk's finding that 42% of organizations lack a unified approach reflects that immaturity directly [3]. Closing the gap described in this Expert Insight is therefore as much a budget and ownership question as a technical one; someone in the organization needs explicit accountability for a credential population that is now dramatically larger than the human identity population it has historically been compared against.

CyberTech Intelligence Perspective

CyberTech Intelligence's assessment is that machine identity should be treated as its own governance domain, not folded silently into either API governance or cloud security posture management, because it has a distinct lifecycle, a distinct set of controls, and a distinct failure mode. An API can be well-designed and a cloud environment well-configured, and an enterprise can still be breached because the credential connecting the two was created once, over-permissioned, and never revisited. Closing this gap does not require waiting for a new control category to mature; it requires applying the same discipline, inventory, ownership, rotation, and revocation, that already exists for human identities, to a population of credentials that is now roughly 45 to 144 times larger.

Figure 2. Machine identity risk perception vs. reality, CyberArk 2025 survey of 1,200 security leaders.

Executive Actions

  • Inventory all service accounts, API keys, and workload credentials with the same rigor applied to human user accounts, including a named owner for each.
  • Establish a mandatory rotation cadence for machine credentials rather than leaving rotation to be triggered only by an incident.
  • Extend offboarding processes to explicitly cover machine identities tied to departing engineers, decommissioned projects, and retired integrations.
  • Require explicit review before granting broad or standing permissions to any new service account, rather than defaulting to broad scope to avoid follow-up requests.
  • Extend machine identity governance explicitly to AI agent credentials now, given SpyCloud's data showing millions of AI-tool-linked credentials already exposed.

Conclusion

Cloud and API security conversations that focus on code vulnerabilities and configuration settings while treating machine identity as a secondary concern are addressing a shrinking share of the actual risk. The evidence reviewed here, from the 45-to-1 and 144-to-1 identity ratios research firms report, to CyberArk's finding that half of surveyed organizations have already experienced a machine-identity-linked breach, to the Braintrust incident's plain illustration of the mechanism, points to the same conclusion: machine identity is where API risk and cloud risk actually converge, and it remains the least governed layer connecting them. Closing that gap does not require a new security discipline invented from scratch; it requires applying the governance rigor already proven on the human identity side to a population of credentials that, by any current estimate, is now dramatically larger.

Strengthen Machine Identity Governance with CyberTech Intelligence

CyberTech Intelligence helps security and identity leaders extend governance discipline to machine identities, closing the gap between mature human identity programs and the far larger, far less governed population of service accounts, API keys, and AI agent credentials underneath them.

To assess your organization's machine identity governance maturity, connect with CyberTech Intelligence for a Machine Identity Governance Review.

Connect With Us

References

[1] Rubrik Zero Labs. Machine Identity Research. Rubrik, 2026.

[2] Entro Labs. H1 2025 Non-Human Identity Research. Entro Security, 2025.

[3] CyberArk. 2025 State of Machine Identity Security Report. CyberArk, 2025. https://www.cyberark.com/state-of-machine-identity-security-report/

[4] GitGuardian. State of Secrets Sprawl 2026 Report. GitGuardian, 2026.

[5] SpyCloud. 2026 Identity Exposure Report. SpyCloud, 2026.

[6] Google Cloud. Cloud Threat Horizons Report H1 2026. Google Cloud, 2026.

[7] Rescana. Braintrust AWS Data Breach Prompts Urgent API Key Rotation for AI Platform Customers. Rescana, 2026. https://www.rescana.com/post/braintrust-aws-data-breach-prompts-urgent-api-key-rotation-for-ai-platform-customers

[8] DZone. Machine Identity Debt and Cloud Security. DZone, 2026. https://dzone.com/articles/machine-identity-debt