Zero Trust Security

The Non-Human Identity Problem: Service Accounts, API Keys, and the Credentials Nobody Governs

Service accounts, API keys, and automation credentials now outnumber human user accounts in most enterprise environments. They are also dramatically less governed. The result is one of the fastest-growing attack surfaces in enterprise security.

The Scale of the Problem

The ratio of non-human to human identities in enterprise environments has been rising for years. Cloud infrastructure, DevOps pipelines, microservices architectures, robotic process automation, and now AI agents have all contributed to an explosion in programmatic credentials. Research from several identity security vendors in 2023 and 2024 suggested that non-human identities outnumber human ones by ratios of 10:1 to 45:1 in mature enterprise environments.

The governance structures applied to these identities lag dramatically behind. Human user accounts typically flow through a provisioning process: HR creates a record, IT provisions access based on role, manager approves, and access is revoked when the employee leaves. Service accounts and API keys are frequently created ad hoc by developers or operations teams to solve an immediate problem, granted broad permissions because it is faster than scoping them precisely, and never revisited.

The credential that was created to solve a one-week project three years ago is still active. It has production database access. Nobody knows it exists.

How Attackers Exploit Non-Human Identities

Non-human credentials are attractive targets for several reasons. They rarely rotate. They typically have broad access. They are not subject to MFA challenges. And when they are compromised, there is often no anomaly detection tuned to their behaviour patterns — nobody notices that a service account which normally processes invoices is now querying the HR database at 3am.

The attack patterns are well-documented. Credentials exposed in source code repositories — a persistent problem despite years of tooling to prevent it. Credentials stolen from CI/CD pipeline environment variables. Long-lived API tokens exfiltrated from compromised developer workstations. Overly permissive cloud IAM roles that can be assumed by workloads running in compromised environments.

In each case, the attacker gains a credential that looks legitimate, operates within normal authentication patterns, and can traverse the environment with the permissions the credential carries. Traditional anomaly detection struggles because the credential is doing what credentials do — authenticating and accessing resources.

The Governance Gap

The root cause of non-human identity risk is governance, not technology. The technology to manage service account credentials securely exists. Secrets managers, short-lived token systems, workload identity federation — all mature capabilities. The gap is that most organisations do not apply the same governance discipline to non-human identities that they apply to human ones.

A human user who leaves the organisation has their access revoked within days, sometimes hours. A service account for a decommissioned application may remain active for years. A human user who requests access to a sensitive system goes through an approval workflow. A developer who needs a service account to access a production database creates one with a quick API call.

Closing the governance gap requires applying to non-human identities the same principles applied to human ones: least privilege access scoped to specific resources, time-limited credentials where possible, regular review and revocation of unused credentials, and continuous monitoring of credential usage patterns.

AI Agents Make This Urgent

The emergence of AI agents as a class of enterprise workload is accelerating the non-human identity problem significantly. An AI agent is a non-human identity that takes actions autonomously — calling APIs, reading databases, sending messages, modifying records. The permissions it carries are the permissions it can exercise, and in many early deployments those permissions are broad because the developers building the agent found it easier to grant wide access than to scope it precisely.

Unlike a traditional service account, an AI agent’s behaviour is harder to predict and baseline. Its action patterns depend on what it is asked to do, which varies. This makes anomaly detection more complex and the consequence of a compromised or manipulated agent potentially more severe.

Organisations deploying AI agents in 2024 and beyond need to treat those agents as first-class identities subject to the same governance discipline as human users. Specific resource permissions. Continuous monitoring. Policy-based access control. Real-time revocation when behaviour deviates from expected patterns.

TAC governs non-human identities including AI agents through the same policy engine as human users. See AI Agent Access Governance →

This website uses cookies

We use cookies to personalize content, provide social media features, and analyze our traffic. We also share information about your use of our site with our analytics partners. You can change your preferences at any time. For more information, please see our Privacy Policy and Cookie Policy. Privacy Policy Cookie Policy