Why the Principle of Least Privilege Is Critical for Non-Human Identities

Attackers only really care about two aspects of a leaked secret: does it still work, and what privileges it grants once they are in. One of the takeaways from GitGuardian’s 2025 State of Secrets Sprawl Report was that the majority of GitLab and GitHub API keys leaked in public had been granted full read and write access to the associated repositories. Once an attacker controls access to a repository, they can do all sorts of nasty business. 

Both platforms allow for fine-grained access controls, enabling developers to tightly restrict what every token can and can't do. The question is then, why are teams not following the principle of least privilege for their projects? And what can be done to better secure the enterprise against overpermissioned NHIs?

What Is the Principle of Least Privilege?

When you join an organization, your IAM team works to ensure you have the right amount of permissions. As a new employee, the team most likely doesn't want to give you immediate access to all production environments or unfettered access to sensitive data. You should be given just the minimum amount of access you need in order to do your work. We generally refer to this as the principle of least privilege.

Wikipedia defines this as: "The practice of limiting access rights for users, accounts, and computing processes to only those resources absolutely required to perform their intended function."

The principle of least privilege is designed to reduce risk from both internal and external threats. These threats come mainly in the form of identity-based attacks, where an adversarial actor assumes the identity of someone, or something, to abuse the privileges they possess. Limiting access rights means limiting the damage that can be done, containing the blast radius.

The concept originated in traditional IT environments focused on human access. In the modern enterprise, humans are far from the majority when it comes to accessing services and resources. Non-human identities (NHIs) now outnumber humans by at least 100-to-1 in most organizations, many of which are only now beginning to recognize the urgent need to better manage these identities and their access at scale. At the same time, teams are finding classic approaches designed around human access, like privileged access management (PAM) and identity governance and administration (IGA), are a poor fit for NHIs. 

Understanding how to secure machine identities requires a different mindset and different tooling. 

Machines Are Not Humans

A human user might attempt to access a system, and when they discover they can't, they request additional permissions. This is most often done through an access ticket or approval workflow that has organizational checks and balances. It includes oversight from managers and security teams. 

Machine identities cannot participate in that type of loop. If a machine identity is underprivileged, it will simply fail in production. And if it is overprivileged, it will keep working, even if it poses a serious security risk.

Developers often default to broad access grants for one reason: breaking the application or CI/CD pipeline carries a significantly higher risk from their perspective. This is often the unfortunate view from the business as well; the need for uptime comes first, and they only worry about widely scoped permissions during or after a breach. 

If developers are unsure which permissions a machine identity requires, they would rather grant too much than risk breaking a deployment pipeline or production system. This mindset, while understandable, is dangerous. 

The Realities Of Large-Scale Systems And Access

Even with good intentions, developers may not know what permissions a machine will need until it runs in a real-world context. A service might need to write to a logging bucket, or a Lambda function might require access to several different APIs depending on runtime conditions.

The result is often trial-and-error. To avoid failure, engineers grant elevated permissions early, with plans to restrict them later. Unfortunately, that tightening of access rarely happens.

Overpermissive machine identities can give attackers lateral movement across environments or full access to critical systems. And these overprivileged identities are rarely reviewed after they are created.

Humans Get Audited; NHIs Usually Don't

Human access is subject to regular audit. Enterprises check group memberships, login patterns, and behavior anomalies. Periodic reviews ensure that unneeded access is locked down and the principle of least privilege is adhered to. 

Machine identity access, on the other hand, is often invisible. Machine identities are created during infrastructure provisioning or CI/CD setup, and then left alone. They are rarely reviewed unless something goes wrong. Until then, NHIs are largely forgotten about, in many cases entirely, their long-lived, overpermissioned access keys unaccounted for in any coherent system. 

The underlying problem of managing permissions is one of visibility. This lack of visibility creates an opportunity for attackers. A leaked API key or cloud token belonging to a machine identity can provide persistent, unnoticed access for months or even years. 

But even if every NHI and its secrets are accounted for, the sheer number of NHIs makes the traditional auditing approach untenable. 

Scale Makes The Problem Worse

Each microservice, deployment tool, infrastructure component, and cloud workload needs access. Multiply this across multiple pipelines, applications, and teams, and it is easy to see how enterprises have gotten to the 100-to-1 NHI-to-human ratio in just a few short years.

Agentic AI Is Intensifying The Problem

The rise of agentic AI systems, which operate on behalf of users or orchestrate tasks across systems, has dramatically increased the risk landscape. These agents often inherit the full set of permissions from the human user or other machine accounts they operate through. This delegation model is usually very wide and poorly scoped.

When an AI agent acts across systems, it may do so using permissions that were never intended for it. The result is a hidden layer of overprivileged identities that are difficult to monitor and control. 

This scale overwhelms traditional IAM processes. Manual reviews and spreadsheets cannot keep up. Static policies are often outdated or misapplied, and audit logs become nearly impossible to interpret when thousands of service accounts behave in similar ways. 

To solve this problem in a scalable and sustainable way, organizations need an approach that enforces permissions without slowing down developers. The IAM team should not be burdened with constant manual oversight. 

Policies must be enforceable through automation, ensuring consistency across environments. Finally, access must be auditable, with clear and contextual visibility into what each identity, human or machine, is able to do, and why.

You Need An Inventory And Visibility First

The first step toward enforcing least privilege for machine identities is to understand what identities exist and what they can do. This means having a full inventory of every machine identity, the secrets they use, and the actions they are permitted to take across systems.

Without this visibility, organizations cannot implement controls or reduce exposure. Unfortunately, today, many security teams struggle to answer the basic question: "What can this service account access?"

An Optimally Permissive Future

The principle of least privilege is more important than ever, but applying it to machine identities requires a different strategy. Unlike humans, machines cannot ask for more access, cannot be easily audited with traditional tooling, and operate at a scale that does not fit with human-centric IAM platforms.

Security teams need tools that provide full inventory, permission insights, and automation.