Validate and roll out

Validate on 10 to 20 machines

Before broad rollout, deploy to 10 to 20 closely monitored machines and confirm all of the following:

• ggshield installs successfully, and ggshield --version reports 1.53.0 or later.
• The binary is on every user's PATH. With the install script, GGSHIELD_BIN_DIR=/usr/local/bin keeps it reachable from an MDM job that runs as root and from sudo -i.
• ggshield plugin list shows machine_scan for the scan user.
• Admin jobs inject the SAT through stdin, so it stays out of command lines and shell history. Your MDM redacts secret environment variables and captured stdin from its logs.
• ggshield machine setup exits successfully and is idempotent: a second run adds nothing that is already in place.
• ggshield auth logout --no-revoke, then ggshield auth login, ran as the logged-in user. Login opens a browser in their session. For EU or self-hosted instances, both commands used --instance.
• Recurring ggshield machine setup still injects the admin SAT through stdin.
• ggshield machine report exits successfully, whether you inject the SAT for that job or run it as the logged-in user after login.
• ggshield machine doctor exits zero when run from inside a git repository, which is what it needs to resolve the effective core.hooksPath. Use it as the MDM audit script that gates the next wave. Every failed check prints its own fix.
• Scan duration is acceptable, and users do not report noticeable performance issues.

If you are deploying honeytoken protection, also confirm:

• ggshield honeytoken plant --list-targets resolves the expected target on a test machine.
• After machine setup, the honeytoken is present and the developer's existing AWS profiles are untouched.

If you are deploying AI Hooks, also confirm:

• machine doctor reports the hook installed for every AI coding assistant it finds on the machine.
• The developer is logged in. On a sample machine, pasting a test credential into a prompt shows the ggshield blocking message. If they are not logged in, the hook fails open and only shows a warning.

If you are collecting the AI and MCP inventory, also confirm:

• ggshield ai discover exits successfully.

Only continue to percentage-based rollout after this first group is healthy.

Confirm visibility in the Endpoints dashboard

In your GitGuardian dashboard, open Endpoint protection > Endpoints and verify the pilot machines appear as expected:

• The machines table lists each pilot endpoint with a latest endpoint scan time, not Never scanned.
• Fleet coverage KPIs reflect the pilot group, so the Endpoints scan percentage rises after scans run.
• Opening a machine shows Local scanning with severity counts and a ggshield scanner version on the latest scan.
• The Discovered secrets table loads for machines where the scan found credentials. An empty table is acceptable on a clean test machine.
• If you deployed honeytoken protection, the pilot machines show as Protected, and the Honeytoken protection card on a machine reports a recent latest sync.
• If you deployed AI Hooks, the AI hooks coverage card reflects the pilot group, and the AI agents column shows which agents have guardrails.
• If you deployed the AI and MCP inventory, the AI Agents tab on a machine lists the agents and MCP servers ai discover found, including whether each agent's subscription is personal or company.

For the CLI and MDM checks above, see Deploy ggshield at scale with a service account token. For how to read each view, see Monitor coverage.

Roll out at scale

Here is the suggested rollout path:

10-20 monitored machines → 1% → 10% → 25% → 50% → 100%
             |             |     |      |       |
             +-------------+-----+------+-------+-- pause / rollback gates

We recommend the following approaches for a successful scaled rollout:

• Split waves by region, timezone, business unit, OS, or device type.
• Spread first scans across hours or days, not minutes.
• On Windows, deploy the Microsoft Defender exclusion for the scanner process with the package, so pilot scan durations are representative.
• Use package caching or internal distribution for very large fleets.
• Monitor errors and endpoint impact before each increase. Gate the next wave on ggshield machine doctor returning zero on a sample of the current wave.

Roll back

Disable the scheduled jobs first, especially machine setup. That job reconciles honeytokens against GitGuardian on every run, so a cleanup pass is undone the next day if setup is still enabled.

Then clear what is already on disk:

• Honeytokens: ggshield honeytoken plant --remove-only.
• AI Hooks: delete the ggshield entries from the tool's hook configuration, listed in Prevent leaks with AI Hooks.

ggshield auth logout --no-revoke as the logged-in user removes their personal token. Revoke the admin SAT in your workspace to cover the whole fleet at once.