Identity-based attacks are on the rise. Attacks in which malicious actors assume the identity of an entity to easily gain access to resources and sensitive data have been increasing in number and frequency over the last few years. Some recent reports estimate that 83% of attacks involve compromised secrets. According to reports such as the Verizon DBIR, attackers are more commonly using stolen credentials to gain their initial foothold, rather than exploiting a vulnerability or misconfiguration.
Attackers are not just after human identities that they can assume, though. More commonly, they are after Non-Human Identities (NHIs), which outnumber human identities in the enterprise by at least 50 to one. Unlike humans, machines have no good way to achieve multi-factor authentication, and we, for the most part, have been relying on credentials alone, in the form of API keys, bearer tokens, and JWTs.
Traditionally, identity and access management (IAM) has been built on the idea of persistent human traits over time. It is rare for a person to change their name, fingerprints, or DNA. We can assume that if you went through an identity verification process, you are confirmed to be the human you claim to be. Based on this, you can obtain certain permissions dependent on your role within the organization and your level of trust.
Securing machine identities means getting a handle on the unique trait that bad actors actually care about, namely, their access keys. If we treat these highly valued secrets as the way to uniquely identify the identities we are protecting, then we can leverage that into true observability around how access is granted and used throughout your enterprise.
Accounting For NHIs Through A Fractured Lens
Before we take a deeper look at secrets as unique identifiers, let’s first consider how we currently talk about NHIs in the enterprise.
Most teams struggle with defining NHIs. The canonical definition is simply “anything that is not a human,” which is necessarily a wide set of concerns. NHIs manifest differently across cloud providers, container orchestrators, legacy systems, and edge deployments. A Kubernetes service account tied to a pod has distinct characteristics compared to an Azure managed identity or a Windows service account. Every team has historically managed these as separate concerns. This patchwork approach makes it nearly impossible to create a consistent policy, let alone automate governance across environments.
The exponential growth of NHIs has left a gap in traditional asset inventory tools, and access reviewers can’t keep pace. Enforcement of consistent permissions or security controls across such a wildly varied set of identities seems near impossible. This is on top of aging legacy systems that have not had their passwords rotated or audited in years.
Compounding this issue is the lack of metadata and ownership around NHIs. Questions like “What is this identity for?” or “Who owns this token?” frequently go unanswered, as the person who created and released that identity into the system has moved on. This vacuum of accountability makes it difficult to apply basic lifecycle practices such as rotation or decommissioning. NHIs that were created for testing purposes often persist long after the systems they were tied to are discontinued, accumulating risk silently.
The UUIDs Of Your Zero Trust Protect Surface
No matter what form or shape an NHI takes, in order to do work as part of an application or system, it needs to authenticate to access data and resources and do its work.
Most commonly, this takes the form of secrets, which look like API keys, certificates, or tokens. These are all inherently unique and can act as cryptographic fingerprints across distributed systems. When used in this way, secrets used for authentication become traceable artifacts tied directly to the systems that generated them. This allows for a level of attribution and auditing that’s difficult to achieve with traditional service accounts. For example, a short-lived token can be directly linked to a specific CI job, Git commit, or workload, allowing teams to answer not just what is acting, but why, where, and on whose behalf.
This access-as-the-identifier model can bring clarity to your inventory, offering a unified view of all your machines, workloads, task runners, and even agent-based AI systems. Secrets offer a consistent and machine-verifiable method of indexing NHIs, letting teams centralize visibility into what exists, who owns it, and what it can access, regardless of whether it’s running on Kubernetes, GitHub Actions, or a public cloud.
Critically, this model also supports lifecycle management and Zero Trust principles more naturally than legacy identity frameworks. A secret is only valid when it can be used, which is a provable state, which means unused or expired secrets can be automatically flagged for cleanup. This can stop identity sprawl and ghost accounts, which are endemic in NHI-heavy environments.
The Security Ramifications Of Secrets At NHI Identifiers
If we are going to talk about secrets as the unique identifier for machines and workloads, we do need to address the fact that they have a nasty tendency to leak. According to our State of Secrets Sprawl 2025 research, almost 23.8 million secrets were leaked on public GitHub repositories in 2024, a 25% year-over-year increase. Worse yet, a full 35% of the private repositories we researched contained secrets, 8 times as many as we found in public repositories.
Breaches over the past several years, from Uber to the U.S. Department of the Treasury, have shown that when secrets are scattered across pipelines, codebases, containers, and cloud configs without consistent management, they become a silent invitation to attackers. These leaked or stolen credentials offer attackers a low-friction path to compromise.
A leaked API key or NHI token allows anyone who attempts to use it to establish a valid session, with no mechanism in place to verify its legitimacy or the context of its use. If the secret is tied to a long-lived, over-permissioned bot or service account, the attacker instantly inherits all that trust.
The problem is amplified further when secrets outlive their purpose. Orphaned secrets, credentials forgotten about and never decommissioned, abandoned CI/CD jobs, or one-off projects, linger quietly, often with dangerous levels of access and zero visibility. Without ownership, expiration, or revocation processes, they become ideal entry points for attackers looking for stealth and persistence.
GitGuardian Can Inventory All Your Secrets, Not Just The Leaked Ones
Secrets can only live in two possible places: where they belong, safely stored in a secrets management vault, or leaked elsewhere. We have been helping people find the secrets leaked where they are not supposed to be for years now, with our internally focused Secrets Detection offering and our Public Monitoring platform.
Now, GitGuardian can act as your cross-environment NHI inventory platform, helping you gain visibility into what secrets are in your vaults, along with metadata around how they are used. GitGuardian builds a unified, contextualized inventory of every secret, regardless of origin or format. Whether it’s injected via Kubernetes, embedded in an Ansible playbook, or retrieved from a vault like HashiCorp, each secret is fingerprinted and monitored.
This cross-environment awareness allows teams to quickly see
Which NHIs have keys leaked publicly.
If any internal leaks happened for those same secrets.
Any secrets redundantly stored in multiple vaults
If the secret is long lived and needs rotation
The GitGuardian NHI Governance Inventory dashboard showing policy violations and risk scores.
Crucially, GitGuardian also detects “zombie” credentials, secrets that persist without authorization or oversight. Rich metadata, like creator attribution, secret lifespan, permissions scope, and context, empower governance over these non-human actors, enabling real-time inventory alignment and accountability.
This visibility isn’t just operational, it’s strategic. GitGuardian enables centralized policy enforcement across all secret sources, transforming reactive secrets detection into proactive identity governance. By mapping secrets to NHIs and enforcing lifecycle policies like expiration, rotation, and revocation, GitGuardian closes the loop between discovery, vaulting, and enforcement
Beyond Inventory And Towards NHI Governance
The rise of non-human identities has reshaped the identity landscape, and with it, the attack surface. Credentials aren’t just access keys. Secrets are the mechanism that allows an attacker to assume an identity that already has persistent access to your data and resources. Without visibility into where those credentials live, how they’re used, and whether they’re still valid, organizations are left vulnerable to silent compromise.
GitGuardian’s Secrets Security + NHI Governance = Non-Human Identity Security
Treating secrets as the UUIDs of modern workloads is the clearest path to scalable, cross-platform NHI governance. But that approach only works if you can see the full picture: vaults, pipelines, ephemeral infrastructure, and everything in between.
GitGuardian delivers that visibility. We are turning fragmented credential sprawl into a unified, actionable inventory. By anchoring NHI identity to its authenticating secret, and layering in rich metadata and lifecycle controls, GitGuardian enables security teams to detect issues early, identify over-permissioned and orphaned credentials, and enforce revocation before a breach occurs.
We are helping complex modern enterprises reduce the likelihood of successful identity-based attacks. When credentials are monitored, scoped, and managed in real time, they’re no longer low-hanging fruit for attackers.
We would love to give you a full demo of the capabilities of the GitGuardian NHI Security platform and help you get unparalleled insight into your NHIs and secrets security. And if you’d rather explore on your own, take a guided tour of GitGuardian with our interactive demo!
