GitGuardian Explained: Secrets Detection, ggshield, Honeytokens and How to Run the Incident Workflow

Leaked credentials are one of the most common starting points for cloud breaches, and they leak in boring ways: a test file, a .env committed by mistake, a CI log, a public fork. GitGuardian is a platform built around finding those secrets, getting them revoked, and stopping the next one before it is committed.

What it is

GitGuardian has three main parts:

• Internal Monitoring connects to your version control systems and other sources, scans history and new commits, and turns each leaked secret into an incident with an owner and a status.
• Public Monitoring watches public GitHub for secrets linked to your organisation's developers, which is where personal side projects and forks leak company keys.
• ggshield, the open-source (MIT) command-line tool, scans files, repositories, Docker images and packages, and runs as a pre-commit or pre-push hook, in CI and on the server as a pre-receive hook.

It also offers honeytokens (decoy credentials) and NHI Governance, which inventories non-human identities across secrets managers such as HashiCorp Vault, AWS Secrets Manager and Azure Key Vault. GitGuardian is independent and raised a Series C in February 2026.

How it works

Detection combines provider-specific detectors, which recognise a token's exact format, with generic detectors for passwords and connection strings. Validity checks test a detected secret against its provider where that is possible, so a live production key rises above an expired test token. An incident is closed as Resolved when the secret has been revoked, or Ignored when it is a false positive, a test credential or an accepted low risk; a resolved secret that appears again reopens the incident.

ggshield does its pattern matching through the GitGuardian API, which is why it needs an API key: developers usually sign in with ggshield auth login, and CI uses a service account key in GITGUARDIAN_API_KEY.

How to use it

Day one: connect sources and scan history

Connect your VCS to Internal Monitoring and let the historical scan run. Expect a large first batch: years of history usually contain hundreds of secrets, most of them dead. Use validity, where the secret was found (a public repository is worse) and the secret type to sort them.

Week one: work the incidents and add prevention

1. Revoke live secrets first, then close incidents as Resolved. Rotation is the fix; history rewriting is optional.
2. Install the hook for developers:

ggshield auth login
ggshield install --mode global      # pre-commit hook for every repository
ggshield secret scan repo .          # scan an existing repository's history

3. Add a CI step so commits from machines without the hook are still checked, and consider a pre-receive hook on self-hosted Git servers, minding GitHub Enterprise Server's short time limit for pre-receive hooks.
4. Record false positives with ggshield secret ignore --last-found, which writes to .gitguardian.yaml, or ignore them in the dashboard, which ggshield also honours.

Every day: cover new places secrets leak

AI coding assistants now write files and run commands on developers' machines. Since 2026, ggshield machine setup installs hooks for tools including Cursor, Claude Code, Codex and Copilot CLI, so a secret is caught before an assistant writes or sends it. Plant honeytokens in places an intruder would search, such as CI variables, internal wikis or a developer laptop's credentials file, and route their alerts to incident response, not the secrets queue: a triggered honeytoken means someone is already inside.

Where it stops

• Scanning needs the API. Content leaves the machine for detection unless you run a self-hosted instance.
• Generic secrets are harder. A random password with no recognisable format may be missed or misclassified; validity checks only work for providers that offer a way to test.
• Hooks can be skipped. A developer can bypass a local hook, so server-side and CI scanning still matter.
• Finding is not fixing. The tool cannot rotate a key in a system it does not control; the owner must.

How it comes up in interviews

• "You find 600 secrets in git history. What do you do first?" Validity, exposure (public versus private), privilege of the secret, and revoke before clean-up.
• "A developer says they deleted the commit, so the key is safe." Explain forks, clones, caches and why only revocation ends the risk.
• "Where would you put honeytokens, and who gets the alert?" Show that you understand deception as detection.

Sources

Checked on 13 November 2026: GitGuardian documentation for ggshield getting started, pre-commit and pre-receive integrations, ggshield secret ignore, the AI hook (ggshield secret scan ai-hook and ggshield machine setup), validity checks, incident statuses, honeytokens and NHI Governance integrations; ggshield GitHub repository README; GitGuardian Series C announcement (11 February 2026).