GitHub Public Monitoring Now Has an API and Webhooks

GitHub's public monitoring, the feature that flags credentials your enterprise's people leak in any public repository on github.com, gained alert triage, always-on validity checks, a REST endpoint, and an enterprise webhook on October 23, 2026. It is still a public preview for GitHub Enterprise Cloud, and it is included with a GitHub Advanced Security or GitHub Secret Protection license at no extra cost.

The practical change is simple: leaks that happen outside the repositories you own can now flow into the same incident pipeline as everything else, already sorted by whether the key still works.

What changed on October 23

Before this update, public monitoring could tell an enterprise that a secret tied to it had shown up in someone's public repo, but there was little to do with that alert beyond reading it. GitHub's changelog lists four additions:

• Triage. Alerts can be closed as Dismissed or Fixed with an optional comment, and reopened later. Each alert gets an activity timeline that records every state change.
• Filtering. The enterprise security dashboard can filter alerts by repository, committer, secret type, attribution method (membership or verified domain), and open or closed state.
• Validity checks. For supported providers, GitHub keeps checking whether a leaked token still works and labels it Active, Inactive, or Unknown.
• API and webhook. Enterprise admins and security managers can pull findings from GET /enterprises/{enterprise}/secret-scanning/public-monitoring-alerts, and subscribe to the secret_scanning_public_monitoring_alert event at the enterprise level.

A day earlier, GitHub extended public monitoring to Enterprise Cloud with data residency. In those regions, attribution relies only on verified domain matching, because enterprise membership rosters are not shared across the residency boundary. At the time of writing, the public monitoring docs page still says the feature is not available with data residency, so expect the docs to catch up with the changelog.

What public monitoring actually watches

Regular secret scanning looks at repositories your organization or enterprise owns. Public monitoring looks everywhere else. According to GitHub's docs, it scans public repositories across github.com, including non-code content such as issue and pull request comments, and attributes a leaked secret to your enterprise in one of two ways:

• Enterprise membership: the person who leaked it is a member of your enterprise.
• Verified domain matching: the commit author's email matches a domain your enterprise has verified, even if that person is not a direct member.

That covers the leaks security teams usually hear about last: a developer's weekend side project with a copied .env, a public fork used to reproduce a bug, a gist-style repo of shell scripts, or a pasted stack trace in an issue on someone else's open source project. None of those repositories belong to the company, so repo-level scanning never sees them.

Why this matters more now that agents write code

AI coding agents have made it cheap to spin up throwaway repos, scaffold projects with real config files, and push without a human reading every diff. That increases the number of places a working key can land. Vendors are adding guardrails at different layers: Metarix covered how Codex CLI started masking credentials in remote shell sessions, and how GitHub secret scanning added detectors for Lovable and Supabase keys, the kinds of tokens vibe-coded apps tend to carry.

Public monitoring sits at the last layer: the secret already escaped, and the question is how fast you notice and rotate it. Validity checks matter here because most leaked-secret queues are mostly noise. An expired test key and a live production key look identical in a list. Sorting by Active turns a long backlog into a short page.

One detail from the changelog is easy to miss: closing an alert does not revoke the credential or remove it from the public repository. Marking it Fixed is bookkeeping. Rotation still happens at the provider, and the commit history still contains the old value.

Wiring it into an incident pipeline

The sketch below is illustrative, not something Metarix has run against a live enterprise. It shows how the new pieces fit together; check GitHub's REST and webhook reference for the exact payload fields and supported token types before you build on it.

1. Turn it on. An enterprise admin or enterprise security manager enables public monitoring and its alert settings from the enterprise security dashboard. You need GitHub Enterprise Cloud plus a GitHub Advanced Security or Secret Protection license.

2. Backfill with the REST API. A scheduled job can pull existing findings so nothing that predates the webhook is lost. A request looks like this (illustrative; ACME is a placeholder enterprise slug and the token comes from your secret store, never from code):

curl -H "Authorization: Bearer $GH_TOKEN" -H "Accept: application/vnd.github+json" https://api.github.com/enterprises/ACME/secret-scanning/public-monitoring-alerts

Per the changelog, the response carries alert metadata, the secret type, how it was attributed, and the exposed locations.

3. Go real time with the webhook. Subscribe an enterprise webhook to secret_scanning_public_monitoring_alert and route each event by validity:

• Active: page the owning team, rotate the credential at the provider, then close the alert as Fixed with a comment linking the rotation ticket.
• Inactive: confirm the key is really dead, then close it with a short note so the audit trail shows the decision.
• Unknown: send it to a human queue. Unknown usually means GitHub cannot check that provider, not that the key is safe.

4. Reach out to the committer. The alert names the committer and location. For a personal repo, the fastest fix is often asking the developer to delete the file and rewrite history, but treat that as cleanup after rotation, never instead of it.

If your integration already reads secret scanning audit log events, note a separate change from GitHub's October 20 secret scanning update: from November 12, 2026, the business field in secret_scanning_alert.* and push protection bypass events switches from the enterprise display name to the enterprise slug. Filters that match on the display name will break unless they accept both or use business_id.

For the automation account behind all this, a GitHub App is a better fit than a personal access token now that GitHub Apps can replace enterprise PATs for more admin work; see the GitHub Apps page for context.

How it compares with other leak defenses

Public monitoring is one of several overlapping controls. They catch different leaks at different moments:

• [Push protection](https://docs.github.com/en/code-security/secret-scanning/introduction/about-push-protection) blocks supported secrets before a push lands. It prevents leaks but only where it is enabled, and a developer can still bypass it.
• Repository secret scanning finds secrets already committed to repos you own, with alerts going to that repo's admins.
• [The secret scanning partner program](https://docs.github.com/en/code-security/secret-scanning/secret-scanning-partnership-program/secret-scanning-partner-program) sends matches found in public repositories to the token's issuer, so a provider can notify the owner or revoke the key. The provider learns about the leak; your security team may not.
• Public monitoring sends leaks in repos you do not own to your enterprise, attributed to your people. It is the only one of the four that tells your security team about a leak in someone else's repository.
• Third-party monitoring such as GitGuardian's public GitHub monitoring covers similar ground without requiring GitHub Enterprise Cloud, as a separate paid product.

Limits worth knowing

• Preview status. GitHub says public monitoring is in public preview and subject to change, so the API and webhook payloads could shift.
• Enterprise Cloud only. Organizations on other plans, or teams without an Advanced Security or Secret Protection license, do not get it.
• Attribution has gaps. As documented, a leak is only attributed through enterprise membership or a verified email domain. A contractor committing from a personal account with a personal email, who is not an enterprise member, would match neither.
• Validity checks are partial. They run only for supported providers; everything else shows Unknown.
• No cleanup. GitHub does not revoke the secret or scrub the repository for you.

Verdict

If you already pay for GitHub Enterprise Cloud with Advanced Security or Secret Protection, turn public monitoring on this week and connect the webhook. It costs nothing extra, and the Active label alone is enough to make the alert queue worth watching. Route Active findings straight to rotation and keep a human on the Unknown ones.

If you are not on that tier, this update is not a reason to upgrade by itself. Push protection, pre-commit scanning, short-lived credentials, and agent tools that mask secrets will prevent more leaks than any monitor catches afterward. Public monitoring is the safety net for the leaks that get through, and as of this update it is finally a net you can automate.

Sources

• GitHub Changelog: Public monitoring adds triage, validity, API, and webhooks (October 23, 2026)
• GitHub Changelog: Public monitoring now available with data residency (October 22, 2026)
• GitHub Docs: Public monitoring for secret scanning
• GitHub Changelog: Updates to GitHub secret scanning (October 20, 2026)
• GitHub Docs: Secret scanning partner program
• GitHub Secret Protection product page