Identity-based attacks are on the rise. Attacks that assume the identity of an entity that allows malicious actors to easily access resources and easily access sensitive data have increased in recent years. Several recent reports estimate that 83% of attacks will involve compromised secrets. Reports such as Verizon DBIR show that attackers are gaining their first footing, rather than exploiting vulnerabilities or misconceptions, using stolen credentials more commonly.
However, attackers are not just human identities they can envision. More generally, they are after nonhuman identity (NHIS), surpassing corporate human identity by at least 50:1. Unlike humans, machines do not have a good way to achieve multifactorial authentication. Most often, they rely solely on their credentials, in the form of API keys, bearer tokens, and JWTS.
Traditionally, identity and access management (IAM) has been built on the idea of human traits that persist over time. It is rare for a person to change their name, fingerprint, or DNA. If you go through the identity verification process, you can assume that you are confirmed to be the person you assert. Based on this, you can obtain specific permissions that depend on the roles and trust levels within your organization.
Protecting the identity of a machine means dealing with unique traits that bad actors actually care about: access keys. Treating these highly regarded secrets as a way to uniquely identify the identity they are protecting can use it for true observability as to how access is permitted and used across the enterprise.
Occupies the NHIS via fractured lenses
Before looking into secrets as unique identifiers, let’s start by thinking about how we are talking about the current company’s NHI.
Most teams struggle with defining NHI. The standard definition is simply “non-human” and is necessarily a broad range of concern. NHIS differs between cloud providers, container orchestrators, legacy systems, and edge deployments. The Kubernetes service account associated with a pod has distinct characteristics compared to an Azure managed identity or Windows service account. All teams have historically managed these as separate concerns. This patchwork approach makes it almost impossible to automate governance across the environment, as well as create consistent policies.
NHIS’ exponential growth remains a gap in traditional asset inventory tools, and access reviewers are unable to maintain their pace. Enforcement of authority or security controls across such a highly diverse set of identities seems almost impossible. This adds to aging legacy system that hasn’t rotated or audited passwords in a few years.
What exacerbates this issue is the lack of metadata and ownership around NHIS. Questions like “What is this identity for?” or “Who owns this token?” are often not answered because people who created and released that identity into the system have moved. This accountability gap makes it difficult to apply basic lifecycle practices such as rotation and decommissioning. NHIs created for testing purposes often last long after the system they are connected to is discontinued, resulting in a quiet build-up of risk.
Zero Trust uUID protects surfaces
Whatever form or form NHI takes, to work as part of an application or system, it must be authenticated to access and work with data and resources.
Most commonly, this takes the form of a secret that looks like an API key, certificate, or token. All of these are unique in nature and can act as cryptographic fingerprints for the entire distributed system. When used in this way, the secrets used for authentication become trackable artifacts that are directly tied to the system that generated them. This allows for attribution and auditing to a level that is difficult to achieve with traditional service accounts. For example, a short-lived token can be directly linked to a particular CI job, GIT commit, or workload, allowing the team to answer not only what is acting, but why, where, and on behalf of anyone.
This identifier model as access can clarify inventory and provide a unified view of all machines, workloads, task runners, and even agent-based AI systems. Secrets provide a consistent, machine-verified way to index NHIS, allowing teams to focus visibility on what exists, owners, and what they can access, whether they are running in Kubernetes, Github actions, or in public clouds.
Importantly, this model supports lifecycle management and zero trust principles more naturally than legacy identity frameworks. Secrets are only valid when available. This is a proven state and can automatically flag unused or expired secrets for cleanup. This allows you to stop sprawl and ghost accounts of identity that are endemic in NHI-heavy environments.
Impact of secret security for NHI identifiers
When talking about secrets as unique identifiers for machines and workloads, you need to address the fact that they tend to be leaky. Our Secret Status was found in 2025 research, with approximately 23.8 million secrets leaked in public Github repositories in 2024, an increase of 25% from the previous year. Worse, 35% of the private repositories we surveyed contained eight times the amount of secrets we found in public repositories.
Violations from the past few years, from Uber to the US Treasury, have shown that secrets can be quiet invitations to attackers if they are scattered without consistent management across pipelines, codebases, containers, and cloud configurations. These leaks or stolen credentials provide attackers with a low friction path to compromise.
Anyone who attempts to establish a valid session using it by using a leaked API key or NHI token has no mechanism to validate its legitimacy or the context of its use. If the secret is tied to a long-life unauthorized bot or service account, the attacker will immediately inherit all of that trust.
When secrets outweigh the objective, the problem is further amplified. Orphaned secrets, qualifications are forgotten, not abolished, abandoned CI/CD jobs, or one-time projects remain quiet, often with dangerous levels of access and visibility. Without ownership, expiration or revocation process, it is an ideal entry point for attackers looking for stealth and persistence.
gitguardian can stock all the secrets, not just the leaked ones
Secrets can only live in two possible places. It is where they belong and are kept safely in a secret management safe or leaked elsewhere. We have been helping people find secret detection offerings and public surveillance platforms that focus on us, for years, to find secrets that have been leaked to unpredictable locations.
Currently, Gitguardian can act as an NHI inventory platform across the environment, recognizing what secrets there are and obtaining metadata about how they are used. GitGuardian builds a unified, contextualized inventory of all secrets, regardless of origin or form. Whether injected via Kubernetes, embedded in an Ansible Playbook, or retrieved from a safe like Hashicorp, each secret is fingerprinted and monitored.
This mutual environment awareness allows teams to see immediately
Which NHI has a public key. If an internal leak occurs due to those same secrets. If secrets live long and require rotation, secrets stored redundantly in multiple safes
The GitGuardian NHI Governance Inventory Dashboard shows policy violations and risk scores.
Importantly, Gitguardian also detects “zombie” credentials, secrets that persist without approval or surveillance. Rich metadata such as creator attribution, secret life expectancy, permission scope, and context enhances governance over these non-human actors, allowing real-time inventory alignment and accountability.
This visibility is not just operational, but also strategic. Gitguardian enables centralized policy enforcement across all secret sources, transforming reactive secret detection into aggressive identity governance. By mapping secrets to NHIS and enforcing lifecycle policies such as expiration, rotation, and cancellation, GitGuardian closes the loop between discovery, vault, and enforcement
Going beyond inventory and towards NHI governance
The rise of non-human identities has changed the landscape of identity, and with that, the attack surface has changed. Your credentials aren’t just your access key. Secrets are mechanisms that allow attackers to assume an identity that already has persistent access to your data and resources. Without visibility into where these credentials live, how they will be used, and whether they are still valid, organizations will remain vulnerable to quiet compromises.
Gitguardian’s Secrets Security + NHI Governance = Nonhuman Identity Security
Treating secrets as UUIDs for modern workloads is the clearest path to scalable, cross-platform NHI governance. But that approach only works if you can see the big picture of vaults, pipelines, ephemeral infrastructure, everything in between.
GitGuardian provides that view. It transforms fragmented credentials into a unified, practical inventory. By pinning the NHI identity to its perceived secrets and layering rich metadata and lifecycle controls, GitGuardian allows security teams to detect issues early, identify overly authorized and isolated entitlements, and enforce revocations before a violation occurs.
We help complex modern companies reduce the likelihood of successful identity-based attacks. Once credentials are monitored, scoped and real-time, they are no longer low fruit for attackers.
We would like to provide a complete demo of the features of the GitGuardian NHI Security Platform and help you gain unparalleled insights into NHIS and Secrets Security. Also, if you want to explore yourself, take a guided tour of GitGuardian with an interactive demo!
Source link
