Discover your NHIs

NHI Inventory

The inventory provides a centralized, searchable table listing all Non-Human Identities discovered across your perimeter. This dynamic view helps you monitor, audit, and triage NHIs efficiently across various environments and sources.

Inventory table overview

Each row in the inventory represents a unique NHI and displays the following key attributes:

• Secret name – The identifier of the associated secret.
• Detector: The Secrets Detection Engine detector that classified the secret, or Unknown if none matched.
• Source – The integration where the NHI was discovered (e.g., the name of the secret manager or Kubernetes cluster).
• Path – The exact path or location of the secret within the source.
• Environment – The environments of this NHI's secrets (production, pre-production, staging, testing, or development). Each secret's environment is inferred from its path, tags, and labels, with the source env as fallback, so an identity whose secrets live in several environments shows several values. See Environment below.
• Breached policies – Any detected misconfigurations or violations of security best practices. Learn more about breached policies
• Identity level – Whether the NHI holds admin-level permissions on its source (e.g. an AWS IAM principal with AdministratorAccess, a Microsoft Entra Global Administrator, or an Okta Super Admin). Admin identities are marked with a dedicated badge in the detail view. Learn more
• Risk criticality – An aggregated level (low, medium, high, critical) combining the highest-risk policy breach on the identity with modifiers for admin status and production exposure. Learn more
• Owners – The person(s) responsible for the NHI. See NHI Ownership below.

The inventory supports filtering based on:

• Detector: any detector, or Unknown
• Detector type: Generic, Specific, or Unknown
• Secret family
• Secret category
• Secret provider
• Breached policy
• Environment
• Source
• Identity level: Admin or Non-admin
• Risk criticality: Critical, High, Medium, or Low
• Owner: by specific owner, No owner, or Current user

The detector-linked filters (detector, detector type, secret family, category, and provider) are the same facets used on secret incidents, so you can ask the same questions of vaulted secrets as of leaks. Learn more about categories and providers.

Upgrade ggscout to 0.32.0 or later

Detector classification requires ggscout 0.32.0 or later. Until you upgrade, collected secrets stay unclassified (Unknown). After you upgrade, the next fetch classifies the existing inventory. No extra configuration is required.

Clicking into an NHI opens a detailed view that includes the detector, policy breaches, secret version, and a visual map of the NHI’s relationships and context.

Note that if a version is deleted, metadata remains but the graph is empty and marked as deleted, while fully destroyed secrets disappear from the inventory.

Environment

GitGuardian assigns an environment to each secret. The environment drives the Environment column and filter of the inventory, the Cross-Environment Secrets policy, and the production modifier of Risk criticality.

How the environment is resolved

For each secret, GitGuardian reads the following, in order, and stops at the first match:

1. The secret path.
2. The tags attached to the secret.
3. The labels attached to the secret.
4. The env declared for the source in the ggscout configuration.

When nothing resolves from the path, tags, or labels, the 'env' is inherited from the source. When the source has no env either, the secret has no environment set.

Recognized environments and aliases

• Production: production, prod, prd, live, and any value starting with prod- (such as prod-eu)
• Pre-production: pre-production, pre-prod, preprod, preproduction
• Staging: staging, stage, stg
• Testing: testing, test, qa, sit, int, uat, sandbox, demo
• Development: development, dev, local

Paths use a narrower vocabulary: live, sit, int, demo, and local are as often used as variable names as environments, so they are ignored in paths. The source env accepts the five full names plus the aliases listed on the ggscout configuration page.

What each source contributes

• Path: HashiCorp Vault (namespace, KV mount, and path), Akeyless (folder), AWS Secrets Manager (secret name), CyberArk Secrets Manager SaaS and Self-Hosted (policy branch). Paths are not read on Azure Key Vault, Delinea Secret Server, Google Cloud Secret Manager, or Kubernetes.
• Tags and labels: HashiCorp Vault KV v2 custom_metadata, AWS Secrets Manager resource tags, Azure Key Vault secret tags, Google Cloud Secret Manager labels and annotations, CyberArk annotations, Akeyless item_tags, Kubernetes Secret labels, GitLab CI environment_scope, and the GitHub Actions environment tag. Azure Key Vault tags, GitLab CI environment_scope, and Akeyless item_tags require ggscout 0.33.0 or later.
• Nothing: Delinea Secret Server exposes neither a readable path nor tags, so its secrets take the source env.

Path rules

• Only whole path segments count: vault/prod/db and vault/prod-eu/db resolve to production, while dev-tools/prod-db resolves nothing.
• When several segments match, the deepest one wins.
• int, sit, live, demo, and local are ignored in paths. They still count in tags and labels.

Tag and label rules

• A tag is read when the last segment of its key is env, environment, stage, or tier (so finops:environment works), or when the key is deployment.environment.name or environment_scope.
• When several keys match, the least namespaced one wins: env beats finops:env.
• Tags are read before labels. A label is only read when no tag resolves, so a tag environment=staging wins over a label env=prod.
• Labels are read only in the key:value or key=value form, and their key follows the same rules as a tag key.

NHI Ownership

Ownership assigns accountability for each NHI to one or more people in your organization: you can see who is responsible for an identity, filter the inventory by owner, and add or change owners manually.

Suggested vs manual owners

• Suggested owners – GitGuardian can automatically suggest owners using data from your integrated sources and from secret incidents. Suggested owners are labeled as Set automatically by GitGuardian in the NHI detail view. You can keep them, remove them, or add other owners.
• Manual owners – Any owner you add or confirm yourself is labeled Set manually. Manual assignments are never overwritten by automatic suggestions.

How owners are suggested

Suggestions are based on several signals, in order of confidence (highest first):

1. Direct owner field – The NHI source exposes an explicit owner for the identity (e.g. IAM or IdP owner field).
2. Metadata tags – A tag on the resource contains an owner (e.g. an AWS IAM or Azure tag with an email).
3. Source-level owner – The integration has a declared owner (e.g. the user who configured the integration).
4. Last editor or creator – The person who last modified or created the resource, when provided by the source.
5. Incident committer – A developer who committed a secret that led to an incident tied to this NHI (private or public).
6. Public secrets scan – The user whose scan detected the secret associated with this NHI.

When several candidates exist, the system keeps only those with the highest confidence. You can have up to 5 owners per NHI.

Who can be an owner

• A workspace member (linked to their GitGuardian user).
• An external user identified by email (e.g. a contractor or someone in another team). No GitGuardian account is required.

Managing owners

• In the inventory, the Owner column shows up to two owners per NHI; use the Owner filter to narrow the list (e.g. No owner, Current user, or a specific person).
• In an NHI’s detail view, use the Owners section to add, remove, or replace owners. You can type a workspace member or any valid email to add an external owner. Removing a suggested owner discards that suggestion so it is not re-applied automatically.

API

Ownership can be managed via the public API using the nhi:ownership:read and nhi:ownership:write scopes. Endpoints allow you to list owners for an identity, add owners, remove an owner, or replace the full list of owners.

Exploration map

The Exploration map gives you a visual, end-to-end view of an NHI, helping you understand its connections, usage, and potential impact across your environment.

The map is composed of:

• Secrets managers – Where the NHI's secrets are safely stored.
• Consumers – Entities (such as services, scripts, or jobs) that use the secret to authenticate and access other systems.
• Accessed resources – The targets accessed by the consumers, along with their permissions, based on Secret Analyzers.
• Incidents – Both public and private secret incidents associated with the NHI.

You can access the map from an NHI’s detail view or directly from a secret incident, enabling fast, contextual navigation between detection and analysis.

Use cases

While the primary goal is to visualize and contextualize NHIs, the map also helps to:

• Streamline remediation – Quickly assess the impact of revoking a secret and identify all affected systems.
• Investigate leaks – Trace which consumers and resources may have been compromised.
• Improve secret hygiene – Spot stale or overprivileged secrets, unused consumers, and other hygiene issues across your perimeter.