Release Date: August 10, 2026

Credential stealers do not hunt around a developer machine, they go straight for the handful of files where developers keep their secrets.

Endpoint Protection already gives you a full inventory of the credentials sitting in those files, and it now adds intrusion detection to that same deployment: ggshield plants a decoy AWS credential exactly where the stealers look first. The decoy opens nothing, so nobody has a reason to touch it. The moment someone does, you get an alert that names the compromised endpoint.

What does this mean for you?

• A tripwire on the surface attackers hit first: stealers arrive through malicious packages, trojanized tools, and rogue browser extensions. Whichever way they get in, reading that credential file is their first move, and that move is now what exposes them.
• Alerts with no ambiguity: the decoy has no legitimate use, so any use of it is unauthorized by definition. There is no baseline to learn, no tuning, and no signature list to maintain.
• A last line of defense: if malware has already slipped past your EDR and other endpoint controls, using the decoy still gives it away.
• A named machine to investigate: each event carries the IP address, user agent, and timestamp, and resolves to a specific endpoint and its owner.
• Coverage you can measure: a new Honeytoken protection card in the Endpoints dashboard reports the share of your fleet that is protected and lists the endpoints that are not, so you can drive coverage to completion.
• No new agent to deploy: planting reuses the ggshield binary you already install for scanning and writes a file rather than running a resident process.

Why is this important?

Credentials on developer machines have been a blind spot for a long time. Repository scanning, CI checks, and collaboration tool monitoring only ever see secrets that leave the laptop, while the credentials that stay local are exactly the ones harvesting malware is built to collect. Endpoint Protection brought those credentials into your inventory. It now watches for the theft itself, at the moment it happens, on a surface where most organizations have no detection at all.

For developers, this is invisible. Planting only ever touches its own credential profile and leaves every other profile on the machine untouched.

Start securing your endpoint fleet now!

Honeytoken protection is available now for workspaces with Endpoint Protection on a Business or Enterprise plan. If you already run endpoint scanning, adding it means nothing more than one MDM job to update and one more scope on your service account token.

• Protect endpoints with Honeytokens for how planting works, how to verify it, and how to remove it
• Deploy ggshield at scale with a service account token for the token scopes and MDM job setup
• Monitor coverage for tracking coverage across your fleet
• ggshield honeytoken plant for the full command reference

Enhancements​

• Public API: Added the ability to create Personal Access Tokens (PATs) and Service Account Tokens (SATs) programmatically via the API, enabling automated token rotation workflows. Tokens created via the API must have a finite TTL.
• ggshield: Launched an Azure DevOps extension that lets admins add a ggshield secret scan job to every pipeline in their organization with a single pipeline decorator. See Azure Pipelines for details.

Fixes​

• Audit Logs: Scans triggered via a Personal Access Token now emit an audit log event.
• Issue Tracking Integration: Fixed the "Edit issue" dialog closing unexpectedly.
• Notifications: Fixed an issue where the team name was not populated for notifiers when the workspace contained more than 100 teams.
• Access Management: Fixed an issue where deactivated members were incorrectly displayed in the grant access dialog.
• GitHub Checkruns integration: Fixed an issue where a disabled detector could still block pull requests.
• JFrog Artifactory Integration: Fixed an issue where the JFrog Container Registry reachability check did not route through ggbridge.
• GitLab Integration: Fixed an issue where GitLab sources appeared as monitored in the integration settings but were not reflected in the perimeter view.

  Release Date: May 21, 2026

Developers are writing more code than ever with Claude Code, Cursor, and other AI assistants - and a lot of that code touches secrets. The new open-source GitGuardian/agent-skills repository ships skills that teach those agents how to use ggshield: when to scan, how to read findings, and how to walk the developer through remediation.

What's in it?

• Claude Code plugin: a one-command install (/plugin install ggshield) that makes the skill available to Claude Code - the agent invokes it when the developer asks to scan, validate a token, or remediate a leaked credential.
• Cursor rules & commands: the same skill packaged for Cursor, exposing the ggshield workflow so the agent can call it on demand.
• Defense in depth (optional): layer the ggshield agent hook on top (ggshield install -t claude-code) - unlike the skill, the hook runs automatically and scans every prompt, tool call, and tool output from inside the agent.

Why is this important?

We are meeting developers where they already are - no new tool to adopt, no workflow change. When the developer brings up secret scanning, key validation, or a leaked credential, the agent now knows to reach for ggshield, how to interpret the findings, and how to guide remediation in context. Pair it with the ggshield hook for fully automated, agent-side scanning. Either way, fewer secrets slip through AI-assisted development - with zero friction added to the developer's day.

Get Started Today!

The repository is public, MIT-licensed, and ready to demo:

• Browse the skills on GitHub
• Install the Claude Code plugin with /plugin install ggshield
• Or drop the Cursor rules into your .cursor/ directory

Contributions and feedback are welcome - open an issue or a pull request on the repo.

Enhancements​

• Sources health management — Jira Data Center: GitGuardian now pauses real-time ingestion and historical scans on unreachable Jira Data Center sources, auto-resumes them once health is restored, and surfaces an actionable recovery step. Rolling out to more integrations in upcoming releases. See the Jira Data Center integration guide.
• Jira Cloud - recurrent scanning instead of webhooks: Jira Cloud monitoring now relies on scheduled recurrent scans instead of inbound webhooks. See the Jira Cloud integration guide.
• VCS - scan orphaned commits and Git notes in historical scans: Historical scans on Version Control Systems now fetch every reference the remote exposes - pull/merge request refs, Git notes, GitLab keep-around refs, Gerrit change refs, and any other custom namespace - on top of standard branches and tags. Secrets in closed PRs, force-pushed history, and Git notes are no longer blind spots. See Manage your monitored perimeter.

Fixes​

• Perimeter: Fixed an issue where unmonitored sources were incorrectly displayed as deleted in the user interface.

  Release Date: April 10, 2026

AI coding assistants like Cursor, Claude Code, and GitHub Copilot can now read files, run shell commands, and call external tools during a session. That makes them powerful, but it also means secrets can be exposed before code ever reaches a repository or CI pipeline. ggshield now scans AI interactions in real time and blocks secrets before they are sent to a model or executed.

What does this mean for you?

• Prompt scanning: Secrets in your prompts are caught before they reach the AI model.
• Tool call protection: File reads, shell commands, and MCP calls are scanned before the AI assistant executes them.
• Post-action alerts: If a tool output contains secrets, you get a desktop notification so you can act immediately.
• Simple setup: A single ggshield install command configures hooks for your tool of choice.

Why is this important?

Prompts, local file access, shell output, and MCP tool calls sit outside the controls that protect repositories and CI pipelines. A developer might paste an API key while debugging, or an AI agent might read a .env file and pass credentials to a model provider. These interactions are invisible to most security programs today. Secret scanning at the hook level closes that gap, giving security teams visibility and control over what flows through AI-assisted development workflows.

Get started

1. Make sure you have ggshield 1.49.0 or later installed
2. Run ggshield install -t <tool> -m global where <tool> is cursor, claude-code, or copilot
3. Start coding: ggshield will automatically scan prompts and tool calls in the background

Check out the full setup guide to learn more.

---

Enhancements​

• Risk Score: Shipped an updated model that improves separation between low-risk noise and higher-priority findings; some incident scores may shift. Learn more.
• Saved views: The Critical saved view is now the default when you open the Internal Monitoring incidents page. Learn more.
• Public API:
  • Added privacy mode support, allowing users to control secret content visibility when retrieving secrets via API endpoints. Learn more.
  • Added new endpoints to trigger and cancel historical scans programmatically, enabling integration of scan management into automated workflows. Learn more.
  • Added severity_rule_id and detector category to the incident response - for both internal and public secret incidents.
  • Added a new GET /v1/severity-rules endpoint to list severity rules.
• Authentication: The SSO domain is now remembered after logout, allowing users to reconnect with a single click instead of re-entering their domain each time.
• Public exposure: "Found outside perimeter" leak details are now visible to all customers, regardless of Public Monitoring subscription. This allows users to better assess and qualify the signal as we continue to improve the reliability of this detection. Access to this information may evolve as the feature matures.

Fixes​

• Secrets Detection: Fixed an issue where ggshield could return an incorrect incident URL when two secrets shared the same hash across different repositories with the "Group by secret per source" enabled.
• Analytics: Fixed an issue where the "All time" date range filter did not consistently cover all incidents, potentially causing some older incidents to be excluded from analytics views.
• Jira Data Center Integration: Fixed an issue where Jira Data Center source connections could intermittently lose authentication.
• Honeytoken: Fixed a deployment job failure caused by an encoding error when interacting with the GitLab API during honeytoken deployment.
• Public API: Fixed an error when querying occurrences for public incidents originating from Explore Search.