GitHub starts watching the whole public site for your leaked secrets

The most reliable way to leak a secret from a private repository is still the accidental human sitting next to it. A personal fork opened to test a workflow change. A support ticket with a full env dump pasted in for context. A public gist someone opened at 2am to "just share this quickly." Your enterprise-grade secret scanner never saw any of those. This week it started to.

On July 1, 2026, GitHub added a preview capability called public monitoring to secret scanning for enterprises. According to the changelog, it watches the entire public surface of github.com in real time for secrets that belong to your enterprise, and it attributes hits back to your organisation based on where your people commit. It ships to GitHub Enterprise Cloud customers with GitHub Secret Protection or Advanced Security, at no additional cost.

What actually changed

The old model was narrow by construction. Enterprise scanners looked at surfaces the enterprise owned: your org's repos, your PRs, your push events. Everything outside that boundary was somebody else's problem, usually a security researcher's, and you found out when the responsible-disclosure email arrived.

Public monitoring widens the sensor to the entire public github.com. The changelog names git content, pull request comments, GitHub issues, and arbitrary public repositories. Detection is described as real-time, not a nightly crawl. Attribution runs through GitHub's identity layer and the verified domains you have already attached to your enterprise. Plainly: if an employee pushes a token to a personal repo that has nothing to do with your organisation, the scan can still fire and land in your Security tab.

Two consequences sit under that. Blast radius: detection now covers commits your enterprise never owned. Attribution: leaks are supposed to route to the right enterprise instead of a general researcher inbox, provided the identity graph is clean. When it isn't (contractors, unlinked personal accounts, offboarded people who kept a public fork), expect the edges to fray.

Why a pipeline team should care

Every pipeline is a story about who holds the token. The pipeline itself is usually the easy part. What breaks is the tributaries: a developer's script that copies a value into notes, an issue where someone pastes half an environment to explain a bug, a fork someone opened to sketch a change before a PR. That is where leaks live, and it is exactly the terrain the enterprise scanner did not walk.

Widening the sensor means that class of leak (human error one step outside the perimeter) is now visible with the same latency as the leak itself. If it works as claimed, your first indicator of a leaked deploy key stops being an outside researcher and starts being an internal alert.

Does that let you rip out your third-party scanners? No. Pastebin, container registries with world-readable manifests, npm postinstall scripts phoning home, someone's Notion page set to public: GitHub sees GitHub, and the rest is still on you.

Turning it on, honestly

The changelog is thin here on purpose. Enterprise owners and security managers enable it from the enterprise Security tab. It is public preview, so settings and defaults will move. Support for Enterprise Cloud with data residency is listed as "coming soon," which matters if your compliance posture depends on it.

A short pre-flight for the CI/CD side:

• Verified domains. Attribution runs through them. Stale identity plumbing means misses and misrouted alerts.
• The alert path. Preview features tend to land in the same stream as owned-repo findings. Decide whether a personal-fork leak pages the same rotation as a push to main. The triage flavour is different.
• Rotation runbook. If time-to-rotate is measured in days, the sensor gets ahead of your response. Fix the runbook before turning up the volume.

There is no YAML to paste, because the behaviour you are enabling is a policy, not a workflow. What you can do is audit your own hygiene the day you flip the switch:

# List the secrets your workflows still consume by name. Long-lived PATs
# are exactly what public monitoring will find on someone's personal fork.
gh api "/orgs/$ORG/actions/secrets" --paginate \
  | jq -r '.secrets[] | [.name, .created_at, .updated_at] | @tsv'

If that list still contains classic PATs or long-lived deploy keys, the alert will find you before you find them. Rotate to short-lived OIDC-issued credentials first.

Where the caveats live

Preview, not GA. That is the whole disclaimer in two words. Scope will change, the UI will change, and public-preview features have been rolled back or moved behind add-ons before. Do not build a runbook around behaviour that has not stabilised.

The upside is real: the category being addressed is the one enterprise scanning has historically been useless at, and improvement there is worth taking seriously. The caveat is smaller and chronic: your secrets do not live only on github.com, and this changes nothing about that. Rotate on detection anyway. Read the docs. And treat the alert queue as production the day you turn it on.

If your incident-response plan for a leaked credential is still "we will hear about it from Twitter," you now have one fewer excuse. The alert is coming from inside the enterprise.