Machine Identities Now Outnumber Humans and Nobody’s Watching Them

In most organizations today, machine identities far outnumber human ones. Every cloud workload, pipeline, integration and AI agent needs its own way to authenticate, and the count grows with each one that gets built.

The bigger issue is governance. Organizations have clear processes for who gets human access, who approves it and when it ends. Service accounts, API keys, tokens, workload identities, certificates and AI agents mostly sit outside those processes, so many have no owner, no review and no end date.

What is a Machine Identity?

A machine identity represents a non-human actor that needs to authenticate to another system without a person involved. It can be a workload, service, application, device, automation process, pipeline or AI agent.

Credentials such as API keys, tokens, certificates and secrets are what the identity uses to prove itself. Both show up in many forms:

· Service accounts in directories, databases and SaaS platforms

· API keys and personal access tokens used by scripts, integrations and developer tools

· OAuth grants and refresh tokens let one SaaS application act inside another

· Cloud workload identities, such as IAM roles, managed identities and Kubernetes service accounts

· Certificates and SSH keys that authenticate servers, services and devices

· CI/CD credentials let pipelines pull code, push artifacts and deploy infrastructure

· Infrastructure-as-code tools create and change resources through cloud identities

· AI agent identities that let autonomous software call tools and APIs

None of this is a failure in itself; automation can't stop and ask someone to sign in every time two services talk. The gap exists because machine identities are created through engineering workflows, while identity governance was built around people and HR events.

Why Human Identity Controls Don't Transfer

Almost every human identity control depends on an anchor that machine identities lack.

A starting event. A human account begins when HR records a new hire. A machine identity can appear whenever a developer deploys infrastructure, registers an app, creates a token or enables an integration. No authoritative system may record why it exists or how long it should stay.

An ending event. A resignation triggers deprovisioning. A retired application, an abandoned proof of concept or a replaced integration triggers nothing, so its account, token, certificate or key can stay valid long after the workload is gone.

An interactive checkpoint. Human access usually passes through an identity provider that enforces MFA, device checks and conditional access. Machine credentials are built for unattended use and skip those checks. Many are bearer credentials, meaning whoever holds them can use them, unless extra controls bind them to a specific workload or device.

A reviewer who understands it. A manager can say whether an employee still needs access. Reviewing a service principal, a cloud role, a certificate or an API integration means understanding the workload and the permissions it needs. The person who created it may have moved on, and the team running the application may not know why access was granted.

So nobody is watching because the systems that set ownership, trigger reviews and start retirement were never connected to machine identities.

Discovery is Hard Because the Identity Is Fragmented

Human identities mostly live in one central directory. Machine identities are spread across cloud IAM, Kubernetes clusters, secrets managers, certificate stores, SaaS admin panels, CI/CD platforms and source code. Some are formal objects, like a registered application. Others are just strings: a key in an environment variable, a token in a config file, a secret committed to a repository long ago.

Finding an identity also doesn't tell you how it is used. A directory shows that an account exists and what it may do. It rarely shows which workload depends on it or what breaks if it is disabled. That makes cleanup risky, so forgotten identities tend to stay.

What Happens When Identities Are Forgotten

An orphaned machine identity stays active after its purpose, owner or workload is gone. For an attacker it is close to ideal. The credentials are valid, so logins look legitimate. Nobody expects activity from the identity, so nobody reviews it. And it often holds broad permissions that were never trimmed, with no interactive sign-in to challenge it.

The 2025 Salesloft Drift incident shows how this plays out. Google Threat Intelligence Group reported that an actor it tracks as UNC6395 used stolen OAuth tokens tied to the Drift integration to pull data from customers' Salesforce instances. Because the tokens were legitimate, the attacker could act as a trusted application. Google later advised customers to treat every token connected to Drift as potentially compromised.

The same weakness helps attackers who start with a person. After compromising a human account, they can move into cloud and SaaS environments and collect tokens, keys and service account credentials. Depending on the platform, a password reset can leave those untouched, so access continues until someone finds and revokes them.

Excessive Permissions Turn Visibility Gaps Into Larger Incidents

Teams usually configure machine identities to keep automation running. When a job fails because of a missing permission, the fastest fix is to broaden the role. When nobody is sure which API actions an integration needs, wide scopes avoid future breakage. Once granted, those permissions are rarely revisited.

The permissions attached to an identity also show only part of its access. Effective access can come from inherited roles, group membership, delegated OAuth scopes, resource policies, role assumption (one identity temporarily taking on another role's permissions) or workload federation (a workload proving who it is with a token from a trusted platform instead of a stored secret). Evaluating an identity means tracing what it can ultimately reach.

That effective access sets the blast radius, the amount of damage a compromised identity can do. A role that fit at setup drifts as the workload changes, so least privilege for machines has to be checked continuously against what the workload actually does.

How AI Agents Raise the Stakes

AI agents magnify the problems above. Their behavior is harder to baseline, their authority is difficult to trace and their credentials are easier to misuse.

Traditional automation is predictable. A backup job calls the same endpoints on the same schedule. An agent chooses which tools to call, and in what order, at runtime, so its normal behavior varies from run to run.

It also gets unclear whose identity is in use. An agent acting for a user may run with that user's delegated rights, its own service identity, or both, passed through a chain of tools and Model Context Protocol (MCP) servers. If tools in that chain reuse a broad service identity and don't scope authorization at each step, the agent can end up with permissions far beyond the task the user intended.

Agents are quick to build, often by teams outside security and IT, and a prototype often starts with a static key in a config file. An agent that reads untrusted input such as emails, tickets or pull requests can also be steered by prompt injection into using its legitimate credentials for actions its owner never intended. The target system sees an authorized request from a valid identity.

Standards are catching up. Microsoft Entra Agent ID gives agents their own identity type in the directory, and MCP's Enterprise-Managed Authorization extension, which reached stable status this year, lets an organization's identity provider decide which MCP servers a client may reach. These define how access is granted. Deciding who owns an agent, what it may do and when it is switched off remains the organization's job.

What Organizations Need to Change

Machine identities need the same accountability model already expected for human access. In practice, that means binding every non-human identity to a workload, purpose, owner, authentication method, authorization model and retirement event.

Start with Visibility

Inventory machine identities across cloud platforms, applications, APIs, pipelines, Kubernetes, certificate stores and secrets managers.

Make Ownership Part of Issuance

Every identity needs a responsible owner, a stated purpose and a reason for its access. An identity with no owner or explanation should be flagged for review, then restricted or retired if nobody claims it.

Prefer Temporary Access Over Permanent Credentials

Where the platform supports it, use short-lived credentials and workload federation instead of persistent secrets, so exposed or forgotten credentials do less damage and expire sooner. Automate rotation too, but rotating the credential of an identity that shouldn't exist only gives it fresh authentication material.

Tie Permissions to the Workload

Give each identity only the access its workload needs, and review direct permissions, inherited roles, delegated access, resource policies and the ability to assume other identities.

Monitor What Identities Do

Track what each machine identity accessed, compare it with its intended purpose and watch for changes over time. Give each workload its own credential. When several workloads share one, activity can't be traced to a specific identity, and ownership has nothing to attach to.

Set Boundaries for AI Agents

Agents need the same ownership and review as other non-human actors, including their delegation paths and tool access.

Retire Identities with Their Workloads

When an application, pipeline, integration or certificate is decommissioned, remove its identities and credentials in the same change. Because usage is often hard to see, disable the identity first and watch for breakage before deleting it.

The Real Gap Is Accountability

Human identity management rests on five questions asked of every account. Who is this? Why does this access exist? Who approved and owns it? What can it do? When should it end?

Machine identities need answers to the same five, whether they belong to workloads, services, API clients, pipelines or agents. Until organizations can answer them, those machines are authenticated and authorized, but nobody is accountable for them.