Core concepts
What is Endpoint Protection?
GitGuardian Developer Endpoint Protection extends secrets security to developer workstations. Credentials accumulate in shell history, config files, IDE caches, browser stores, and the files and caches that AI coding agents create on the local filesystem — places outside the reach of repository scanners and CI checks. Endpoint Protection discovers those credentials on the machine where they live.
Why it matters
As a security or platform lead, you typically already scan repos and CI. Endpoint Protection answers questions those layers cannot:
- What credentials are sitting on developer laptops right now?
- Which machines were scanned recently, and which were never scanned?
- After a compromise, what was on a given machine, ranked by severity?
What it does
Machine scan — Recursively discovers plaintext credentials across the local filesystem, including config files, dotfiles, logs, IDE caches, and browser data. Findings are reported to the GitGuardian inventory, where each one is scored by severity and access scope, and can then be forwarded to your SOC, SIEM, or SOAR.
Honeytoken dissemination on endpoints — Deploys decoy credentials directly on developer machines. Any attempt to use them triggers a real-time alert, turning each endpoint into a tripwire for infostealers and lateral movement.
AI hooks — Guardrails integrated into Claude Code, Cursor, Copilot, and other coding agents to prevent them from reading, copying, or transmitting secrets across files, tools, and chats — the fastest-growing leak vector in modern development workflows.
Local agent and MCP inventory — Visibility into which AI agents and MCP servers run on each endpoint, what data and tools they can access and usage.
How scanning works
ggshield runs the scan locally on the endpoint. Results are uploaded to your GitGuardian dashboard (SaaS or self-hosted) for centralized visibility.
What is sent to GitGuardian: The secret hash, not the secret value. GitGuardian stores metadata and context around the finding — not the credential itself. Source documents from the filesystem are never transmitted to GitGuardian's servers.
Public leak check: Secrets are hashed locally using GitGuardian's HasMySecretLeaked (HMSL) protocol and compared against GitGuardian's database of known-leaked secrets. The secret value is never transmitted.
Validity checks: For active secrets (AWS keys, GitHub tokens, etc.), ggshield calls the provider's API directly from the endpoint to verify validity and retrieve metadata such as scopes and owner. This call goes from the endpoint to the third-party provider — not through GitGuardian's servers.
What is scanned
The engine performs a full filesystem traversal, covering any file that may contain a secret:
- Shell history files (
.zsh_history,.bash_history, etc.) - Configuration files (
.env,.gitconfig,.npmrc, SSH configs, credential files) - Cloud credential stores (for example
~/.aws, GCP, or Azure CLI caches) - AI coding agent caches and histories (Cursor, Claude Code, Copilot, MCP configs, etc.)
- Temporary directories and browser storage
- Structured data files (CSV, SQL, XLSX, PDF, SQLite)
- Archives (
.zip,.jar,.war,.ear) and compressed files (.gz,.bz2,.xz,.zst) - Any file matching patterns associated with secrets (API keys, tokens, certificates, private keys)
Security teams can define exclusion lists to exclude specific directories or file types from the scan scope.
Machine scan focuses on credential accumulation across the full filesystem and does not limit itself to Git repositories.
Platform support
| Platform | Architecture | Status |
|---|---|---|
| macOS (workstations) | arm64 (M1/M2/M3/M4), x86_64 | ✅ Fully supported |
| Linux (workstations) | arm64, x86_64 | ✅ Fully supported |
| Windows (workstations) | x86_64 | ✅ Fully supported |
| Linux servers (RHEL, Debian, Ubuntu) | arm64, x86_64 | 🚧 Beta |
| Windows Server (2022 & 2025) | x86_64 | 🚧 Beta |
