Public Secrets Monitoring: AI Analysis of Leaked Credentials

TL;DR

The exposure problem: AI-driven development pushed exposed credentials to 1.27 million last year, up 81%, and 64% of secrets confirmed valid in 2022 are still unrevoked as of January 2026.
The fix: GitGuardian Public Secrets Monitoring now runs two AI agents and deep analysis over every public GitHub and Docker Hub incident, returning a company-related verdict, a risk score, and visible reasoning.
The rollout: New workspaces get Agents Analysis by default, existing ones roll out gradually, one enterprise team saw a 10x productivity gain, and human review still closes every incident.

Credentials for AI services reached 1.27 million exposed across public code last year, up 81%, and 24,008 unique secrets turned up in public MCP configuration files alone. What makes those numbers worse is how long they stay live: of the secrets GitGuardian confirmed valid in 2022, 64% were still unrevoked when we retested them in January 2026, which means the same leaked credentials are still reaching the same systems they did on day one.

AI-driven development has multiplied the places compromised credentials can land in public: not just source code and CI/CD pipelines, but MCP configuration files, AI tool caches, terminal session logs, and the output of agents that write code for the humans running them. The public exposure surface grew faster than any team's capacity to review it.

Scale moved the bottleneck rather than creating a new one. Detection at this volume is tractable, and what has become hard is everything downstream of the alert: deciding whether the leaked key belongs to your organization at all, and whether it is serious enough to act on today.

The two main questions that gate every public incident

Two questions determine whether a public monitoring program delivers value or drowns in noise.

1. Is this actually ours?

A credential appearing in a public repository could belong to your organization, a vendor, a contractor, or a developer who used your domain in a test environment.

The hard cases run in both directions. A cloud key in the personal repository of one of your developers looks damning until you consider that it might belong to their own account. A key committed by someone you have never heard of, in a repository you did not know existed, looks irrelevant until you notice that the surrounding code references one of your internal services. Both are live credentials, and the difference between "critical: escalate now" and "not ours: ignore" is the first thing a reviewer needs to know, and it's the thing most risk scores couldn't reliably answer.

2. How serious is it?

Risk is contextual: an unrevoked production database password sitting in a six-month-old public commit is a different situation entirely from a test API key in a sandbox. A number on a scale of one to 10 collapses that difference into an ordinal, without the reasoning behind it, the triage path that follows from it, or anything an AppSec lead can hand to their team.

Without reliable answers to both, security teams end up choosing between over-triage, which means reviewing everything and burning analyst hours on incidents that were never theirs, and under-triage, which means moving fast enough to miss the ones that were. Neither holds up as the volume grows.

A multi-agent pipeline built for both questions

GitGuardian Public Secrets Monitoring now runs two AI agents over every public incident across GitHub and Docker Hub. A triage agent makes a first-pass assessment of each incident. The most promising cases are promoted to a deep analysis agent for a more thorough investigation. Their conclusions surface in three places:

Each incident is marked Related, Uncertain, or Unrelated, with the reasoning available to inspect rather than a probability to interpret. Only the deep analysis agent can confirm a Related verdict, so seeing one means the incident cleared both passes.

An agent-computed risk score

The score reflects what the secret is, where it appeared, and what it can reach. It is set once and does not drift, and anything ruled Unrelated scores zero, so sorting by risk buries the noise automatically.

An Analysis tab

This is the part that changes how a reviewer actually works. The investigation details view lays out how the agents moved from detection to verdict, showing the triage reasoning, the deep analysis where it ran, and the timeline of both. Most tooling in this category hands back a classification and expects it to be taken on trust, which is a difficult thing to ask of a team that will have to justify a credential rotation to an engineering group that did not ask for one. Here the working is shown, so a reviewer who disagrees with a verdict can see which signals produced it and judge whether their own knowledge of the environment outweighs them.

Three saved views arrive pre-configured, covering company-related, unclear if company-related, and not company-related incidents, so teams open a queue that has already been triaged rather than a flat list to work through. Where a verdict misses the mark, a feedback loop lets reviewers flag it, and GitGuardian uses that signal to improve later versions of the analysis.

Agents Analysis is on by default for new Public Secrets Monitoring workspaces, which get the company-related verdict, the risk score, the Analysis tab, and the new saved views immediately. Existing workspaces are being rolled over more gradually, because many teams have workflows built around the previous tags and scoring and should understand what changes before it changes underneath them. The capability is in beta, analysis lands within a day of detection rather than instantly, and customers who want it enabled early can ask their Customer Success Manager.

From detection to action

One enterprise security team managing their GitGuardian incidents through an MCP server integration reported a 10x improvement in productivity. Agent-generated context, meaning the verdict, the reasoning, and the risk score, replaces the manual investigation that used to precede every remediation conversation. The analyst who needs to know whether an incident is theirs and how bad it is now gets that answer delivered alongside the incident instead of going to look for it.

Here, you can read about how we got a CISA GitHub leak down in under a day.

Where the signal matters most

Public Secrets Monitoring has always sat at a specific point in how organizations respond to exposure. Most of the time, a secret that appears in public was exposed internally first, which makes the public alert less a starting point than the earliest external signal that something upstream has already gone wrong.

That makes the triage decision more consequential than it looks, since a false positive costs analyst hours while a missed true positive can mean an attacker reaches the credential first.

Agent analysis makes the signal sharper: less noise to filter, clearer reasoning for the findings that do need human attention, and a faster path from "a secret was disclosed in public" to the internal question that actually matters: where did this come from, and what else is exposed?

AI-driven development built this exposure problem, and the same class of tooling is now what makes it manageable, because exposure arriving at machine speed cannot be triaged at human speed alone. What the GitGuardian platform does is separate the noise from the incidents worth reading. It does not close anything automatically, and that judgment stays with your team.

Find the leaked credentials that are actually yours

GitGuardian Public Secrets Monitoring gives every public incident a verdict, a risk score, and the reasoning behind both.

Join the live webinar.

FAQ

Why are leaked credentials an ongoing problem?

Exposure outlives the commit. Of the credentials GitGuardian confirmed valid in 2022, 64% were still active in January 2026, and credentials for AI services grew 81% year over year to 1.27 million exposed across public code. Revocation rarely keeps pace with the rate of new exposure.

How can businesses detect leaked credentials?

Public secrets monitoring scans public sources such as GitHub and Docker Hub for credentials tied to your organization. At current volume, detection alone is not enough, so a useful system also determines whether the credential is actually yours and how severe the exposure is before anyone reviews it.

Which secrets managers detect leaked credentials?

None, and that is by design. A secrets manager protects credentials you have deliberately placed under management, controlling issuance, rotation, and access. It has no visibility into credentials that were never stored in it, which is precisely the category that ends up in public repositories. Detection is a separate control.

What to do after credentials are leaked?

Confirm the credential belongs to your organization, then revoke or rotate it. Scope comes next: find where else the secret exists internally, since a public appearance can be a downstream symptom rather than the origin. Close the incident once the internal source has been identified and fixed.