Assess and improve your NHI security posture
Our security policies are informed by the OWASP Top 10 for NHIs, a comprehensive framework that highlights the most critical security risks they pose.
We support the following policies:
- Publicly Leaked Secrets: These are secrets that have been exposed publicly, identified through our public monitoring services. Such exposure can allow unauthorized parties to access sensitive systems, posing significant security threats.
- Internally Leaked Secrets: Secrets that have been inadvertently exposed within your internal perimeter can be detected through our private monitoring services. These internal leaks can be just as harmful as public ones, especially if internal defenses are breached.
- Cross-Environment Secrets: A secret that is found in multiple environments, like both production and staging, can risk exposing sensitive production-level access to less secure environments. Ensuring each environment has distinct secrets helps maintain security boundaries.
- Reused Secrets: When a secret is used by multiple entities, it increases the risk of compromise. If one entity is breached, others using the same secret can also be jeopardized. Ensuring unique secrets for each use case reduces this risk.
- Duplicated Secrets: Having the same secret stored in multiple vaults or paths can complicate management and increase the chance of using outdated or unrevoked credentials. It is crucial to maintain a single source of truth to manage secrets effectively.
- Long-Lived Secrets: Secrets that exist beyond a given lifespan (by default one year) without renewal are vulnerable to misuse. Regularly updating these secrets helps minimize the risk of prolonged exposure to potential threats.
- Overprivileged Identity: An identity that has been granted broader permissions than it actually needs. Overprivileged NHIs widen the blast radius if their secret is compromised, so trimming entitlements back to least privilege is key to reducing risk. Evaluation is available for AWS IAM, Microsoft Entra, and Okta identities.
In the inventory details, selecting a breach policy will visually highlight the locations of the issues on the exploration map.

Identify admin identities
In addition to policy breaches, GitGuardian flags identities that hold admin-level permissions on your infrastructure or identity provider. Admin NHIs are surfaced in the inventory with an Identity level: Admin badge and can be isolated with the dedicated Identity level filter (Admin / Non-admin).
Admin detection is available for:
- AWS IAM: principals attached to
AdministratorAccessorIAMFullAccess, or holding custom policies with wildcard actions on IAM or AWS Organizations. - Microsoft Entra: principals with high-impact directory roles (e.g. Global Administrator, Privileged Role Administrator, Application Administrator), admin-equivalent Azure RBAC roles (Owner, User Access Administrator), or tier-1 Microsoft Graph permissions (e.g.
RoleManagement.ReadWrite.Directory). - Okta: principals with built-in admin roles (Super, Org, App, Group, User, API Access Management Admin) or custom roles granting admin-equivalent permissions.
Use this signal to focus remediation on the identities with the greatest blast radius, independently of whether they currently breach a policy.
Risk criticality
Each NHI in the inventory is assigned a Risk criticality level (low, medium, high, critical) derived from two layers:
- Base severity from the highest-risk active policy breach on the identity. For example, a publicly leaked secret rates critical, internally leaked rates high, overprivileged rates medium, long-lived rates low.
- Modifiers that bump the score by +1 level each, capped at critical:
- Admin identity: any breach on an admin NHI is one level more severe.
- Cross-environment with production: a cross-environment breach that touches production environment is one level more severe.
This means a leaked secret on an admin identity is surfaced as critical even if the leak itself is internal, letting you sort the inventory by risk and focus on the NHIs where an attacker would do the most damage first.
Note that new policies will be supported shortly.