GitGuardian ggshield Setup: Block AI Coding Leaks in 13 Steps [2026]

AI coding assistants now read your files, run shell commands, and call external APIs mid-session. That convenience comes with a new leak path: a stray .env file, a hardcoded AWS key, or a database password can get pasted straight into a prompt, a tool call, or a commit an agent makes on your behalf. GitGuardian’s open-source CLI, ggshield, closes that gap by scanning what AI coding tools read and write before anything reaches a model or a remote repository. This guide walks through installing ggshield, wiring it into Cursor, Claude Code, GitHub Copilot, and Codex, and hardening a real project against secret leaks in under two hours.

By the end of this tutorial you will have a working pre-commit hook, an AI-tool integration that blocks secrets before they reach a model, a CI pipeline check, and a documented incident-response path for the day a secret slips through anyway. Every step below uses commands verified against ggshield’s September 2026 release documentation.

·

Google · Preferred Sources

Don't miss new tech stories on Google

Add Tech Insider once in the Google app and our stories appear in your news suggestions.

Add Now

Why AI coding assistants create a new secret-leak surface

Traditional secret scanning focused on one choke point: the git commit. Tools like pre-commit hooks or GitHub’s native secret scanning caught a hardcoded API key the moment a developer tried to push it. That model assumed a human was the only actor reading and writing code.

AI coding assistants break that assumption. According to GitGuardian’s own release documentation, tools such as Cursor, Claude Code, GitHub Copilot, and Codex can now read files, run shell commands, and call external tools during a single session. An agent debugging a failed API call might open a .env file to check a variable name, paste its contents into a prompt to “see what’s wrong,” or echo a credential into a terminal command that gets logged. None of that activity touches git until much later, if ever, and by then the secret has already been sent to a model provider, written into a chat log, or printed to a terminal history that gets uploaded somewhere else.

GitGuardian’s documentation describes the fix directly: ggshield integrates with AI coding tools through their hook systems to scan interactions in real time, and when a secret is detected, ggshield blocks the action before it reaches the model and tells the developer to remove the secret, as described in GitGuardian’s AI coding tools integration documentation. That moves the scanning checkpoint from “before the commit” to “before the prompt,” which matters because an agent session can expose far more raw file content than a single diff ever would.

This isn’t a theoretical risk. Help Net Security’s September 2026 roundup of open-source security tools highlighted a parallel project, Sift, a free command-line tool that searches for passwords, API keys, and other sensitive data across local disks, Windows file shares, an entire Active Directory domain, SharePoint, OneDrive, Teams channel files, Slack messages, and Jira and Confluence, according to Help Net Security’s September 2026 open-source tools coverage. The fact that two separate secret-hunting tools shipped major updates in the same month says something about where the industry’s attention has shifted: secrets don’t just live in git history anymore, they live in every surface an AI agent can touch.

How ggshield’s detection engine actually works

It helps to understand what’s happening under the hood before you start tuning thresholds or debugging a false positive. ggshield’s detection engine combines two approaches rather than relying on either one alone. The first layer is pattern matching: regular expressions tuned to the exact shape of a given provider’s credentials, so an AWS access key, a Stripe secret key, and a Slack webhook URL each get matched against a signature specific to that provider rather than a single generic “looks like a password” rule. The second layer is entropy analysis, which flags strings with unusually high randomness even when they don’t match a known provider pattern, catching custom-generated tokens, internal API keys, and homegrown secrets that no public pattern library would recognize.

GitGuardian’s detection engine also performs validity checking for supported providers, meaning it can confirm whether a matched string is still an active, usable credential rather than an expired or already-rotated one. This matters for triage: a finding marked as a currently valid AWS key deserves an immediate, drop-everything rotation, while a finding marked as already invalid is still worth cleaning up from history but isn’t an active emergency. Not every provider supports this check, and the --json output from a scan will show “Could not check” for validity when the provider isn’t supported or when the scan is running offline.

Understanding this two-layer approach explains why ggshield occasionally flags something that looks like a false positive at first glance, such as a long, random-looking test fixture string. The entropy layer doesn’t know your fixture is fake; it only knows the string looks like it could be a secret. That’s exactly the behavior you want from a scanner erring on the side of caution, even though it means your ignore list in .gitguardian.yaml will need occasional maintenance.

Choosing between local, global, and CI install modes

The -m flag used throughout this guide (local, global, or ci) controls scope, and picking the wrong one is a common source of confusion during rollout. A local install registers the hook only inside the current repository’s .git directory, which is the right choice for a hook you want scoped to one project, such as a repo with unusually strict compliance requirements. A global install registers the hook at the user or system level so every repository you open on that machine inherits the same protection automatically, which is almost always the right default for the AI-tool integration in Step 5, since you want Cursor or Claude Code protected the same way no matter which project you’re working in that day.

CI mode is a separate code path entirely, built for non-interactive pipeline runs rather than a developer’s interactive terminal. It skips the OAuth browser flow in favor of a pre-issued API key passed through an environment variable, and it’s designed to exit with a non-zero status code that fails the build cleanly rather than prompting for input the pipeline can’t provide. Mixing these up, for instance trying to run an interactive local-mode command inside a Docker container with no browser access, is one of the more common setup failures teams report when they first automate the rollout.

Prerequisites and versions

Confirm you have the following before starting. Version numbers below reflect GitGuardian’s September 2026 release documentation; always check the current release notes before a production rollout since point releases ship frequently.

• Python 3.9 or later, or a package manager that can install a standalone binary (pipx, Homebrew, or a direct binary download)
• ggshield version 1.55.0 or later for the AI coding tool setup workflow covered in this guide
• A free GitGuardian account to generate a personal access token (the Community plan covers individual developers and small teams)
• Git 2.30 or later, already installed on most development machines
• One or more supported AI coding tools: Cursor, Claude Code, GitHub Copilot (Copilot Chat), or Codex
• Terminal access with permission to modify shell profile files (.bashrc, .zshrc, or equivalent) and git hook directories
• A GitHub, GitLab, or Bitbucket repository you control, for the CI pipeline step later in this guide
• Administrator rights if you plan to deploy ggshield fleet-wide through an MDM setup job rather than per-developer

You do not need a paid GitGuardian subscription to follow this tutorial. The CLI, the local pre-commit hook, and the AI-tool integration all work against the free tier. Paid tiers add centralized dashboards, historical scanning across an entire organization’s repositories, and incident management workflows, which matter once you’re protecting more than a handful of repos.

Step 1: Install ggshield

Pick whichever installer fits your platform. pipx is the recommended route because it isolates ggshield’s dependencies from your project’s Python environment, which avoids version conflicts down the line.

# macOS or Linux with pipx
pipx install ggshield

# macOS with Homebrew
brew install gitguardian/tap/ggshield

# Any platform with pip (use a virtual environment)
pip install ggshield

# Verify the install and confirm you have 1.55.0 or later
ggshield --version

If ggshield --version reports anything older than 1.55.0, upgrade before continuing. The AI coding tool integration commands used later in this guide depend on hook-registration behavior that only exists in the newer release line.

Step 2: Create a GitGuardian account and generate an API key

ggshield needs a personal access token to authenticate scan requests against GitGuardian’s detection engine, which the GitGuardian repository documentation describes as covering more than 550 secret patterns. Sign up for a free account, then authenticate the CLI directly from your terminal rather than copying a raw token:

# This opens a browser window to complete OAuth login
ggshield auth login

# Confirm the token is stored and working
ggshield auth status

The OAuth flow avoids pasting a long-lived token into a config file by hand, which is the kind of secret-handling mistake this entire tutorial is trying to prevent. If you’re setting up ggshield on a headless CI runner instead of a developer workstation, generate a service-account API key from the GitGuardian dashboard and store it as a masked CI secret rather than in a script.

Step 3: Run your first manual scan

Before wiring ggshield into hooks or AI tools, run it manually against an existing project to see what it finds. This step also confirms your installation and authentication are both working.

# Scan the current directory recursively
ggshield secret scan path . --recursive

# Scan only staged changes, useful before a commit
ggshield secret scan pre-commit

# Scan the entire git history of a repository
ggshield secret scan repo .

Run the repo-history scan on an older project at least once. It’s common to discover a credential that was committed, then “removed” in a later commit without ever being rotated, which means it’s still sitting in git history where anyone with clone access (including an AI agent with repo read access) can find it.

Step 4: Install the pre-commit hook

This is the classic choke point and still worth setting up even though the AI-tool integration in the next steps covers a newer risk. The pre-commit hook catches secrets that make it into a diff regardless of whether an AI assistant or a human typed them.

# Install the hook in the current repository
ggshield install -m local -t pre-commit

# Verify it's registered
cat .git/hooks/pre-commit

Test it immediately by staging a dummy secret and attempting a commit:

echo 'AWS_SECRET_ACCESS_KEY=AKIAIOSFODNN7EXAMPLE' > test-secret.env
git add test-secret.env
git commit -m "test commit"

You should see the commit rejected with output describing the detected secret type, the file, and the line number. Delete test-secret.env and unstage it once you’ve confirmed the block worked.

Step 5: Connect ggshield to your AI coding assistants

This is the step that addresses the actual gap this tutorial opened with. GitGuardian’s repository README lists Cursor, Claude Code, Copilot Chat, and Codex as the supported tools for this integration path. The install command targets one tool at a time and registers a hook inside that tool’s own extension or configuration system:

# Install the integration globally for a specific tool
ggshield install -t cursor -m global
ggshield install -t claude-code -m global
ggshield install -t copilot -m global
ggshield install -t codex -m global

# Or install for the current project only
ggshield install -t cursor -m local

Once installed, ggshield scans prompts and tool calls in the background, according to GitGuardian’s documentation. If you ask an assistant to “read my .env file and tell me what’s wrong with my database connection,” and that file contains a live credential, ggshield intercepts the read before the file content reaches the model’s context window and surfaces a warning in your terminal or IDE instead.

Fleet-wide deployment for teams

Running the install command on every developer’s laptop by hand doesn’t scale past a handful of people. GitGuardian’s September 2026 release notes describe a ggshield machine setup command designed for exactly this, paired with a scheduled MDM setup job that pushes the hook registration out without requiring each developer to run anything manually.

# Registers AI-tool hooks for the current machine,
# intended to run from an MDM-triggered script
ggshield machine setup

If your organization manages developer laptops through Jamf, Intune, or a similar MDM platform, package this command into a login script or a scheduled policy so new hires and newly provisioned machines get the protection automatically, rather than depending on every engineer remembering to opt in.

Step 6: Add a secrets.yaml ignore list for known false positives

Every secret scanner eventually flags something that isn’t actually a secret: a test fixture, a documentation example, or a placeholder string that happens to match an API key pattern. Rather than disabling detection for an entire file, ggshield supports a scoped ignore list.

# Generate a .gitguardian.yaml config file
ggshield config init

# Ignore a specific finding by its match, not the whole file
ggshield secret ignore --name "test-fixture-key" 

A sample .gitguardian.yaml for a typical project looks like this:

version: 2
secret:
  show_secrets: false
  exit_zero: false
  ignored_paths:
    - "tests/fixtures/*"
    - "docs/examples/*"
  ignored_matches:
    - name: "test-fixture-api-key"
      match: "sk-test-xxxxxxxxxxxxxxxxxxxx"

Keep this file in version control so the whole team shares the same ignore list, and review it periodically. An ignore list that grows unchecked becomes a place where real secrets hide in plain sight because everyone assumes “that file is already excluded.”

Step 7: Add ggshield to your CI pipeline

Local hooks protect individual developers, but they can be bypassed with git commit --no-verify, a different machine, or a direct push from a CI system. A pipeline-level check closes that gap. Here’s a GitHub Actions example:

name: Secret Scan
on: [pull_request]

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: GitGuardian scan
        uses: GitGuardian/ggshield-action@main
        env:
          GITGUARDIAN_API_KEY: ${{ secrets.GITGUARDIAN_API_KEY }}

Store the API key as a repository or organization secret, never as plain text in the workflow file. For GitLab CI, the equivalent job uses the official ggshield Docker image:

secret_scan:
  stage: test
  image: gitguardian/ggshield:latest
  script:
    - ggshield secret scan ci
  variables:
    GITGUARDIAN_API_KEY: $GITGUARDIAN_API_KEY

Step 8: Scan broader surfaces beyond git with a general-purpose secret hunter

ggshield is built around git-centric workflows and AI coding tool hooks, but secrets also pile up in places git never touches: shared drives, chat exports, ticket attachments, and old local disk backups. Help Net Security’s September 2026 coverage of open-source security tools describes Sift as a free command-line tool built specifically for this wider surface, covering local disks, Windows file shares, an entire Active Directory domain, SharePoint, OneDrive, Teams channel files, Slack messages, and Jira and Confluence.

Running a tool like this once a quarter against shared storage and collaboration platforms catches the credentials that never went near a repository, such as a password pasted into a Slack thread during an incident or an API key attached to a support ticket. Pair it with ggshield rather than treating either as a complete solution; they cover different territory.

Step 9: Configure detection sensitivity and severity thresholds

Default settings scan for every supported secret type at every severity. For a large legacy codebase, that can produce an overwhelming first-run report. Narrow the scope while you work through a backlog of findings:

# Only fail the build on high-severity findings while triaging
ggshield secret scan ci --minimum-severity high

# Output results as JSON for scripting a triage dashboard
ggshield secret scan path . --recursive --json > findings.json

# Count findings by secret type
cat findings.json | python3 -c "
import json, sys
from collections import Counter
data = json.load(sys.stdin)
types = Counter(f['type'] for r in data.get('results', []) for f in r.get('matches', []))
for t, c in types.most_common():
    print(f'{t}: {c}')
"

Raise the threshold back to default once the backlog is triaged. Permanently scanning only for “high severity” findings means medium-confidence matches, which still include real leaked credentials more often than teams expect, slip through silently.

Step 10: Build an incident response path for when a secret does leak

No scanner catches everything, especially secrets that existed before you installed one. Document a response path now, before you need it under pressure:

1. Rotate the exposed credential immediately at the provider (AWS, Stripe, database host, etc.) before doing anything else
2. Confirm the old credential is fully revoked, not just regenerated alongside the old one still being valid
3. Check provider-side access logs for any usage of the credential during the exposure window
4. Remove the secret from git history with a tool like git filter-repo, understanding this rewrites history and requires coordinating a force-push with your team
5. Add the pattern to your ignored_matches list only after confirming it’s genuinely a fixture, never to suppress a real leak
6. Document the incident, even briefly, so the team has a record of what leaked, when, and how it was fixed

Rotation always comes before history cleanup. A secret that has already been read by an AI model provider, a CI log, or a cached build artifact is not meaningfully “removed” from git history alone.

Step 11: Audit existing repositories for historical leaks

New hooks only protect new commits. Run a full historical scan across every repository your team actively maintains, prioritizing anything with production credentials or customer data models:

# Scan every branch, not just the default branch
ggshield secret scan repo . --branch=all

# Batch-scan multiple local clones with a shell loop
for repo in ~/projects/*/; do
  echo "Scanning: $repo"
  (cd "$repo" && ggshield secret scan repo . --json >> ~/secret-audit-log.json)
done

Budget real time for this step on an organization with dozens of repositories. It is not unusual for a first-time historical audit to surface credentials that were live for months or years.

Step 12: Extend coverage to non-code platforms your AI agents touch

AI coding assistants with tool-calling access often reach beyond the local filesystem. If your agents are configured with access to internal wikis, ticketing systems, or deployment dashboards, treat those as part of the same threat surface, since a credential pasted into a Confluence runbook is just as exposed to an agent’s tool calls as one sitting in a repo. GitGuardian’s broader platform (beyond ggshield’s CLI) extends detection to SharePoint, OneDrive, Teams, Slack, Jira, and Confluence for organizations on paid tiers, overlapping with the coverage Sift provides as a free alternative.

Step 13: Verify the full setup end to end

Run through this checklist before considering the rollout complete:

Check	Command	Expected result
CLI installed and authenticated	ggshield auth status	Shows a valid, active token
Pre-commit hook active	Commit a dummy secret	Commit rejected with a finding report
AI tool integration active	Ask an assistant to read a file with a fake key	Read blocked or flagged before model access
CI pipeline check active	Open a pull request with a dummy secret	Pipeline job fails the build
Historical scan completed	ggshield secret scan repo . --branch=all	Zero unresolved high-severity findings

Common pitfalls when rolling out secret scanning for AI tools

These mistakes show up repeatedly in team rollouts, and most of them are easy to avoid once you know to check for them.

• Installing the hook but never testing it. A hook that silently fails to register gives a false sense of coverage. Always run the dummy-secret test from Step 4 immediately after installation.
• Forgetting the AI-tool integration is per-tool, not global. Installing the Cursor hook does not protect Claude Code or Copilot sessions. Run the install command separately for every assistant your team actually uses.
• Treating --no-verify as an emergency escape hatch without a CI backstop. If developers can bypass the local hook freely and there’s no pipeline check, the hook is close to decorative.
• Letting the ignore list absorb real findings. Under deadline pressure, it’s tempting to add a genuine (but “probably fine”) finding to ignored_matches instead of fixing it properly. Review that file in code review, not just the code itself.
• Skipping the historical repo scan. New hooks protect new commits only. A credential committed two years ago is still fully exposed in git history until someone actively scans for it and rotates it.
• Assuming fleet-wide MDM deployment “just works” without verification. Spot-check a sample of machines after pushing ggshield machine setup through MDM; silent failures on a subset of devices are common with any fleet policy rollout.
• Not rotating a secret just because it was removed from a file. Deleting the line that contains the credential does nothing if the credential itself is still valid and sitting in git history or a model provider’s logs.

Troubleshooting ggshield setup issues

Work through this list when the setup doesn’t behave as expected.

• “Authentication failed” on ggshield auth status. Run ggshield auth login again; OAuth tokens expire and the CLI does not always surface a clear expiry message.
• Pre-commit hook doesn’t trigger at all. Confirm the hook file at .git/hooks/pre-commit is executable (chmod +x .git/hooks/pre-commit) and that you didn’t install a competing pre-commit framework hook that silently overwrites it.
• AI tool integration installed but nothing gets blocked. Restart the IDE or assistant application entirely; hook registration for Cursor and similar tools is often only picked up on a fresh launch, not a hot reload.
• False positives on every scan for the same string pattern. Add the specific match to ignored_matches in .gitguardian.yaml rather than disabling the detector type entirely, which would blind you to real secrets of that type elsewhere.
• CI job passes locally but fails in the pipeline. Check whether the CI environment has a different GITGUARDIAN_API_KEY scope or whether fetch-depth: 0 is missing from the checkout step, which limits how much history the scanner can see.
• ggshield machine setup succeeds on some machines but not others. Check OS-level permissions for the MDM agent; the command needs write access to each AI tool’s local hook configuration directory, which can be restricted by endpoint management policies.
• Scan is extremely slow on a large monorepo. Use --exclude flags to skip generated directories like node_modules, vendor, or build output, which inflate scan time without containing real secrets.
• Historical scan reports a finding that was already rotated. ggshield flags the pattern match in history regardless of whether the credential is still live. Mark it as resolved in the dashboard (paid tiers) or document it locally so it doesn’t get re-triaged every audit.
• Docker-based CI job can’t reach the GitGuardian API. Confirm the CI runner’s network policy allows outbound HTTPS to GitGuardian’s API endpoints; locked-down self-hosted runners sometimes block this by default.

Advanced tips for larger teams and regulated environments

Once the basic setup is stable, these refinements tighten coverage further without adding much day-to-day friction.

Pin the ggshield version in your CI configuration rather than always pulling latest. GitGuardian ships point releases frequently, and while that generally means faster detector improvements, pinning avoids a surprise behavior change breaking a pipeline mid-sprint. Bump the pinned version deliberately on a schedule instead.

For regulated environments handling payment data, health records, or government contracts, combine ggshield’s commit and AI-tool scanning with the broader guidance in the OWASP Top 10, which lists broken access control and cryptographic failures (including exposed credentials) among the most common root causes of real-world breaches. Secret scanning is one control among several, not a replacement for least-privilege credential issuance in the first place.

If your organization issues managed developer laptops, the UK National Cyber Security Centre’s guidance on protecting code repositories, available at NCSC’s developer collection, outlines complementary repository-level controls worth pairing with CLI-based scanning, including branch protection rules and mandatory code review before merge.

Consider short-lived credentials wherever your infrastructure supports them. A scanner that blocks a long-lived AWS access key from leaking is valuable, but a workload that only ever uses temporary STS tokens with a 15-minute expiry makes the entire class of leak far less dangerous even if a scanner misses it once.

Separate your detection tooling from your remediation workflow in whatever issue tracker your team already uses. A finding that sits only in a terminal scroll-back buffer or a CI log tends to get fixed by whoever happened to be watching that build; a finding that automatically opens a ticket with the file path, the secret type, and a rotation checklist attached gets fixed even when the original committer is on vacation. Several teams wire the --json output from a scheduled scan into a small script that files a ticket automatically, which turns secret scanning from a point-in-time check into an ongoing queue with actual ownership.

Finally, revisit your AI tool integration list every time your team adopts a new assistant. It’s easy to roll out protection for Cursor and Claude Code during an initial push and then forget to extend it when half the team quietly switches to a different tool six months later. Treat the ggshield install -t command as part of the standard onboarding checklist for any new AI coding tool, the same way you’d add a new linter or formatter to a project’s standard tooling.

Server-side protection for self-hosted git platforms

Everything covered so far runs on the developer’s machine or inside a hosted CI runner. Organizations running self-managed GitLab, Gitea, or a bare Git server over SSH have one more layer available: a server-side pre-receive hook that scans every incoming push before the server accepts it, regardless of whether the pushing machine has ggshield installed at all. This closes the gap left by a contractor’s laptop, a CI system outside your control, or a developer who simply never ran the setup steps in this guide.

# Example pre-receive hook for a bare git server
#!/bin/bash
while read oldrev newrev refname; do
  git diff "$oldrev" "$newrev" | ggshield secret scan docker -
  if [ $? -ne 0 ]; then
    echo "Push rejected: secret detected by GitGuardian"
    exit 1
  fi
done

Place this script at hooks/pre-receive on the server-side bare repository and make it executable. Because this check runs centrally, it also protects against the exact bypass pattern covered earlier, a developer running git commit --no-verify to skip the local hook, since the server never sees that flag and evaluates every push independently of how it was committed.

Complete working project: a protected repository template

Here is a minimal, complete setup you can copy into a new repository to have every layer covered from day one.

# 1. Initialize the repo and install ggshield
git init my-protected-project
cd my-protected-project
pipx install ggshield
ggshield auth login

# 2. Install the local pre-commit hook
ggshield install -m local -t pre-commit

# 3. Install AI-tool integrations for every assistant in use
ggshield install -t cursor -m local
ggshield install -t claude-code -m local

# 4. Create the config file
ggshield config init

# 5. Add a .gitguardian.yaml with a starter ignore list
cat > .gitguardian.yaml << 'EOF'
version: 2
secret:
  show_secrets: false
  exit_zero: false
  ignored_paths:
    - "tests/fixtures/*"
EOF

# 6. Add the CI workflow
mkdir -p .github/workflows
cat > .github/workflows/secret-scan.yml << 'EOF'
name: Secret Scan
on: [pull_request]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: GitGuardian scan
        uses: GitGuardian/ggshield-action@main
        env:
          GITGUARDIAN_API_KEY: ${{ secrets.GITGUARDIAN_API_KEY }}
EOF

# 7. Commit the baseline setup
git add .gitguardian.yaml .github/workflows/secret-scan.yml
git commit -m "Add GitGuardian secret scanning and AI tool protection"

This template covers four layers at once: commit-time blocking, AI assistant session scanning, pipeline-level enforcement, and a documented ignore policy that the whole team can review in pull requests rather than hiding in someone's local config.

Output examples: what a blocked scan actually looks like

A blocked pre-commit attempt produces output similar to this:

>>> GitGuardian has uncovered 1 incident

>>> Secret detected: AWS Access Key
Validity: Could not check (offline)
File: test-secret.env:1
    1 | AWS_SECRET_ACCESS_KEY=AKIA**************

Commit rejected.
Run `ggshield secret ignore ` to ignore this match in the future.

A successful CI scan with no findings reports cleanly:

No secrets have been found.
Scan completed in 1.42 seconds.
Exit code: 0

ggshield coverage comparison across deployment layers

Layer	What it catches	What it misses	Setup effort
Pre-commit hook	Secrets in staged diffs before commit	Bypassed by --no-verify; doesn't cover AI prompt content	Low
AI coding tool integration	Secrets read or generated during an assistant session	Per-tool install required; new assistants need manual setup	Medium
CI pipeline scan	Secrets in any pushed branch, bypass-proof	Catches leaks after the fact, not before a push	Medium
Historical repo scan	Secrets already sitting in git history	One-time unless scheduled to run periodically	Low, but slow on large repos
Cross-platform hunt (e.g. Sift)	Secrets in chat, tickets, shared drives, non-git storage	Separate tool, separate maintenance	Medium

Frequently asked questions

Is ggshield free to use?
Yes. The CLI, the pre-commit hook, and the AI coding tool integration all work on GitGuardian's free Community tier. Paid tiers add a centralized web dashboard, organization-wide historical scanning, and incident management features.

Which AI coding assistants does ggshield support?
GitGuardian's repository documentation lists Cursor, Claude Code, Copilot Chat, and Codex as supported targets for the ggshield install -t command as of the September 2026 release line.

Does ggshield slow down my AI coding assistant?
The scan runs locally against the content being read or sent, which adds a small, typically sub-second delay per flagged interaction. Unflagged interactions pass through without a noticeable difference.

Can I use ggshield without a GitGuardian account?
No. Authentication through ggshield auth login or a service-account API key is required even on the free tier, since the detection engine runs against GitGuardian's backend.

What should I do if ggshield flags a secret that's already been rotated?
Mark it resolved rather than deleting the finding silently, and confirm through your provider's access logs that the old credential shows no usage after rotation. A resolved finding still serves as a record that the leak happened.

Does the pre-commit hook replace GitHub's native secret scanning?
No, they're complementary. GitHub's native secret scanning works at the platform level after a push reaches GitHub's servers, while ggshield's pre-commit hook blocks the commit locally before it ever leaves your machine. Running both closes more of the gap than either alone.

How do I deploy ggshield to an entire engineering team at once?
Use ggshield machine setup triggered through your MDM platform's scheduled policy mechanism, rather than asking each developer to run the install commands individually. Spot-check a sample of machines afterward to confirm the hooks registered correctly.

What's the difference between ggshield and a general-purpose tool like Sift?
ggshield is purpose-built around git workflows and AI coding tool hooks. Sift, covered in Help Net Security's September 2026 open-source roundup, scans broader non-git surfaces like shared drives, SharePoint, and Slack. Most teams benefit from running both rather than treating either as complete coverage on its own.

Related Coverage

• DefectDojo Setup: 369 Scanners in 13 Steps [2026]
• Write Sigma Rules for Threat Detection: 13 Steps [2026]
• How to Install OpenVAS Greenbone Scanner: 13 Steps [2026]
• How to Set Up Pi-hole: 12 Steps, 45 Minutes [2026]
• How to Set Up Zeek 9: Network Monitor in 13 Steps [2026]