You can now mention members and teams directly in incident notes and feedback. Type @, pick a member or team from the searchable list, and they are notified, so the right people see the incident without leaving the note.

What does this mean for you?

• Loop in the right people instantly: Mention a member with @name or a whole team with @team-name. The mentioned member, or every member of a mentioned team, receives an email linking straight to the incident.
• Faster collaboration on incidents: Keep the conversation where the work happens, with no switching to Slack or email to ask a teammate to take a look.
• Works across the platform: Mentions are supported on both Internal Monitoring and Public Monitoring incidents.

Why is this important?

Remediation is a team effort. When an incident needs a specific owner or a team's attention, mentions cut the back-and-forth and shorten response time, while respecting existing permissions.

Get started today!

Open any incident, add a note or feedback, and type @. Manage your mention emails from your notification settings under Workspace.

Enhancements​

• Sources health management for ServiceNow, JFrog Container Registry, JFrog Package Registry, and Microsoft OneDrive: Extending the source health coverage from previous releases, GitGuardian now pauses real-time ingestion and historical scans on unreachable sources of these types, auto-resumes them once health is restored, and surfaces an actionable recovery step. Rolling out to more integrations in upcoming releases. See the integration guides for ServiceNow, JFrog Container Registry, JFrog Package Registry, and Microsoft OneDrive.
• Perimeter source status: sources now show a status (Monitored, Unmonitored, Unreachable, Archived, or Deleted) that you can filter on from the perimeter page and the incident list, and save as a view (e.g. to set aside incidents from archived or deleted sources). Note: a valid secret in an archived or deleted source is not necessarily less risky. See Manage your monitored perimeter.
• GitHub check runs, scan very large pull requests (Business plan): Previously, pull requests above the size limit (200 commits, 60,000 files, or 300,000 lines changed) were skipped to protect your GitHub API rate limit. On the Business plan, GitGuardian now scans these oversized pull requests by cloning the repository branch instead of calling the GitHub API commit by commit. This reuses the clone-based approach already used for historical scans, avoiding rate-limit consumption while still scanning the full pull request. On other plans, oversized pull requests are still skipped. Learn more.
• Custom Sources (BYOS), scan with validated detectors only: Custom Source installs can now enable a "use only detectors with validators" option. When it is on, a source-linked scan keeps only secrets whose detector supports validity checks and drops the rest before the validity check runs, cutting noise from matches that can never be verified. The option is opt-in per install. Learn more.
• JFrog Container Registries: Backfilled author information for existing JFrog container registry occurrences.

Fixes​

• Audit Logs: Changes to monitoring settings (such as toggling automatic monitoring on or off) are now logged in the audit trail.
• Custom Webhooks: Fixed an issue where Discord webhook notifications were not triggering on incident alerts.
• Jira Cloud Integration: Fixed an issue where Jira Cloud sources were not performing recurrent scans as expected.
• Bitbucket DC Integration: Fixed an issue where some Bitbucket Data Center sources stopped being monitored after infrastructure maintenance.
• GitLab Integration: Fixed an issue where updating the integration token failed with an "invalid token" error.

Until now, a generic password or high-entropy secret hardcoded in a Jira ticket, a Confluence page, or a Slack message went undetected. GitGuardian now runs Generic Password and Generic High Entropy Secret detection on your non-code sources (Confluence, Jira, Slack, Microsoft Teams, and others). This is one of the most requested improvements from teams who already monitor their code with GitGuardian and want the same coverage everywhere.

What does this mean for you?

• Instant visibility: findings from your non-code sources that were previously hidden now appear in your dashboard, already flagged as false positives where it applies.
• Real-time coverage: any new content scanned from Confluence, Jira, Slack, Microsoft Teams, and other non-code sources immediately benefits from generic detection and false positive filtering.

Why is this important?

Generic detection now gives your non-code sources the same coverage you already rely on for your code. To keep that coverage high-signal, the False Positive Remover runs on every finding. It already filters your VCS findings, and we have extended it to non-code sources with an LLM-based model. In our benchmark, it identified 25 to 40% of generic findings as false positives and tagged them before they reached the dashboard.

The result: broader coverage, high signal.

Get Started Today!

Generic detection on non-code sources is enabled by default for Business accounts with AI features enabled. No action is required. To review or change your AI configuration, see AI settings.

Learn more about the False Positive Remover

Enhancements​

• Jira Notifier: Added remediation guidance content and detector-specific links as assignable metadata fields in the Jira integration ticket description template.

Fixes​

• Notifications: Fixed an issue where Discord webhook integrations failed to trigger on incident alerts.
• Incidents Dashboard: Fixed a display and filtering issue with the False Positive tag that caused it to behave incorrectly in the UI.
• Perimeter Management: Fixed an issue where toggling the Team Perimeter view between tree and list modes incorrectly marked the selection as modified.
• NHI Inventory: Fixed a data inconsistency where the "files requiring code fix" count could differ between the UI and API responses.

The ServiceNow issue-tracking integration now covers Public Monitoring and Honeytoken events alongside Internal Monitoring, and brings the Smart Notifier filters to ServiceNow. You choose which incidents flow into ServiceNow and which events appear on their tickets, keeping your ticketing scoped to what matters.

What's new?

Event Group Selection: Choose whether ServiceNow creates tickets for Internal monitoring, Public monitoring, or Honeytoken events.

Public Monitoring Support: Route public monitoring incidents to ServiceNow, so secrets exposed on public sources are tracked in the same workflow as your internal incidents.

Honeytoken Support: Create ServiceNow tickets for honeytoken events, bringing decoy alerts into your remediation workflow.

Granular Event Subscription: Previously, you could not choose which events reached ServiceNow. The new Notify when section now lets you select them. The New incident detected event (always included) creates the ticket; the other events you select are posted as comments on that same ticket, keeping the full incident history in one place. For Internal and Public Monitoring, use filters and presets - by severity, risk score, validity, secret type, or tag - to refine the selection, or start from scratch.

Why is this important?

Security teams need ticketing scoped to their remediation work. Event group selection and granular subscription route only the incidents you care about into ServiceNow, cutting noise. Public Monitoring and Honeytoken support bring perimeter and decoy alerts into the same workflow as internal incidents.

Get Started Today!

Available for all workspaces. Existing ServiceNow integrations keep their current settings, and new configurations can enable the expanded event coverage.

Learn more about the ServiceNow integration | Configure honeytoken alerts

Enhancements​

• Sources health management — Confluence Cloud, Slack, Gerrit, and Microsoft SharePoint Online: GitGuardian now pauses real-time ingestion and historical scans on unreachable Confluence Cloud, Slack, Gerrit, and Microsoft SharePoint Online sources, auto-resumes them once health is restored, and surfaces an actionable recovery step. Rolling out to more integrations in upcoming releases. See the integration guides for Confluence Cloud, Slack, Gerrit, and Microsoft SharePoint Online.
• Incident Notifications: Incident notifications in Slack and Microsoft Teams now include the risk score and severity information.
• AWS Marketplace: Added support for a second AWS Marketplace seller account (GitGuardian Inc., US entity), enabling US customers to transact through the US listing while existing customers continue through the original French listing.
• Public API: Added a new API endpoint to retrieve the activity log of a secret incident, enabling automation and monitoring workflows. Learn more.

Fixes​

• Security: fixed an issue where a Service Account Token (SAT) could revoke itself through the public API (e.g. via ggshield auth logout), which could disable every deployment sharing that token. A SAT can now only be revoked from the dashboard or by another token holding the api_tokens:write scope; Personal Access Token self-revocation is unchanged. Learn more.
• Incident assignment: Assigning a secret incident now automatically grants the assignee the access they need. Previously, an assignee without access could receive the notification email but be unable to open the incident.
• Incident details: Fixed an issue where the incident detail view could display the wrong secret line when privacy mode was enabled, due to position misalignment caused by content obfuscation.
• Custom tags: Fixed an issue where members were unable to remove the last custom tag from an incident.
• Custom webhooks: Creating a webhook with an unreachable URL now shows a clear error message instead of failing with a generic server error.
• Playbooks: Fixed unexpected behavior with the auto-grant developer access playbook where access was not correctly applied in certain configurations.
• Activity logs: The auto-grant access playbook now records an entry in the related issue's activity log, consistent with other playbooks.
• JFrog Container Registry: Fixed an issue where only the first ~200 repositories were discovered, leaving the rest unmonitored and sometimes flagged as deleted. All repositories are now discovered.
• GitLab: Fixed a health check that could incorrectly mark a reachable GitLab instance as unavailable when its endpoint returned a 4xx response.

Every incident used to trigger an alert, a ticket, or an email regardless of how critical it was, leaving teams to drown in noise. Smart Notifiers lets you define per-channel rules so a notification is only sent for the incidents that matter - filtering by severity, ML risk score, validity, secret type, or GitGuardian tag, across both internal and public monitoring. No more third-party middleware to filter before routing.

Available now for custom webhook, Slack, and Microsoft Teams. Email alerting can also filter public monitoring incidents by severity.

Get started: configure rules from your notifier settings. See Alerting and notifications and the custom webhook, Slack, Microsoft Teams, and email alerting guides.

Coming next: ServiceNow & Jira, Splunk & PagerDuty, Discord, Email filtering beyond severity and internal monitoring support.

Enhancements​

• Sources health management — Confluence Data Center and Microsoft Teams: GitGuardian now pauses real-time ingestion and historical scans on unreachable Confluence Data Center and Microsoft Teams sources, auto-resumes them once health is restored, and surfaces an actionable recovery step. Rolling out to more integrations in upcoming releases. See the Confluence Data Center integration guide and the Microsoft Teams integration guide.
• Overview analytics: now include Non-Human Identity (NHI) and Public Monitoring data.
• GitHub check runs: a new setting lets you skip merge commits in pull request check runs. When enabled, check runs only flag secrets introduced by commits authored on the PR branch, reducing false positives caused by secrets pulled in from the target branch via merge commits. See Detect secrets in real time in GitHub.
• GitHub check runs - large pull requests: check runs now skip the scan on pull requests above a configured size limit to protect your organization's shared GitHub API rate limit. Previously these pull requests would time out or fail. See Detect secrets in real time in GitHub.
• Ticketing integration: you can now dissociate a Jira or ServiceNow ticket from an incident directly from the incident detail page, without deleting the external ticket itself.
• ServiceNow ticketing integration: added support for the Feedback Received event in event-based notifications. See the ServiceNow integration guide.
• Incidents:
  • Added ability to filter incidents by closure reason.
  • Increased the character limit for secret value search on the incidents page, so longer secrets such as large JWTs are matched correctly.
• Historical scans: improved scanning performance on large repositories, reducing timeouts and scan failures.
• GitLab integration: Read-only tokens are now fully supported for GitLab group hook installations, with setup instructions for manual webhook creation displayed when needed.

Fixes​

• Security: fixed a cross-site scripting (XSS) vulnerability on the mTLS redirect page where the retry button URL could be manipulated via a query parameter.
• Developer share links: fixed an issue where custom remediation guidelines were not displayed on the incident share page.
• Public monitoring: clicking the incidents column on the Secret Graspers settings page now correctly navigates to the Incidents tab with the matching filter applied.
• Slack notifications: fixed a "this team does not exist" error that could occur when adding Slack alert notifications on free plan.
• Jira & Confluence: fixed an unknown scanning error caused by provider rate limits.
• GitHub: fixed a Forbidden error on unauthenticated requests to the GitHub API root endpoint.

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.

Cut incident triage time by getting straight to the right list. The search bar now answers the questions you actually ask during triage - "what did Alice leak in the last 3 months?", "which unassigned critical incidents need owners?" - without forcing you through a chain of filter menus.

What's new?

• Search by secret value: paste a secret directly into the bar to see if it's already raised an incident. The value is hashed in your browser before being sent, so the plaintext never leaves your device.
• Search by commit author: type a developer's name or email fragment (e.g. @contractor.com) to surface every incident with at least one occurrence introduced by that person.
• Search by file path: type any portion of a path (e.g. .env, docker-compose.yml, config/secrets) to filter incidents whose occurrences match.
• Search by source name: type any portion of a repository, channel, drive, or project name to scope the page to that source.
• Natural language search (AI Filters): when AI Filters are enabled on your workspace, type a full sentence and GitGuardian translates it into the right combination of filters - for example, Open critical unassigned incidents related to cloud providers.

All search modes compose. You can mix structured filters, raw text, and a natural-language prompt in the same query, and save the result as a view to share with your team.

Why is this important?

Incident triage is fastest when you don't have to leave the page or know the exact filter name. By making the search bar the single entry point for every way you might describe what you're looking for, GitGuardian removes a layer of clicking from your day-to-day triage workflow - whether you're chasing a specific token, auditing a developer, or scoping leaks to a critical file.

Get Started Today!

The new search modes are available immediately on every workspace, on every plan. Natural language search requires AI Filters to be activated - see AI settings for the workspace settings and self-hosted prerequisites.

Learn more about the search bar

Enhancements​

• Microsoft Teams notifications: Backfilled the Issue Regression event for existing Microsoft Teams notifier configurations - channels now alert when a previously resolved incident reopens, in addition to new incidents and new occurrences. Learn more
• JFrog Artifactory scanning: Incident details now capture additional metadata for secrets found in JFrog Artifactory, making it easier to identify the leak author and assign incidents to the right owner.
• Sources health management — Jira Cloud: GitGuardian now pauses real-time ingestion and historical scans on unreachable Jira Cloud 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 Cloud integration guide.
• Risk score in alerting and ticketing: Incident risk score update events are now available in Custom Webhook, Slack, Microsoft Teams, ServiceNow, Jira Cloud, and Jira Data Center.

Fixes​

• Secret revocation: Fixed a case where revoking a Sendgrid API key from GitGuardian could surface a misleading error because the validity check was not re-run after the revocation request.
• Team perimeter: Restored the ability to bulk select all results when adding JFrog Artifactory sources to a team perimeter, previously broken on workspaces with large Artifactory repositories.
• GitHub health check: The GitHub and GitHub Enterprise health check now probes the documented /meta endpoint instead of the API root. This fixes false Unhealthy statuses reported after upgrading to GitHub Enterprise Server 3.19.4.
• Analytics: Fixed an issue where GitHub PR Check runs analytics dashboards were not displayed for GitHub Enterprise integrations.
• Perimeter performance: The source list now renders independently of the overview sidebar queries, fixing failed page renders on workspaces with very large source inventories (200k+ sources).

We're excited to announce a major enhancement to our Microsoft Teams integration that brings comprehensive notification coverage for all incident lifecycle events, honeytoken alerts, and public monitoring incidents. This unified notification framework provides complete visibility into your security posture directly in Microsoft Teams.

What's new?

Complete Incident Lifecycle Coverage: Previously, Microsoft Teams notifications only covered new incident detections and regression. Now you can receive notifications for every critical event including resolution, assignment, status changes, comments, access control, and sharing - giving you complete visibility into incident management workflows.

Public Monitoring Support: Public monitoring incidents can be sent directly to Microsoft Teams channels, enabling teams to receive perimeter security alerts alongside internal monitoring alerts.

Honeytoken Alerting: Microsoft Teams notifications now support honeytoken events, providing immediate alerts for honeytoken activity, previously only available via custom webhooks and email.

Flexible Configuration: Enhanced Microsoft Teams configuration allows teams to subscribe to specific event types per channel, providing granular control over notification preferences.

Why is this important?

Security teams need real-time visibility into all security events to respond quickly and effectively. This enhancement addresses key customer feedback about missing notification updates for incident resolution and status changes, while extending Microsoft Teams integration to public monitoring and honeytoken.

Get Started Today!

This enhancement is automatically available for all workspaces. Existing Microsoft Teams integrations will maintain their current notification settings, while new configurations can be set up with expanded event coverage.

Learn more about Microsoft Teams integration configuration | Configure honeytoken alerts

Enhancements​

• Public API: New Health Checks endpoints let you programmatically monitor the health of your integration instances (GitHub, GitLab, Slack, Jira, and more). List the latest health check across all instances, filter by integration type, status, or date, and retrieve the full health check history for a specific instance to power your own dashboards and alerting.
• Public API: You can now retrieve and filter archived sources.
  • Sources endpoint: now offer the provider_metadata.archived field (currently available for GitHub sources) and a provider_metadata_archived=true filter.
  • Incidents endpoint: now offer an only_on_provider_archived_sources=true filter to focus on incidents from archived sources and run bulk actions on the returned list.

We're excited to announce that file attachment scanning is now supported for Jira Cloud, Jira Data Center, Confluence Cloud, and Confluence Data Center.

You can now detect secrets in both textual content and uploaded files, giving you full coverage across your Atlassian sources.

Why this matters

Security-relevant content is frequently shared as screenshots, exported logs, reports, and documents attached to tickets or wiki pages. By scanning both attachments and page or issue content, GitGuardian helps you reduce missed exposures and improve remediation coverage across your Atlassian environment.

• Complete source coverage: Detect leaks in issue/page content and file attachments.
• Fewer blind spots: Catch secrets hidden in uploaded logs, reports, screenshots, and documents.
• Consistent experience: Atlassian attachment coverage now aligns with existing support in Microsoft Teams, Slack and other Corporate Data Sources.

Already using Jira or Confluence sources? Here's what you need to know:

• New scopes required: Attachment scanning rely on additional API scopes for Jira and Confluence Cloud (read:attachment:jira on Jira Cloud and readonly:content.attachment:confluence on Confluence Cloud). Reinstall each affected integration from Settings → Integrations → Sources so new OAuth applications include the new permissions.
• Run Full Historical Scan: To avoid any blindspot, we strongly recommend you re-execute the entire historical scans from your Confluence and Jira sources. This will ensure GitGuardian scans all attachments from the past.

Get started today

Check the updated documentation:

• Integrate Jira Cloud
• Integrate Jira Data Center
• Integrate Confluence Cloud
• Integrate Confluence Data Center

--

Enhancements​

• Public API: Removed the deprecated Honeytoken Labels API endpoints. Customers using custom tags should now use the Custom Tags API instead.
• Jira Notification: Jira templates now flag unsupported required fields at configuration time, preventing configurations from being saved with fields that would fail at send time.
• GitHub Check runs: Improved reliability of GitHub PR checks during partial outages for workspaces using GitGuardian Bridge.

We're excited to announce that the GitGuardian Slack app is now officially listed and approved on the Slack Marketplace, available in both US and EU regions ! This means you can install GitGuardian directly from Slack's app directory, and the peace of mind that comes with Slack's marketplace review process. Beyond marketplace approval, this release bundles several improvements to the Slack integration that make it more powerful, more privacy-aware, and easier to operate at scale.

What's new?

• Channel selection at setup time: You now choose which public channels to monitor during installation, instead of the app automatically joining every public channel. This gives you full control over your scanning perimeter from day one.
• File attachment scanning: Secrets hiding in file attachments dropped in channels and messages are now detected alongside text-based messages.
• Interactive messages (Beta): When GitGuardian detects a secret, it posts a threaded response directly in the original conversation with details about the finding and quick actions — including the ability to ignore low-risk incidents without leaving Slack.
• Enhanced privacy controls: Private channel names are now redacted for users who don't have access to those channels in Slack, fully respecting Slack's privacy model. A privacy information banner is also displayed during setup to clarify what GitGuardian can and cannot access.

Why does this matter?

Slack is where developers share code snippets, debug outputs, and configuration examples in real-time. These casual exchanges frequently contain accidentally pasted API keys, database credentials, and tokens that persist in chat history. With the new GitGuardian Slack app, you extend your proactive defense and efficiently streamline the efforts with the responsibles of the leaks!

Get started

1. Open the listing for your region: GitGuardian (US) or GitGuardian EU.
2. In GitGuardian, go to Settings → Integrations → Sources and install Slack from the Messaging section, then complete the OAuth flow for your workspace.

If you previously covered your Slack Perimeter with GitGuardian, you will need to reinstall your Slack App using the same procedure.

Check out the full Slack integration guide for perimeters, private channels, and interactive messages configuration.

Enhancements​

• Accessibility: Added support for Ctrl+Enter to submit forms, improving keyboard navigation efficiency.
• Jira Integration: Dynamic variables (e.g., {secretType}, {sourceName}, {sourceType}) can now be used across all Jira fields — including Labels, Summary, Priority, and custom fields — not just the description. Variables are interpolated at incident creation time, making it easier to build filtered Jira dashboards and reports. Learn more.

Fixes​

• Dashboard: Fixed an issue where filtering Personal Access Tokens could cause the UI to become unresponsive.
• Bitbucket Cloud Integration: Updated API calls to use the new workspace-scoped endpoints, following Bitbucket Cloud's deprecation of cross-workspace APIs.

We're excited to announce native support for Gerrit as a VCS source. Gerrit is widely used for enterprise code review workflows, often hosting sensitive internal repositories. You can now connect your Gerrit instance to GitGuardian to detect secrets exposed across your repositories and commit histories, with the same experience as our other VCS integrations.

What does this mean for you?

• Historical scanning out of the box: GitGuardian performs a full scan of your repositories' commit history as soon as you connect your Gerrit instance, uncovering secrets that may have been exposed weeks, months, or years ago.
• Real-time detection with the webhook plugin: Install the Gerrit webhook plugin to catch new exposures the moment commits are pushed.
• Granular perimeter control: Choose exactly which repositories to monitor, and apply team-based access control just like with other VCS sources.
• Read replica support: Point GitGuardian to a read replica for cloning operations to reduce load on your primary Gerrit server.

Why is this important?

Gerrit repositories often host some of an organization's most sensitive internal code, yet many security programs lack visibility into them. Credentials and API tokens committed to Gerrit can remain in git history indefinitely, exposing internal systems and infrastructure to anyone with repository access. Native Gerrit support closes this gap and extends GitGuardian's secrets detection coverage to another critical part of your development ecosystem.

Get started

1. Generate an HTTP username and HTTP password in your Gerrit account settings (we recommend using a dedicated bot user).
2. Navigate to Settings > Integrations > Sources and click Configure for Gerrit.
3. Submit your Gerrit instance URL and HTTP credentials to start monitoring.

Check out the full integration guide to learn more.

Fixes​

• Personal Access Tokens: Fixed a bug where the source scopes selected during PAT creation were not correctly applied, resulting in tokens being created with unintended permissions.
• Bitbucket Cloud Integration: Updated the Bitbucket Cloud integration to use the new workspace-scoped APIs, following Atlassian's deprecation and removal of cross-workspace REST API endpoints.

NHI Governance can now tell you which of your Non-Human Identities hold admin rights, which are overprivileged compared to what they need, and automatically raises the risk level of any policy breach that lands on an admin NHI. You get a prioritized inventory where the identities an attacker would abuse first are already at the top, across AWS IAM, Microsoft Entra, and Okta.

What does this mean for you?

• Admin identities at a glance: NHIs with admin-level permissions (e.g. AWS AdministratorAccess, Entra Global Administrator, Okta Super Admin) are marked with an Identity level: Admin badge in the inventory and detail view.
• New policy, Overprivileged Identity: A dedicated policy flags identities granted broader permissions than they use, so you can drive NHIs back toward least privilege.
• Smarter risk criticality: Any policy breach on an admin NHI is automatically bumped one severity level higher, capped at critical. A leaked internal secret on an admin identity now shows as critical, not high.
• Cross-source coverage: Admin and overprivilege checks run on AWS IAM, Microsoft Entra (directory roles, Azure RBAC, Microsoft Graph permissions), and Okta (built-in and custom admin roles).

Why is it important?

Not all NHIs carry the same risk. An admin or overprivileged identity that leaks gives an attacker full control of the account, tenant, or directory, while a scoped identity limits the blast radius to one system. Until now, spotting those identities meant combing through IAM policies, directory roles, and custom permissions by hand, and a leaked internal secret looked the same whether it belonged to a read-only service or a Global Administrator.

With this release you can:

1. Focus remediation where it matters: Start with admin and overprivileged NHIs, and with the incidents their breaches generate, instead of treating every NHI equally.
2. Enforce least privilege: Surface NHIs that accumulated broad permissions over time and bring them back in line.
3. Shrink the blast radius: Cut the number of high-impact identities that a single compromised secret could abuse.
4. Meet audit expectations: Evidence that admin and overprivileged machine identities are reviewed, named, and tracked.

Get started

1. Open NHI Governance → Identities and sort by Risk criticality to see which NHIs rank highest.
2. Use the Identity level filter to isolate admin NHIs, and the Breached policies filter to find Overprivileged Identity breaches.
3. Learn more about admin identities, the Overprivileged Identity policy, and risk criticality.

This feature is available to NHI Governance paying customers.

Enhancements​

• Privacy Mode: Workspace owners can now enforce privacy mode at the workspace level, restricting the ability to view plaintext secrets to managers only or owners only for tighter control over sensitive data visibility. Learn more.
• Audit Logs: The list of captured audit log event types is now available through the public API, making it easier to configure SIEM ingestion and alerting rules. Learn more.
• AI: Workspace admins can now manage third-party LLM usage directly from the dashboard. Choose between GitGuardian's managed LLM providers (default), routing calls through your own AWS Bedrock account with Bring Your Own Cloud, or turning external LLMs off entirely. Internal ML models for false positive detection, prioritization scoring, and similar issues continue to run regardless, and existing configurations are unchanged. Learn more.

Fixes​

• Incidents: Fixed an issue where secret grasper matches found in long diffs were not visible in the dashboard occurrence view. The full file content is now displayed when the match falls outside the truncated patch.
• GitLab health check: Updated the GitLab instance health check for compatibility with GitLab.com and upcoming GitLab 19 self-hosted versions.

Team perimeter already scoped internal incident access for version control repositories. It now applies to all non-VCS integrations—container registries, messaging and collaboration (Slack, Microsoft Teams), documentation and file storage (Confluence, SharePoint Online, OneDrive), ticketing (Jira, ServiceNow), package registries—and to Bring Your Own Sources. Members only see incidents for sources that workspace managers add to their team's perimeter.

What does this mean for you?

• Consistent access control: The same team rules apply whether a secret is found in a repository, a container image, a chat, a document, or a custom source.
• Clearer delegation: Managers can assign sources to teams from the same team perimeter configuration flow.

Get started

Workspace Managers can add sources to a team's perimeter from Settings > User management > Teams, then open the team and use Add sources under the perimeter section. See Configure team perimeter and the Sources integration overview for supported integrations.

Fixes​

• Public Monitoring: Fixed an issue where some secret grasper matches were not displayed and highlighted in the incident page when they occurred in the full file content rather than in the commit diff.

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.

GitGuardian now enforces multi-factor authentication (MFA) via email verification for all users who sign in with email and password. After entering your credentials, you'll receive a verification code at your email address to confirm your identity.

Beyond login, verification is also required before performing sensitive actions in your workspace settings — such as configuring SSO, creating API tokens, managing integrations, or inviting members.

Who is affected?

• Users who log in with email and password will be prompted for email verification at login and before sensitive actions.
• Users who log in via SAML SSO or GitHub are not affected — MFA is handled by your identity provider.

For more details, see the MFA email verification documentation.

Enhancements​

• Bring Your Own Sources: The POST /v1/scan/create-incidents API now supports an optional location.url field, allowing you to link scanned documents back to their origin (e.g., a wiki page, ticket, or config file). When provided, this URL appears in incident details for easy navigation to the origin of the leak.
• Authentication: Personal Access Tokens (PAT) and Service Account Tokens (SAT) now use an improved v2 format with gg_pat_ and gg_sat_ prefixes for better detection and security.

Fixes​

• Audit Logs:
  • Fixed an issue where the incorrect actor was displayed for certain audit log entries in the frontend.
  • Audit logs are now properly generated when creating Custom Sources via API using Personal Access Tokens.
• Incidents: Fixed an issue in the bulk filter panel where the select-all checkbox showed "0 incidents" and failed to deselect incidents after selection.
• API: Fixed a bug in the /v1/public-incidents/secrets/{id}/occurrences endpoint when retrieving occurrences for incidents discovered through Explore.
• NHI Governance: Resolved timeout issues when collecting Microsoft Entra ID data for workspaces with large datasets.

We are introducing a unified approach to public exposure information for secrets detected in Internal Monitoring. This update consolidates how we display public exposure, making it easier to understand and act on publicly visible secrets.

What's changing?

• Single tag: The "Publicly exposed" and "Publicly leaked" tags are now consolidated into a single "Publicly leaked" tag that appears whenever a secret has any type of public exposure.
• New "Public exposure" property: A new property provides detailed information about the nature of the exposure, categorized into three types:
  • Source is publicly visible: The incident has at least one occurrence in a monitored source that is publicly visible.
  • Has linked public incident: The secret also appears in public incidents from your public perimeter (requires Public Monitoring).
  • Found outside perimeter: The secret was found in public locations unrelated to your company, such as repositories you don't own (requires Public Monitoring for full details).

A new default saved view "Public exposure" and a dedicated column are available to help you filter and view exposure details.

👉 Learn more about public exposure

Setting up SSO and user provisioning shouldn't feel like a side project. That's why GitGuardian is now available as an Okta-verified app on the Okta Integration Network — giving your identity team a streamlined, standardized way to connect GitGuardian with your Okta directory.

What does this mean for you?

• One-click SAML SSO: Add GitGuardian from the Okta app catalog and configure SSO in minutes — no custom SAML app required.
• SCIM provisioning built in: Automatically create, update, and deactivate GitGuardian users when changes happen in Okta. No more manual onboarding or orphaned accounts.
• Group Push: Sync your Okta groups and their memberships directly into GitGuardian teams, keeping access aligned with your directory structure.
• SP and IdP-initiated SSO: Users can sign in from the GitGuardian dashboard or straight from their Okta portal — both flows are supported out of the box.
• Just-in-Time provisioning: New users get a GitGuardian account automatically on first login, even without SCIM.

Why is this important?

Managing user access across security tools is a pain point for every identity team. Manual provisioning leads to delays, stale accounts, and inconsistent permissions. With the Okta Integration Network app, GitGuardian plugs directly into your existing identity lifecycle — so access stays in sync, offboarding is instant, and your team can enforce consistent security policies without extra overhead.

Get Started Today!

1. In Okta, go to Applications > Browse App Catalog and search for "GitGuardian"
2. Click Add Integration and enter your GitGuardian Workspace ID
3. Configure SSO in your GitGuardian dashboard under Settings > Authentication
4. Optionally, enable SCIM provisioning under Settings > Identity Provider

Check out the full Okta SSO setup guide and the SCIM configuration guide to learn more.

Another registry, zero blind spots. We're expanding GitGuardian's container security coverage with a new integration for Red Hat Quay — the enterprise-grade, OCI-compliant registry trusted by organizations running OpenShift and hybrid cloud infrastructure.

Whether you're on quay.io or running a self-hosted Quay instance, GitGuardian now has you covered by scanning your container images for hardcoded credentials, API keys, and internal tokens buried in image layers.

What does this mean for you?

• SaaS and self-hosted, covered: Works with quay.io and on-premise Red Hat Quay deployments — same integration, same protection.
• Full image layer analysis: Every layer, every Dockerfile, every environment variable — scanned for secrets that shouldn't be there.
• Historical + incremental scanning: Catch secrets already hiding in existing images, and detect new ones as they're pushed.
• Granular perimeter control: Monitor specific repositories or your entire Quay instance — fine-tune coverage to match your needs.
• OAuth2 authentication: Secure, token-based integration with read-only access. No credentials stored, no write permissions required.

Why is this important?

Container images are the final artifact before production. A secret embedded in an image layer — a database password in an ENV directive, an API key baked into a config file — travels straight to your runtime environment. Unlike source code, image layers are often overlooked in security reviews, making them a prime vector for credential exposure.

With Red Hat Quay joining Docker Hub, Amazon ECR, Azure Container Registry, Google Artifact Registry, and JFrog Container Registry, GitGuardian now covers six major container registries — giving you unified secrets detection wherever your images live.

Get Started Today!

1. Navigate to Settings > Integrations > Sources
2. Click Install next to Red Hat Quay in the Container registries section
3. Create an OAuth Application in your Quay instance and connect it to GitGuardian

This feature is currently available in beta. Check out the full setup guide to learn more.

--

Enhancements​

• Public API: Added endpoint to retrieve GitGuardian's egress IP addresses in CIDR notation for allowlisting in firewalls, network security groups, or other access control systems. Learn more.

Your container images are scanned. Your Git repos are covered. But what about the packages flowing through your software supply chain?

We're thrilled to announce JFrog Artifactory Package Registries integration — bringing GitGuardian's secrets detection engine to the artifacts that power your builds. Maven JARs, npm tarballs, PyPI wheels, NuGet packages, and more: if a secret is hiding in there, we'll find it.

What does this mean for you?

• 12 package ecosystems covered: Scan Maven, npm, PyPI, NuGet, Go, Gradle, Swift, Cargo, RubyGems, Composer, Pub, and Generic repositories — all from a single integration.
• Historical + incremental scanning: Detect secrets already lurking in existing packages, and catch new ones as they're published.
• Granular perimeter control: Choose exactly which repositories to monitor, or cover your entire JFrog instance — your call.
• Share remediation efforts: Assign package repositories ownership like you do for VCSs, to route findings to relevant teams.
• Seamless setup: Connect your JFrog Artifactory instance in minutes with an Access Token — no agents, no sidecars, no complexity.

Why is this important?

Secrets don't stay in source code. They travel — embedded in build artifacts, bundled into packages, and shipped across your software supply chain. A leaked API key in a Maven artifact or a database credential in an npm package can compromise production systems just as effectively as one committed to Git.

With this integration, GitGuardian closes a critical blind spot. You now have unified secrets detection across your repositories, container images, and package registries — a complete view of your exposure surface.

Get Started Today!

1. Navigate to Settings > Integrations > Sources
2. Click Install next to JFrog Package Registries in the Package registries section
3. Connect your JFrog instance with an Access Token and start scanning

This feature is currently available in beta.
Check out the full setup guide to learn more.

Enhancements​

• Audit Logs: Scope information is now displayed in audit log entries when Personal Access Tokens (PATs) and Service Account Tokens (SATs) are created, providing enhanced visibility into token permissions for security compliance and monitoring.
• Security Settings: Added the ability to restrict Personal Access Token (PAT) scopes for members, allowing workspace managers to limit members to creating PATs with specific scopes (e.g., "Scan only") for enhanced security control. Learn more.
• Authentication Settings: Added customizable session duration setting, allowing workspace administrators to configure how long dashboard sessions remain active before users are automatically logged out. Learn more.
• Slack & Webhook Alerting: Added feedback content (remarks) to Slack and Webhook alerts for both internal and public monitoring incidents, providing complete feedback information in notification payloads. Learn more.
• Slack Alerting: Enhanced incident notification messages with improved formatting, additional context (secret type, status, assignee, severity, risk score), and clearer attribution for automated GitGuardian actions.
• Jira Ticketing: Added filename and line number as template options in Jira templates, displayed as "N/A" when not applicable to the incident source.
• Dashboard: Added "System" theme mode option that automatically matches the operating system's light or dark mode preference, set as default for new users.

Fixes​

• Alerting: Fixed an issue where Jira Cloud installations were unexpectedly soft-deleted without user action, causing notification failures.
• API: Fixed schema validation error for API response path 'id' that was causing client-side errors.
• Incidents: Fixed timeout issues when applying bulk updates to incident custom tags, improving performance for large-scale operations.
• Public Incidents: Fixed 400 Bad Request error when creating public incidents from secrets found in Explore.
• Security: Fixed an authorization issue where Workspace Members with Team Leader permissions could delete notification settings for the "All Incidents" team, ensuring only Workspace Managers can manage these settings.

We're introducing Ownership in NHI Governance: you can now assign and track who is responsible for each Non-Human Identity across your inventory. Ownership helps close the accountability gap for machine identities, speed up remediation when secrets are exposed, and align with compliance expectations.

What does this mean for you?

• Suggested owners: GitGuardian automatically suggests owners using data from your integrated sources and from secret incidents.
• Manual control: Add, edit, or remove owners at any time from an NHI's detail view.
• Inventory at a glance: An Owner column in the NHI inventory shows who is responsible for each identity.
• Workspace members and external users: Owners can be workspace members or external users identified by email.

Why is it important?

NHIs outnumber human identities by orders of magnitude, yet accountability for machine identities is usually unclear. Without ownership, remediation slows down, orphaned accounts go unaddressed, and incident response suffers when secrets are exposed or misconfigured. Ownership gives you:

1. Faster remediation – Know who to contact when an NHI is compromised or needs rotation.
2. Fewer orphaned accounts – Assign responsibility so every identity has someone accountable.
3. Stronger compliance – Meet audit and regulatory expectations (e.g. PCI-DSS, SOC 2, HIPAA) that require clear accountability for sensitive resources.
4. Better triage – Filter and prioritize by owner (e.g. "identities with no owner" or "owned by my team") to focus efforts where they matter most.

Get started

Open NHI Governance → Identities to see the Owner column and filter. Open any NHI to view or edit owners in the Owners section. Learn more about Ownership

This feature is available to NHI Governance paying customers.

Enhancements​

• Incidents: CSV exports now include new columns (risk_score, custom_tags, incident_name), updated tags, and a dedicated public monitoring export format with additional actor and source information.
• ggshield: Secrets with multiple incidents (when using "By secret per source" grouping) are now correctly ignored in scans if a related incident exists and is closed, preventing CI pipelines from blocking unnecessarily.

Fixes​

• Validity Checks: Secrets marked as invalid are now re-checked periodically, so their status can update to valid when they become usable again.
• Analytics: Commit date in hover tooltips now matches the actual timeline data.
• Developer in the Loop: Duplicate feedback submissions are now prevented by disabling the submit button after click and applying a cooldown period.
• SCIM: Email notifications for user and team sync operations (onboarding, offboarding, team membership changes) are now off by default. A new setting in the identity provider section lets you opt in to these notifications when desired.

We've refreshed the GitGuardian interface and introduced Dark Mode so you can work comfortably in any environment. The updated design brings cleaner layouts, improved contrast, and polished forms and navigation, making everyday tasks feel smoother and easier to consume.

What does this mean for you?

• Reduced Eye Strain: Work comfortably during late-night incident responses or in low-light environments with the new Dark theme.
• Personalized Experience: Choose the theme that works best for you—Light or Dark.
• Cleaner Interface: Enjoy improved contrast and polished navigation that makes reviewing incidents or exploring NHI identities faster.

How to Enable Dark Mode

To try it out, head to Account → Interface → Theme and pick your preference. Theme selection is per-user and stored in your profile, so your choice follows you across sessions.

Enhancements​

• Incidents API: Added external ticket information (Jira/ServiceNow) to incidents API responses, simplifying integration and improving tracking in alerting and issue management workflows.
• Analytics: Updated period selector options to include "Last 30/60/90 days" and "Previous month/quarter/year" for more flexible date range selection.
• SSO and GitGuardian Bridge configuration: Improved user experience when editing SSO Identity Provider and GG Bridge certificates, with clearer certificate status display and replacement workflows.

Fixes​

• Validity Checks: Implemented automatic retry mechanism for failed validity checks to reduce false alarms caused by transient errors such as temporary service unavailability.
• CSV Export: Fixed an issue where the secret value column in CSV exports contained invalid JSON format with single quotes instead of proper double-quoted JSON.