Your company now has 109 machine identities for every employee, and nobody owns them

Palo Alto Networks surveyed 2,930 cybersecurity leaders for its 2026 Identity Security Landscape report and came back with a number that should worry every CISO: machine identities now outnumber human ones 109 to 1, up from 82 to 1 just a year earlier. ManageEngine's separate Identity Security Outlook, drawn from 515 identity and security leaders, found organizations reporting machine-to-human ratios averaging 100 to 1, with some environments hitting 500 to 1. The exact multiplier varies by methodology, but every serious survey agrees on the direction: the identity population inside a modern enterprise is now overwhelmingly non-human, and it is growing faster than anyone is tracking it.

This matters because identity, not the network perimeter, has become the primary attack surface — and the identity program built to secure it was designed for humans. Provisioning workflows, access reviews, offboarding checklists, and MFA policies all assume a person with a manager, a start date, and an HR record behind them. API keys, service accounts, OAuth tokens, CI/CD pipeline credentials, and now autonomous AI agents have none of that. They get created by a developer in five minutes to unblock a deploy, they inherit broad permissions because narrowing them takes extra work nobody has time for, and they almost never get revoked because no offboarding process exists for a credential that was never “hired” in the first place.

The governance gap is not hypothetical

Palo Alto's report found that 9 in 10 surveyed organizations had suffered a successful identity-related breach in the past 12 months, and 96% of respondents admitted human identities carry access well beyond what their roles require. Machine identities are worse on both counts, because almost nobody is reviewing them at all. A service account created in 2022 to run a one-off data migration typically still holds its original permissions in 2026, because no calendar reminder exists to question it, and no manager gets a quarterly access-review email about a credential instead of a person.

The consequences show up in exactly the incidents security teams are now responding to weekly. A renewed wave of the GhostAction GitHub supply-chain campaign, disclosed by researchers at StepSecurity in October 2026, worked precisely because compromised maintainer accounts carried broad, long-lived push access and had secrets — AWS keys, PyPI publishing tokens, AI provider API keys — sitting in workflow configuration and git history with no expiry and no owner actively watching them. The attack didn't need a zero-day. It needed credentials that had quietly accumulated privilege and gone unreviewed, which describes the median machine identity in most organizations.

Why the AI agent wave makes this worse, not just bigger

Palo Alto's survey projects AI agent deployment growing 85% this year, and each of those agents needs its own credentials to call APIs, read data stores, and take actions on a user's behalf. Unlike a service account that does one narrow job forever, an AI agent's permission needs can change as its task changes, which pushes teams toward either over-provisioning it upfront (the path of least resistance) or building dynamic, scoped-credential issuance (the harder, correct path that almost nobody has built yet). Most organizations are choosing the first option by default, simply because the tooling for the second doesn't exist in their stack.

What an actual inventory looks like

Security teams that have made progress on this problem share a common starting point: they stopped treating “identity governance” as a human-only program and built a separate, explicit non-human identity inventory with four fields that most organizations currently have for zero of their machine credentials — an owner (a specific person, not a team mailbox), a business justification, an expiry date, and a last-used timestamp. Tools exist for this now under the “non-human identity management” (NHIM) category, from vendors like Astrix, Entro, and Token Security, as well as native features inside secret managers like HashiCorp Vault and cloud-provider IAM consoles. None of them fix the problem by installation alone — they only work if someone commits to reviewing what they surface.

Actionable takeaways

• Inventory before you buy tooling. Export every API key, service account, and OAuth grant your cloud provider and CI/CD system know about before evaluating an NHIM platform — most teams are shocked by the count alone, often 10-50x their human headcount.
• Set a default expiry, not a default grant. New service credentials should expire in 90 days unless someone actively renews them with a justification, inverting the current default of permanent access until someone notices.
• Treat AI agent credentials as a new category, not a service-account subtype. Scope them per-task where your tooling allows it, and log every action an agent takes under its own identity, separate from the human who deployed it.
• Assign a human owner to every machine credential during the next access review cycle. A credential with no accountable person behind it is, by definition, orphaned — and orphaned credentials are exactly what attackers like the GhostAction operators are counting on finding.